RFC3775 日本語訳
3775 Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT=393514 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Johnson
Request for Comments: 3775 Rice University
Category: Standards Track C. Perkins
Nokia Research Center
J. Arkko
Ericsson
June 2004
コメントを求めるワーキンググループD.ペニス要求をネットワークでつないでください: 3775年のライス大学カテゴリ: 標準化過程C.パーキンスノキアリサーチセンターJ.Arkkoエリクソン2004年6月
Mobility Support in IPv6
IPv6での移動性サポート
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes.
このドキュメントはノードがIPv6インターネットを動き回っている間に届いたままで残ることができるプロトコルを指定します。 それぞれの可動のノードはインターネットへの現在の接着点にかかわらずいつもホームアドレスによって特定されます。 また、家から遠くに位置している間、可動のノードと交際する、注意、-、アドレス、可動のノードの現在の位置の情報を提供する。 透明に可動のノードのホームアドレスに記述されたIPv6パケットに掘られる、それ、注意、-、アドレス。 プロトコルが、IPv6ノードが可動のノードのホームアドレスの結合をキャッシュするのを可能にする、それ、注意、-、アドレス、次に、可動のノードのために直接それに運命づけられたどんなパケットも送る、これ、注意、-、アドレス この操作を支持するために、モバイルIPv6は新しいIPv6プロトコルと新しい目的地オプションを定義します。 可動であるか、または静止していることにかかわらずすべてのIPv6ノードが可動のノードとコミュニケートできます。
Johnson, et al. Standard Track [Page 1] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[1ページ]のRFC3775移動性サポート
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . 6
3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. General Terms . . . . . . . . . . . . . . . . . . . 8
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . 10
4. Overview of Mobile IPv6. . . . . . . . . . . . . . . . . . 13
4.1. Basic Operation . . . . . . . . . . . . . . . . . . 13
4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . 15
4.3. New IPv6 Destination Option . . . . . . . . . . . . 17
4.4. New IPv6 ICMP Messages. . . . . . . . . . . . . . . 17
4.5. Conceptual Data Structure Terminology . . . . . . . 17
4.6. Site-Local Addressability . . . . . . . . . . . . . 18
5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . 18
5.1. Binding Updates to Home Agents. . . . . . . . . . . 18
5.2. Binding Updates to Correspondent Nodes. . . . . . . 20
5.2.1. Node Keys . . . . . . . . . . . . . . . . . 20
5.2.2. Nonces. . . . . . . . . . . . . . . . . . . 20
5.2.3. Cookies and Tokens. . . . . . . . . . . . . 21
5.2.4. Cryptographic Functions . . . . . . . . . . 22
5.2.5. Return Routability Procedure. . . . . . . . 22
5.2.6. Authorizing Binding Management Messages . . 27
5.2.7. Updating Node Keys and Nonces . . . . . . . 29
5.2.8. Preventing Replay Attacks . . . . . . . . . 30
5.3. Dynamic Home Agent Address Discovery. . . . . . . . 30
5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . 30
5.5. Payload Packets . . . . . . . . . . . . . . . . . . 30
6. New IPv6 Protocol, Message Types, and Destination Option . 31
6.1. Mobility Header . . . . . . . . . . . . . . . . . . 31
6.1.1. Format. . . . . . . . . . . . . . . . . . . 32
6.1.2. Binding Refresh Request Message . . . . . . 34
6.1.3. Home Test Init Message. . . . . . . . . . . 35
6.1.4. Care-of Test Init Message . . . . . . . . . 36
6.1.5. Home Test Message . . . . . . . . . . . . . 37
6.1.6. Care-of Test Message. . . . . . . . . . . . 38
6.1.7. Binding Update Message. . . . . . . . . . . 39
6.1.8. Binding Acknowledgement Message . . . . . . 42
6.1.9. Binding Error Message . . . . . . . . . . . 44
6.2. Mobility Options. . . . . . . . . . . . . . . . . . 46
6.2.1. Format. . . . . . . . . . . . . . . . . . . 46
6.2.2. Pad1. . . . . . . . . . . . . . . . . . . . 47
6.2.3. PadN. . . . . . . . . . . . . . . . . . . . 48
6.2.4. Binding Refresh Advice. . . . . . . . . . . 48
6.2.5. Alternate Care-of Address . . . . . . . . . 49
6.2.6. Nonce Indices . . . . . . . . . . . . . . . 49
6.2.7. Binding Authorization Data. . . . . . . . . 50
6.3. Home Address Option . . . . . . . . . . . . . . . . 51
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 5 2。 IPv4. . . . . . . . . . . . 6 3のためのモバイルIPとの比較。 用語。 . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. 一般項. . . . . . . . . . . . . . . . . . . 8 3.2。 モバイルIPv6用語. . . . . . . . . . . . . . . . . 10 4。 モバイルIPv6の概観。 . . . . . . . . . . . . . . . . . 13 4.1. 基本的な操作. . . . . . . . . . . . . . . . . . 13 4.2。 新しいIPv6は.154.3について議定書の中で述べます。 新しいIPv6目的地オプション. . . . . . . . . . . . 17 4.4。 新しいIPv6 ICMPメッセージ。 . . . . . . . . . . . . . . 17 4.5. 概念的なデータ構造用語. . . . . . . 17 4.6。 サイト地方のアドレス指定能力. . . . . . . . . . . . . 18 5。 モバイルIPv6セキュリティ. . . . . . . . . . . . . 18 5.1の概観。 結合はエージェントをホームにアップデートします。 . . . . . . . . . . 18 5.2. 通信員ノードにアップデートを縛ります。 . . . . . . 20 5.2.1. ノードキー. . . . . . . . . . . . . . . . . 20 5.2.2。 一回だけ。 . . . . . . . . . . . . . . . . . . 20 5.2.3. クッキーと象徴。 . . . . . . . . . . . . 21 5.2.4. 暗号の機能. . . . . . . . . . 22 5.2.5。 手順をRoutabilityに返してください。 . . . . . . . 22 5.2.6. 拘束力がある管理メッセージ. . 27 5.2.7を認可します。 ノードキーと一回だけ. . . . . . . 29 5.2.8をアップデートします。 反射攻撃. . . . . . . . . 30 5.3を防ぎます。 ダイナミックなホームエージェントアドレス発見。 . . . . . . . 30 5.4. モバイル接頭語発見. . . . . . . . . . . . . . 30 5.5。 有効搭載量パケット. . . . . . . . . . . . . . . . . . 30 6。 新しいIPv6プロトコル、メッセージタイプ、および目的地オプション. 31 6.1。 移動性ヘッダー. . . . . . . . . . . . . . . . . . 31 6.1.1。 形式。 . . . . . . . . . . . . . . . . . . 32 6.1.2. 付いて、要求メッセージ. . . . . . 34 6.1.3をリフレッシュしてください。 ホームテストイニットメッセージ。 . . . . . . . . . . 35 6.1.4. 注意、-、.5にイニットメッセージ. . . . . . . . . 36 6.1をテストしてください。 家では、メッセージ. . . . . . . . . . . . . 37 6.1.6がテストされます。 注意、-、テストメッセージ。 . . . . . . . . . . . 38 6.1.7. アップデートメッセージを縛ります。 . . . . . . . . . . 39 6.1.8. 確認メッセージ. . . . . . 42 6.1.9を縛ります。 エラーメッセージ. . . . . . . . . . . 44 6.2を縛ります。 移動性オプション。 . . . . . . . . . . . . . . . . . 46 6.2.1. 形式。 . . . . . . . . . . . . . . . . . . 46 6.2.2. Pad1。 . . . . . . . . . . . . . . . . . . . 47 6.2.3. PadN。 . . . . . . . . . . . . . . . . . . . 48 6.2.4. 付いて、アドバイスをリフレッシュしてください。 . . . . . . . . . . 48 6.2.5. 代替治療、-、アドレス. . . . . . . . . 49 6.2.6 一回だけのインデックスリスト. . . . . . . . . . . . . . . 49 6.2.7。 認可データを縛ります。 . . . . . . . . 50 6.3. ホームアドレスオプション. . . . . . . . . . . . . . . . 51
Johnson, et al. Standard Track [Page 2] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[2ページ]のRFC3775移動性サポート
6.4. Type 2 Routing Header . . . . . . . . . . . . . . . 53
6.4.1. Format. . . . . . . . . . . . . . . . . . . 54
6.5. ICMP Home Agent Address Discovery Request Message . 55
6.6. ICMP Home Agent Address Discovery Reply Message . . 56
6.7. ICMP Mobile Prefix Solicitation Message Format. . . 57
6.8. ICMP Mobile Prefix Advertisement Message Format . . 59
7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . 61
7.1. Modified Router Advertisement Message Format. . . . 61
7.2. Modified Prefix Information Option Format . . . . . 62
7.3. New Advertisement Interval Option Format. . . . . . 64
7.4. New Home Agent Information Option Format. . . . . . 65
7.5. Changes to Sending Router Advertisements. . . . . . 67
8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . 69
8.1. All IPv6 Nodes. . . . . . . . . . . . . . . . . . . 69
8.2. IPv6 Nodes with Support for Route Optimization. . . 69
8.3. All IPv6 Routers. . . . . . . . . . . . . . . . . . 71
8.4. IPv6 Home Agents. . . . . . . . . . . . . . . . . . 71
8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . 73
9. Correspondent Node Operation . . . . . . . . . . . . . . . 74
9.1. Conceptual Data Structures. . . . . . . . . . . . . 74
9.2. Processing Mobility Headers . . . . . . . . . . . . 75
9.3. Packet Processing . . . . . . . . . . . . . . . . . 76
9.3.1. Receiving Packets with Home Address Option. 76
9.3.2. Sending Packets to a Mobile Node. . . . . . 77
9.3.3. Sending Binding Error Messages. . . . . . . 78
9.3.4. Receiving ICMP Error Messages . . . . . . . 79
9.4. Return Routability Procedure. . . . . . . . . . . . 79
9.4.1. Receiving Home Test Init Messages . . . . . 80
9.4.2. Receiving Care-of Test Init Messages. . . . 80
9.4.3. Sending Home Test Messages. . . . . . . . . 80
9.4.4. Sending Care-of Test Messages . . . . . . . 81
9.5 Processing Bindings . . . . . . . . . . . . . . . . 81
9.5.1. Receiving Binding Updates . . . . . . . . . 81
9.5.2. Requests to Cache a Binding . . . . . . . . 84
9.5.3. Requests to Delete a Binding. . . . . . . . 84
9.5.4. Sending Binding Acknowledgements. . . . . . 85
9.5.5. Sending Binding Refresh Requests. . . . . . 86
9.6. Cache Replacement Policy. . . . . . . . . . . . . . 86
10. Home Agent Operation . . . . . . . . . . . . . . . . . . . 87
10.1. Conceptual Data Structures. . . . . . . . . . . . . 87
10.2. Processing Mobility Headers . . . . . . . . . . . . 88
10.3. Processing Bindings . . . . . . . . . . . . . . . . 88
10.3.1. Primary Care-of Address Registration. . . . 88
10.3.2. Primary Care-of Address De-Registration . . 92
10.4. Packet Processing . . . . . . . . . . . . . . . . . 94
10.4.1. Intercepting Packets for a Mobile Node. . . 94
10.4.2. Processing Intercepted Packets. . . . . . . 95
10.4.3. Multicast Membership Control. . . . . . . . 96
6.4. 2ルート設定ヘッダー. . . . . . . . . . . . . . . 53 6.4.1をタイプしてください。 形式。 . . . . . . . . . . . . . . . . . . 54 6.5. ICMPホームエージェントアドレス発見要求メッセージ. 55 6.6。 ICMPホームエージェントアドレス発見応答メッセージ. . 56 6.7。 ICMPのモバイル接頭語懇願メッセージ・フォーマット。 . . 57 6.8. ICMPのモバイル接頭語広告メッセージ・フォーマット. . 59 7。 IPv6隣人発見. . . . . . . . . 61 7.1への変更。 変更されたルータ通知メッセージ・フォーマット。 . . . 61 7.2. 変更された接頭語情報オプション形式. . . . . 62 7.3。 新しい広告間隔オプション形式。 . . . . . 64 7.4. 新しいホームエージェント情報オプション形式。 . . . . . 65 7.5. 送付ルータ通知への変化。 . . . . . 67 8. IPv6ノード. . . . . . . . . . . 69 8.1のタイプのための要件。 すべてのIPv6ノード。 . . . . . . . . . . . . . . . . . . 69 8.2. 経路最適化のサポートがあるIPv6ノード。 . . 69 8.3. すべてのIPv6ルータ。 . . . . . . . . . . . . . . . . . 71 8.4. IPv6ホームのエージェント。 . . . . . . . . . . . . . . . . . 71 8.5. IPv6のモバイルノード. . . . . . . . . . . . . . . . . 73 9。 通信員ノード手術. . . . . . . . . . . . . . . 74 9.1。 概念的なデータ構造。 . . . . . . . . . . . . 74 9.2. 移動性ヘッダー. . . . . . . . . . . . 75 9.3を処理します。 パケット処理. . . . . . . . . . . . . . . . . 76 9.3.1。 ホームアドレスオプションでパケットを受けます。 76 9.3.2. モバイルノードにパケットを送ります。 . . . . . 77 9.3.3. 拘束力があるエラーメッセージを送ります。 . . . . . . 78 9.3.4. ICMPエラーメッセージ. . . . . . . 79 9.4を受け取ります。 手順をRoutabilityに返してください。 . . . . . . . . . . . 79 9.4.1. ホームテストイニットメッセージ. . . . . 80 9.4.2を受け取ります。 受信、注意、-、イニットメッセージをテストしてください。 . . . 80 9.4.3. ホームテストメッセージを送ります。 . . . . . . . . 80 9.4.4. 発信、注意、-、メッセージ. . . . . . . 81 9.5処理結合. . . . . . . . . . . . . . . . 81 9.5.1をテストしてください。 .2に拘束力があるアップデート. . . . . . . . . 81 9.5を受けます。 .3に結合. . . . . . . . 84 9.5をキャッシュするという要求 結合を削除するという要求。 . . . . . . . 84 9.5.4. 拘束力がある承認を送ります。 . . . . . 85 9.5.5. 結合を送って、要求をリフレッシュしてください。 . . . . . 86 9.6. 交換方針をキャッシュしてください。 . . . . . . . . . . . . . 86 10. ホームエージェント操作. . . . . . . . . . . . . . . . . . . 87 10.1。 概念的なデータ構造。 . . . . . . . . . . . . 87 10.2. 移動性ヘッダー. . . . . . . . . . . . 88 10.3を処理します。 結合. . . . . . . . . . . . . . . . 88 10.3.1を処理します。 初期医療、-、登録を記述してください。 . . . 88 10.3.2. 初期医療、-、.92 10.4に反-登録を記述してください。 パケット処理. . . . . . . . . . . . . . . . . 94 10.4.1。 モバイルノードのためにパケットを妨害します。 . . 94 10.4.2. 処理はパケットを妨害しました。 . . . . . . 95 10.4.3. マルチキャスト会員資格コントロール。 . . . . . . . 96
Johnson, et al. Standard Track [Page 3] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[3ページ]のRFC3775移動性サポート
10.4.4. Stateful Address Autoconfiguration. . . . . 98
10.4.5. Handling Reverse Tunneled Packets . . . . . 98
10.4.6. Protecting Return Routability Packets . . . 99
10.5. Dynamic Home Agent Address Discovery. . . . . . . . 99
10.5.1. Receiving Router Advertisement Messages . . 100
10.6. Sending Prefix Information to the Mobile Node . . . 102
10.6.1. List of Home Network Prefixes . . . . . . . 102
10.6.2. Scheduling Prefix Deliveries. . . . . . . . 102
10.6.3. Sending Advertisements. . . . . . . . . . . 104
10.6.4. Lifetimes for Changed Prefixes. . . . . . . 105
11. Mobile Node Operation. . . . . . . . . . . . . . . . . . . 105
11.1. Conceptual Data Structures. . . . . . . . . . . . . 105
11.2. Processing Mobility Headers . . . . . . . . . . . . 107
11.3. Packet Processing . . . . . . . . . . . . . . . . . 107
11.3.1. Sending Packets While Away from Home. . . . 107
11.3.2. Interaction with Outbound IPsec Processing. 110
11.3.3. Receiving Packets While Away from Home. . . 112
11.3.4. Routing Multicast Packets . . . . . . . . . 114
11.3.5. Receiving ICMP Error Messages . . . . . . . 115
11.3.6. Receiving Binding Error Messages. . . . . . 116
11.4. Home Agent and Prefix Management. . . . . . . . . . 117
11.4.1. Dynamic Home Agent Address Discovery. . . . 117
11.4.2. Sending Mobile Prefix Solicitations . . . . 118
11.4.3. Receiving Mobile Prefix Advertisements. . . 118
11.5. Movement. . . . . . . . . . . . . . . . . . . . . . 120
11.5.1. Movement Detection. . . . . . . . . . . . . 120
11.5.2. Forming New Care-of Addresses . . . . . . . 122
11.5.3. Using Multiple Care-of Addresses. . . . . . 123
11.5.4. Returning Home. . . . . . . . . . . . . . . 124
11.6. Return Routability Procedure. . . . . . . . . . . . 126
11.6.1. Sending Test Init Messages. . . . . . . . . 126
11.6.2. Receiving Test Messages . . . . . . . . . . 127
11.6.3. Protecting Return Routability Packets . . . 128
11.7. Processing Bindings . . . . . . . . . . . . . . . . 128
11.7.1. Sending Binding Updates to the Home Agent . 128
11.7.2. Correspondent Registration. . . . . . . . . 131
11.7.3. Receiving Binding Acknowledgements. . . . . 134
11.7.4. Receiving Binding Refresh Requests. . . . . 136
11.8. Retransmissions and Rate Limiting . . . . . . . . . 137
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 138
13. Protocol Configuration Variables . . . . . . . . . . . . . 138
14. IANA Considerations. . . . . . . . . . . . . . . . . . . . 139
15. Security Considerations. . . . . . . . . . . . . . . . . . 142
15.1. Threats . . . . . . . . . . . . . . . . . . . . . . 142
15.2. Features. . . . . . . . . . . . . . . . . . . . . . 144
15.3. Binding Updates to Home Agent . . . . . . . . . . . 145
15.4. Binding Updates to Correspondent Nodes. . . . . . . 148
15.4.1. Overview. . . . . . . . . . . . . . . . . . 149
10.4.4. Statefulは自動構成を記述します。 . . . . 98 10.4.5. 取り扱い逆はパケット. . . . . 98 10.4.6にトンネルを堀りました。 リターンRoutabilityパケット. . . 99 10.5を保護します。 ダイナミックなホームエージェントアドレス発見。 . . . . . . . 99 10.5.1. ルータ通知メッセージ. . 100 10.6を受け取ります。 モバイルノード. . . 102 10.6.1に接頭語情報を送ります。 ホームネットワークのリストは.2に.10210.6を前に置きます。 接頭語配送の計画をします。 . . . . . . . 102 10.6.3. 広告を送ります。 . . . . . . . . . . 104 10.6.4. 変えられた接頭語のための生涯。 . . . . . . 105 11. モバイルノード手術。 . . . . . . . . . . . . . . . . . . 105 11.1. 概念的なデータ構造。 . . . . . . . . . . . . 105 11.2. 移動性ヘッダー. . . . . . . . . . . . 107 11.3を処理します。 パケット処理. . . . . . . . . . . . . . . . . 107 11.3.1。 ホームから離れている間、パケットを送ります。 . . . 107 11.3.2. 外国行きのIPsec処理との相互作用。 110 11.3.3. ホームから離れている間、パケットを受けます。 . . 112 11.3.4. マルチキャストパケット. . . . . . . . . 114 11.3.5を発送します。 ICMPエラーメッセージ. . . . . . . 115 11.3.6を受け取ります。 拘束力があるエラーメッセージを受け取ります。 . . . . . 116 11.4. ホームのエージェントと接頭語管理。 . . . . . . . . . 117 11.4.1. ダイナミックなホームエージェントアドレス発見。 . . . 117 11.4.2. モバイル接頭語懇願. . . . 118 11.4.3を送ります。 モバイル接頭語広告を受け取ります。 . . 118 11.5. 動き。 . . . . . . . . . . . . . . . . . . . . . 120 11.5.1. 動き検出。 . . . . . . . . . . . . 120 11.5.2. 新しい状態で形成する、注意、-、.3に.12211.5を記述します。 倍数を使用する、注意、-、アドレス。 . . . . . 123 11.5.4. ホームを返します。 . . . . . . . . . . . . . . 124 11.6. 手順をRoutabilityに返してください。 . . . . . . . . . . . 126 11.6.1. テストイニットメッセージを送ります。 . . . . . . . . 126 11.6.2. テストメッセージ. . . . . . . . . . 127 11.6.3を受け取ります。 リターンRoutabilityパケット. . . 128 11.7を保護します。 結合. . . . . . . . . . . . . . . . 128 11.7.1を処理します。 送付結合はエージェント. 128 11.7.2をホームにアップデートします。 通信員登録。 . . . . . . . . 131 11.7.3. 拘束力がある承認を受けます。 . . . . 134 11.7.4. 結合を受けて、要求をリフレッシュしてください。 . . . . 136 11.8. Retransmissionsとレート制限. . . . . . . . . 137 12。 定数. . . . . . . . . . . . . . . . . . . . 138 13について議定書の中で述べてください。 構成変数. . . . . . . . . . . . . 138 14について議定書の中で述べてください。 IANA問題。 . . . . . . . . . . . . . . . . . . . 139 15. セキュリティ問題。 . . . . . . . . . . . . . . . . . 142 15.1. 脅威. . . . . . . . . . . . . . . . . . . . . . 142 15.2。 特徴。 . . . . . . . . . . . . . . . . . . . . . 144 15.3. ホームのエージェント. . . . . . . . . . . 145 15.4にアップデートを縛ります。 通信員ノードにアップデートを縛ります。 . . . . . . 148 15.4.1. 概観。 . . . . . . . . . . . . . . . . . 149
Johnson, et al. Standard Track [Page 4] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[4ページ]のRFC3775移動性サポート
15.4.2. Achieved Security Properties. . . . . . . . 149
15.4.3. Comparison to Regular IPv6 Communications . 150
15.4.4. Replay Attacks. . . . . . . . . . . . . . . 152
15.4.5. Denial-of-Service Attacks . . . . . . . . . 152
15.4.6. Key Lengths . . . . . . . . . . . . . . . . 153
15.5. Dynamic Home Agent Address Discovery. . . . . . . . 154
15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . 155
15.7. Tunneling via the Home Agent. . . . . . . . . . . . 155
15.8. Home Address Option . . . . . . . . . . . . . . . . 156
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . 156
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . 157
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 157
18. References . . . . . . . . . . . . . . . . . . . . . . . . 158
18.1. Normative References. . . . . . . . . . . . . . . . 158
18.2. Informative References. . . . . . . . . . . . . . . 159
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 161
A.1. Piggybacking. . . . . . . . . . . . . . . . . . . . 161
A.2. Triangular Routing. . . . . . . . . . . . . . . . . 161
A.3. New Authorization Methods . . . . . . . . . . . . . 161
A.4. Dynamically Generated Home Addresses. . . . . . . . 161
A.5. Remote Home Address Configuration . . . . . . . . . 162
A.6. Neighbor Discovery Extensions . . . . . . . . . . . 163
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 164
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 165
15.4.2. セキュリティの特性を獲得しました。 . . . . . . . 149 15.4.3. 通常のIPv6コミュニケーション. 150 15.4.4との比較。 反射攻撃。 . . . . . . . . . . . . . . 152 15.4.5. サービス不能攻撃. . . . . . . . . 152 15.4.6。 キー長. . . . . . . . . . . . . . . . 153 15.5。 ダイナミックなホームエージェントアドレス発見。 . . . . . . . 154 15.6. モバイル接頭語発見. . . . . . . . . . . . . . 155 15.7。 ホームのエージェントを通して、トンネルを堀ります。 . . . . . . . . . . . 155 15.8. ホームアドレスオプション. . . . . . . . . . . . . . . . 156 15.9。 2ルート設定ヘッダー. . . . . . . . . . . . . . . 156 16をタイプしてください。 貢献者. . . . . . . . . . . . . . . . . . . . . . . 157 17。 承認. . . . . . . . . . . . . . . . . . . . . 157 18。 参照. . . . . . . . . . . . . . . . . . . . . . . . 158 18.1。 引用規格。 . . . . . . . . . . . . . . . 158 18.2. 有益な参照。 . . . . . . . . . . . . . . 159 付録A.未来の延期. . . . . . . . . . . . . . . . . 161A.1。 便乗。 . . . . . . . . . . . . . . . . . . . 161 A.2。 三角形のルート設定。 . . . . . . . . . . . . . . . . 161 A.3。 新しい認可方法. . . . . . . . . . . . . 161A.4。 ダイナミックに発生したホームアドレス。 . . . . . . . 161 A.5。 リモートホームアドレス構成. . . . . . . . . 162A.6。 隣人発見拡大. . . . . . . . . . . 163作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . 164 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 165
1. Introduction
1. 序論
This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Without specific support for mobility in IPv6 [11], packets destined to a mobile node would not be able to reach it while the mobile node is away from its home link. In order to continue communication in spite of its movement, a mobile node could change its IP address each time it moves to a new link, but the mobile node would then not be able to maintain transport and higher-layer connections when it changes location. Mobility support in IPv6 is particularly important, as mobile computers are likely to account for a majority or at least a substantial fraction of the population of the Internet during the lifetime of IPv6.
このドキュメントはノードがIPv6インターネットを動き回っている間に届いたままで残ることができるプロトコルを指定します。 IPv6[11]の移動性の特定のサポートがなければ、モバイルノードがホームのリンクから離れている間、モバイルノードに運命づけられたパケットはそれに達することができないでしょう。 動きにもかかわらず、コミュニケーションを続けるために、モバイルノードは新しいリンクに移行するたびにIPアドレスを変えるかもしれませんが、その時位置を変えるとき、モバイルノードは輸送と、より高い層の接続を維持できないでしょう。 IPv6での移動性サポートは特に重要です、モバイルコンピュータがIPv6の生涯インターネットの人口の大部分か少なくともかなりの部分を占めそうなとき。
The protocol defined in this document, known as Mobile IPv6, allows a mobile node to move from one link to another without changing the mobile node's "home address". Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a
モバイルIPv6として知られているこのドキュメントで定義されたプロトコルで、モバイルノードの「ホームアドレス」を変えないで、モバイルノードは別のものへの1個のリンクから移行できます。 パケットは、インターネットへのモバイルノードの現在の接着点にかかわらずこのアドレスを使用することでモバイルノードに発送されるかもしれません。 また、モバイルノードは、aに移行した後に(静止するかモバイル)の他のノードとコミュニケートし続けるかもしれません。
Johnson, et al. Standard Track [Page 5] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[5ページ]のRFC3775移動性サポート
new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications.
新しいリンク。 ホームのリンクから遠くのモバイルノードの動きは、その結果、輸送するためにわかりやすくて、より高い層のプロトコルとアプリケーションです。
The Mobile IPv6 protocol is just as suitable for mobility across homogeneous media as for mobility across heterogeneous media. For example, Mobile IPv6 facilitates node movement from one Ethernet segment to another as well as it facilitates node movement from an Ethernet segment to a wireless LAN cell, with the mobile node's IP address remaining unchanged in spite of such movement.
モバイルIPv6プロトコルは種々雑多なメディアの向こう側に均質のメディアの向こう側に移動性に移動性とちょうど同じくらい適しています。 例えば、そのような動きにもかかわらず、イーサネットセグメントから無線LANセルまでのノード運動を容易にするモバイルノードのIPアドレスを変わりがなく、モバイルIPv6はまた、1つのイーサネットセグメントから別のセグメントまでのノード運動を容易にします。
One can think of the Mobile IPv6 protocol as solving the network- layer mobility management problem. Some mobility management applications -- for example, handover among wireless transceivers, each of which covers only a very small geographic area -- have been solved using link-layer techniques. For example, in many current wireless LAN products, link-layer mobility mechanisms allow a "handover" of a mobile node from one cell to another, re-establishing link-layer connectivity to the node in each new location.
人はネットワーク層の移動性管理問題を解決するとモバイルIPv6プロトコルを考えることができます。 いくつかの移動性管理アプリケーション(例えば、それのそれぞれが非常に小さい地理的な領域だけをカバーするワイヤレスのトランシーバーの中の引き渡し)が、リンクレイヤのテクニックを使用することで解決されました。 例えば、製品であり多くの現在の無線LANで、リンクレイヤ移動性メカニズムは「引き渡し」を許容します。モバイル1つのセルからそれぞれの新しい位置のノードにリンクレイヤの接続性を復職させる別のセルまでのノードについて。
Mobile IPv6 does not attempt to solve all general problems related to the use of mobile computers or wireless networks. In particular, this protocol does not attempt to solve:
モバイルIPv6は、モバイルコンピュータかワイヤレス・ネットワークの使用に関連するすべての一般的問題を解決するのを試みません。 特に、このプロトコルは、以下を解決するのを試みません。
o Handling links with unidirectional connectivity or partial
reachability, such as the hidden terminal problem where a host is
hidden from only some of the routers on the link.
o 取り扱いは単方向の接続性か部分的な可到達性にリンクされます、リンクの上のルータのいくつかだけホストを隠される隠された端末の問題などのように。
o Access control on a link being visited by a mobile node.
o モバイルノードによって訪問されるリンクの上にコントロールにアクセスしてください。
o Local or hierarchical forms of mobility management (similar to
many current link-layer mobility management solutions).
o 地方的、または、階層的な形式の移動性管理(多くの現在のリンクレイヤ移動性運営方法と同様の)。
o Assistance for adaptive applications.
o 適応型のアプリケーションのための支援。
o Mobile routers.
o モバイルルータ。
o Service Discovery.
o 発見を修理してください。
o Distinguishing between packets lost due to bit errors vs. network
congestion.
o パケットを見分けるのは噛み付いている誤りのためネットワークの混雑に対して負けました。
2. Comparison with Mobile IP for IPv4
2. IPv4のためのモバイルIPとの比較
The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both from the experiences gained from the development of Mobile IP support in IPv4 (Mobile IPv4) [22, 23, 24], and from the opportunities provided by IPv6. Mobile IPv6 thus shares many features with Mobile
IPv6(モバイルIPv6)が経験のおかげで得することの両方であるのにおけるモバイルIPサポートのデザインはモバイルIPサポートの開発からIPv4(モバイルIPv4)[22、23、24]と、そして、IPv6によって提供された機会から得ました。 その結果、モバイルIPv6は多くの特徴をモバイルと共有します。
Johnson, et al. Standard Track [Page 6] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[6ページ]のRFC3775移動性サポート
IPv4, but is integrated into IPv6 and offers many other improvements. This section summarizes the major differences between Mobile IPv4 and Mobile IPv6:
IPv4、IPv6と統合されて、他の多くの改良を提供します。 このセクションはモバイルIPv4とモバイルIPv6の主要な違いをまとめます:
o There is no need to deploy special routers as "foreign agents", as
in Mobile IPv4. Mobile IPv6 operates in any location without any
special support required from the local router.
o 「外国人のエージェント」として特別なルータを配布する必要は全くモバイルIPv4のようにありません。 モバイルIPv6はどんな位置でもローカルルータから必要である特別なサポートなしで作動します。
o Support for route optimization is a fundamental part of the
protocol, rather than a nonstandard set of extensions.
o 経路最適化のサポートは標準的でない拡大よりむしろプロトコルの基本的な部分です。
o Mobile IPv6 route optimization can operate securely even without
pre-arranged security associations. It is expected that route
optimization can be deployed on a global scale between all mobile
nodes and correspondent nodes.
o モバイルIPv6経路最適化は根回しされたセキュリティ協会がなくてもしっかりと作動できます。 世界的規模ですべてのモバイルノードと通信員ノードの間で経路最適化を配布することができると予想されます。
o Support is also integrated into Mobile IPv6 for allowing route
optimization to coexist efficiently with routers that perform
"ingress filtering" [26].
o また、サポートは、経路最適化が効率的に「イングレスフィルタリング」[26]を実行するルータと共存するのを許容するためにモバイルIPv6と統合されます。
o The IPv6 Neighbor Unreachability Detection assures symmetric
reachability between the mobile node and its default router in the
current location.
o IPv6 Neighbor Unreachability Detectionは現在の位置でモバイルノードとそのデフォルトルータの間の左右対称の可到達性を保証します。
o Most packets sent to a mobile node while away from home in Mobile
IPv6 are sent using an IPv6 routing header rather than IP
encapsulation, reducing the amount of resulting overhead compared
to Mobile IPv4.
o モバイルIPv6のホームから離れていますが、モバイルノードに送られたほとんどのパケットにIPカプセル化よりむしろIPv6ルーティングヘッダーを使用させます、モバイルIPv4と比べて、結果として起こるオーバーヘッドの量を減少させて。
o Mobile IPv6 is decoupled from any particular link layer, as it
uses IPv6 Neighbor Discovery [12] instead of ARP. This also
improves the robustness of the protocol.
o ARPの代わりにIPv6 Neighborディスカバリー[12]を使用するとき、モバイルIPv6はどんな特定のリンクレイヤからも衝撃を吸収されます。 また、これはプロトコルの丈夫さを改良します。
o The use of IPv6 encapsulation (and the routing header) removes the
need in Mobile IPv6 to manage "tunnel soft state".
o IPv6カプセル化(そして、ルーティングヘッダー)の使用は「トンネル軟性国家」を管理するモバイルIPv6の必要性を取り除きます。
o The dynamic home agent address discovery mechanism in Mobile IPv6
returns a single reply to the mobile node. The directed broadcast
approach used in IPv4 returns separate replies from each home
agent.
o モバイルIPv6のダイナミックなホームエージェントアドレス発見メカニズムはただ一つの回答をモバイルノードに返します。 IPv4で使用される指示された放送アプローチはそれぞれのホームのエージェントから別々の回答を返します。
3. Terminology
3. 用語
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
Johnson, et al. Standard Track [Page 7] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[7ページ]のRFC3775移動性サポート
3.1. General Terms
3.1. 一般項
IP
IP
Internet Protocol Version 6 (IPv6).
インターネットプロトコルバージョン6(IPv6)。
node
ノード
A device that implements IP.
IPを実装するデバイス。
router
ルータ
A node that forwards IP packets not explicitly addressed to
itself.
明らかにそれ自体に扱われなかったIPパケットを進めるノード。
unicast routable address
ユニキャスト発送可能アドレス
An identifier for a single interface such that a packet sent to it
from another IPv6 subnet is delivered to the interface identified
by that address. Accordingly, a unicast routable address must
have either a global or site-local scope (but not link-local).
シングルのための識別子は、別のIPv6サブネットからそれに送られたパケットがそのアドレスによって特定されたインタフェースに提供されるように、連結します。 それに従って、ユニキャスト発送可能アドレスはグローバルであるかサイト地方の範囲と(リンク地方でない)であるのにどちらかを持たなければなりません。
host
ホスト
Any node that is not a router.
ルータでないどんなノード。
link
リンク
A communication facility or medium over which nodes can
communicate at the link layer, such as an Ethernet (simple or
bridged). A link is the layer immediately below IP.
通信機器か媒体がリンクレイヤでどのノードの上で交信できるか、イーサネット(簡単であるかブリッジしている)のように。 リンクはIPのすぐ下の層です。
interface
インタフェース
A node's attachment to a link.
リンクへのノードの付属。
subnet prefix
サブネット接頭語
A bit string that consists of some number of initial bits of an IP
address.
少し、それが何らかの数から成るストリングはIPアドレスのビットに頭文字をつけます。
interface identifier
インタフェース識別子
A number used to identify a node's interface on a link. The
interface identifier is the remaining low-order bits in the node's
IP address after the subnet prefix.
数は以前はリンクの上によくノードのインタフェースを特定していました。 インタフェース識別子はサブネット接頭語の後のノードのIPアドレスの残っている下位のビットです。
Johnson, et al. Standard Track [Page 8] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[8ページ]のRFC3775移動性サポート
link-layer address
リンクレイヤアドレス
A link-layer identifier for an interface, such as IEEE 802
addresses on Ethernet links.
IEEE802などのインタフェースのためのリンクレイヤ識別子はイーサネットでリンクを扱います。
packet
パケット
An IP header plus payload.
IPヘッダーとペイロード。
security association
セキュリティ協会
An IPsec security association is a cooperative relationship formed
by the sharing of cryptographic keying material and associated
context. Security associations are simplex. That is, two
security associations are needed to protect bidirectional traffic
between two nodes, one for each direction.
IPsecセキュリティ協会は暗号の合わせることの材料と関連文脈の共有で形成された協力体制です。 セキュリティ協会はシンプレクスです。 すなわち、2つのセキュリティ協会が、2つのノードの間の双方向のトラフィック、各方向あたり1つを保護するのに必要です。
security policy database
安全保障政策データベース
A database that specifies what security services are to be offered
to IP packets and in what fashion.
どんなセキュリティー・サービスがパケットとどんなファッションでIPに提供されるかことであるかと指定するデータベース。
destination option
目的地オプション
Destination options are carried by the IPv6 Destination Options
extension header. Destination options include optional
information that need be examined only by the IPv6 node given as
the destination address in the IPv6 header, not by routers in
between. Mobile IPv6 defines one new destination option, the Home
Address destination option (see Section 6.3).
目的地オプションはIPv6 Destination Options拡張ヘッダーによって運ばれます。 目的地オプションは必要性がルータで与えるのではなく、送付先アドレスとしてIPv6ヘッダーで中間で与えられたIPv6ノードだけによって調べられるという任意の情報を含んでいます。 モバイルIPv6は1つの新しい目的地オプション、ホームAddress目的地オプションを定義します(セクション6.3を見てください)。
routing header
ルーティングヘッダー
A routing header may be present as an IPv6 header extension, and
indicates that the payload has to be delivered to a destination
IPv6 address in some way that is different from what would be
carried out by standard Internet routing. In this document, use
of the term "routing header" typically refers to use of a type 2
routing header, as specified in Section 6.4.
ルーティングヘッダーは、IPv6ヘッダー拡張子として存在しているかもしれなくて、ペイロードが何らかの標準のインターネット・ルーティングによって行われるものと異なった方法で送付先IPv6アドレスに提供されなければならないのを示します。 本書では、「ルーティングヘッダー」という用語の使用はタイプ2ルーティングヘッダーの使用について通常言及します、セクション6.4で指定されるように。
"|" (concatenation)
"|" (連結)
Some formulas in this specification use the symbol "|" to indicate
bytewise concatenation, as in A | B. This concatenation requires
that all of the octets of the datum A appear first in the result,
followed by all of the octets of the datum B.
「この仕様によるいくつかの定石がシンボルを使用します」|「示す、A」のように連結をbytewiseします。| B。 この連結は、データAの八重奏のすべてが最初にデータBの八重奏のすべてがあとに続いた結果に現れるのを必要とします。
Johnson, et al. Standard Track [Page 9] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[9ページ]のRFC3775移動性サポート
First (size, input)
1番目(サイズ入力されて、
Some formulas in this specification use a functional form "First
(size, input)" to indicate truncation of the "input" data so that
only the first "size" bits remain to be used.
この仕様によるいくつかの定石が「入力」データのトランケーションを示すのに機能的なフォーム「1(サイズ、入力)番目」を使用するので、最初の「サイズ」ビットだけが使用されるために残っています。
3.2. Mobile IPv6 Terms
3.2. モバイルIPv6用語
home address
ホームアドレス
A unicast routable address assigned to a mobile node, used as the
permanent address of the mobile node. This address is within the
mobile node's home link. Standard IP routing mechanisms will
deliver packets destined for a mobile node's home address to its
home link. Mobile nodes can have multiple home addresses, for
instance when there are multiple home prefixes on the home link.
モバイルノードの本籍として使用されるモバイルノードに割り当てられたユニキャスト発送可能アドレス。 モバイルノードのホームのリンクの中にこのアドレスはあります。 標準のIPルーティングメカニズムはモバイルノードのホームアドレスのためにホームのリンクに運命づけられたパケットを提供するでしょう。 モバイルノードは複数のホームアドレスを持つことができます、例えば、ホームの上に複数のホーム接頭語があるときには、リンクしてください。
home subnet prefix
ホームサブネット接頭語
The IP subnet prefix corresponding to a mobile node's home
address.
モバイルノードのホームアドレスに対応するIPサブネット接頭語。
home link
ホームのリンク
The link on which a mobile node's home subnet prefix is defined.
モバイルノードのホームサブネット接頭語が定義されるリンク。
mobile node
モバイルノード
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
ホームアドレスでまだ届いている間に別のものへの1個のリンクから接着点を変えることができるノード。
movement
動き
A change in a mobile node's point of attachment to the Internet
such that it is no longer connected to the same link as it was
previously. If a mobile node is not currently attached to its
home link, the mobile node is said to be "away from home".
モバイルノードのものにおける変化は、それがもう以前に接続されたように同じリンクに接続されないように、インターネットへの付属を指します。 モバイルノードが現在ホームのリンクに添付されないなら、モバイルノードは「ホームから、離れている」と言われます。
L2 handover
L2引き渡し
A process by which the mobile node changes from one link-layer
connection to another. For example, a change of wireless access
point is an L2 handover.
モバイルノードが1つのリンクレイヤ接続から別のものに変化するプロセス。 例えば、ワイヤレス・アクセスポイントの変化はL2引き渡しです。
Johnson, et al. Standard Track [Page 10] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[10ページ]のRFC3775移動性サポート
L3 handover
L3引き渡し
Subsequent to an L2 handover, a mobile node detects a change in an
on-link subnet prefix that would require a change in the primary
care-of address. For example, a change of access router
subsequent to a change of wireless access point typically results
in an L3 handover.
L2引き渡しにその後です、モバイルノードがリンクの上の中で変化を必要とするサブネット接頭語における変化を検出する、初期医療、-、アドレス 例えば、ワイヤレス・アクセスポイントの変化へのその後のアクセスルータの変化はL3引き渡しを通常もたらします。
correspondent node
通信員ノード
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
モバイルノードが交信している同輩ノード。 通信員ノードは、モバイルである、または静止しているかもしれません。
foreign subnet prefix
外国サブネット接頭語
Any IP subnet prefix other than the mobile node's home subnet
prefix.
モバイルノードのホームサブネット接頭語以外のどんなIPサブネット接頭語。
foreign link
外国リンク
Any link other than the mobile node's home link.
モバイルノードのホームのリンク以外のどんなリンク。
care-of address
注意、-、アドレス
A unicast routable address associated with a mobile node while
visiting a foreign link; the subnet prefix of this IP address is a
foreign subnet prefix. Among the multiple care-of addresses that
a mobile node may have at any given time (e.g., with different
subnet prefixes), the one registered with the mobile node's home
agent for a given home address is called its "primary" care-of
address.
ユニキャスト発送可能アドレスは外国リンクを訪問している間、モバイルノードと交際しました。 このIPアドレスのサブネット接頭語は外国サブネット接頭語です。 倍数、注意、-、モバイルノードがその時々で(例えば、異なったサブネット接頭語で)持っているかもしれないアドレス、与えられたホームアドレスのためにモバイルノードのホームのエージェントに示されたのが呼ばれる、「予備選挙」、注意、-、アドレス
home agent
ホームのエージェント
A router on a mobile node's home link with which the mobile node
has registered its current care-of address. While the mobile node
is away from home, the home agent intercepts packets on the home
link destined to the mobile node's home address, encapsulates
them, and tunnels them to the mobile node's registered care-of
address.
モバイルノードが登録したモバイルノードのホームのリンクの上のルータ、電流、注意、-、アドレス ホームのエージェントが登録されたモバイルノードのものにモバイルノードが家にいないのですが、モバイルノードのホームアドレスに運命づけられたホームのリンクの上にパケットを妨害して、それらをカプセル化して、それらにトンネルを堀る、注意、-、アドレス。
binding
付きます。
The association of the home address of a mobile node with a care-
of address for that mobile node, along with the remaining lifetime
of that association.
その協会の残っている生涯に伴うそのモバイルノードのためのアドレスの注意があるモバイルノードに関するホームアドレスの協会。
Johnson, et al. Standard Track [Page 11] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[11ページ]のRFC3775移動性サポート
registration
登録
The process during which a mobile node sends a Binding Update to
its home agent or a correspondent node, causing a binding for the
mobile node to be registered.
モバイルノードがホームのエージェントか通信員ノードにBinding Updateを送る登録されるべきモバイルノードのための結合を引き起こすプロセス。
mobility message
移動性メッセージ
A message containing a Mobility Header (see Section 6.1).
Mobility Header(セクション6.1を見る)を含むメッセージ。
binding authorization
拘束力がある承認
Correspondent registration needs to be authorized to allow the
recipient to believe that the sender has the right to specify a
new binding.
通信員登録は、受取人が、新しい結合を指定するために送付者が権利があると信じているのを許容するのが認可される必要があります。
return routability procedure
リターンroutability手順
The return routability procedure authorizes registrations by the
use of a cryptographic token exchange.
リターンroutability手順は暗号のトークン交換の使用で登録証明書を認可します。
correspondent registration
通信員登録
A return routability procedure followed by a registration, run
between the mobile node and a correspondent node.
モバイルノードと通信員ノードの間で実行された登録でリターンroutability手順は従いました。
home registration
本国登録
A registration between the mobile node and its home agent,
authorized by the use of IPsec.
IPsecの使用で権限を与えられたモバイルノードとそのホームのエージェントの間の登録。
nonce
一回だけ
Nonces are random numbers used internally by the correspondent
node in the creation of keygen tokens related to the return
routability procedure. The nonces are not specific to a mobile
node, and are kept secret within the correspondent node.
一回だけはリターンroutability手順に関連するkeygenトークンの作成における通信員ノードによって内部的に使用される乱数です。 一回だけは、モバイルノードに特定でなく、通信員ノードの中で秘密にされます。
nonce index
一回だけのインデックス
A nonce index is used to indicate which nonces have been used when
creating keygen token values, without revealing the nonces
themselves.
一回だけのインデックスはkeygenトークン値を作成するとき、どの一回だけが使用されたかを示すのに使用されます、一回だけ自体を明らかにしないで。
Johnson, et al. Standard Track [Page 12] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[12ページ]のRFC3775移動性サポート
cookie
クッキー
A cookie is a random number used by a mobile node to prevent
spoofing by a bogus correspondent node in the return routability
procedure.
クッキーはモバイルノードによって使用される、リターンroutability手順によるにせの通信員ノードでだますのを防ぐ乱数です。
care-of init cookie
注意、-、イニットクッキー
A cookie sent to the correspondent node in the Care-of Test Init
message, to be returned in the Care-of Test message.
クッキーが通信員ノードに発信した、Care、-、Test Initメッセージ、返す、Care、-、Testメッセージ
home init cookie
ホームイニットクッキー
A cookie sent to the correspondent node in the Home Test Init
message, to be returned in the Home Test message.
クッキーは、ホームTestメッセージで返すためにホームTest Initメッセージの通信員ノードに発信しました。
keygen token
keygenトークン
A keygen token is a number supplied by a correspondent node in the
return routability procedure to enable the mobile node to compute
the necessary binding management key for authorizing a Binding
Update.
keygenトークンはリターンroutability手順による通信員ノードによって供給された、モバイルノードがBinding Updateを認可するのに、主要な必要な拘束力がある管理を計算するのを可能にした数です。
care-of keygen token
注意、-、keygenトークン
A keygen token sent by the correspondent node in the Care-of Test
message.
keygenトークンが通信員ノードで発信した、Care、-、Testメッセージ。
home keygen token
ホームkeygenトークン
A keygen token sent by the correspondent node in the Home Test
message.
ホームTestメッセージの通信員ノードによって送られたkeygenトークン。
binding management key (Kbm)
拘束力がある管理キー(Kbm)
A binding management key (Kbm) is a key used for authorizing a
binding cache management message (e.g., Binding Update or Binding
Acknowledgement). Return routability provides a way to create a
binding management key.
拘束力がある管理キー(Kbm)は拘束力があるキャッシュ管理メッセージ(例えば、Binding UpdateかBinding Acknowledgement)を認可するのに使用されるキーです。 リターンroutabilityは拘束力がある管理キーを作成する方法を提供します。
4. Overview of Mobile IPv6
4. モバイルIPv6の概要
4.1. Basic Operation
4.1. 基本的な操作
A mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a
いつもモバイルノードがホームアドレスでアドレス可能であると予想されます、それが現在、ホームのリンクに添付されるか、または家にいないことにかかわらず。 「ホームアドレス」はホームのリンクでホームサブネット接頭語の中でモバイルノードに割り当てられたIPアドレスです。 aをゆったり過ごしてください。
Johnson, et al. Standard Track [Page 13] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[13ページ]のRFC3775移動性サポート
mobile node is at home, packets addressed to its home address are routed to the mobile node's home link, using conventional Internet routing mechanisms.
モバイルノードがホームにあって、ホームアドレスに扱われたパケットはモバイルノードのホームのリンクに発送されます、従来のインターネット・ルーティングメカニズムを使用して。
While a mobile node is attached to some foreign link away from home, it is also addressable at one or more care-of addresses. A care-of address is an IP address associated with a mobile node that has the subnet prefix of a particular foreign link. The mobile node can acquire its care-of address through conventional IPv6 mechanisms, such as stateless or stateful auto-configuration. As long as the mobile node stays in this location, packets addressed to this care-of address will be routed to the mobile node. The mobile node may also accept packets from several care-of addresses, such as when it is moving but still reachable at the previous link.
モバイルノードがホームから遠くのある外国リンクに添付されますが、また、それも、より1時にアドレス可能である、注意、-、アドレス。 注意、-、アドレス、特定の外国リンクがサブネット接頭語を持っているモバイルノードに関連しているIPアドレスがありますか? モバイルノードが取得できる、それ、注意、-、従来のIPv6メカニズムを通した状態がないかstatefulな自動構成などのアドレス。 モバイルノードがこの位置、これに扱われたパケットに滞在する限り、注意、-、アドレスはモバイルノードに発送されるでしょう。 また、モバイルノードがパケットを受け入れるかもしれない、数個、注意、-、アドレス、しかしそれがまだ移行している時のように、前のリンクで届きます。
The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message. The operation of the mobile node is specified in Section 11, and the operation of the home agent is specified in Section 10.
そして、モバイルノードのホームアドレスの間の協会、注意、-、アドレスはモバイルノードのための「結合」として知られています。 モバイルノードがホームから遠くに登録する、それ、初期医療、-、ルータがオンな状態でホームのリンクを扱ってください、モバイルノードのための「ホームのエージェント」として機能するようこのルータに要求して。 モバイルノードは、「拘束力があるアップデート」メッセージをホームのエージェントに送ることによって、この拘束力がある登録を実行します。 ホームのエージェントは、「拘束力がある承認」メッセージを返すことによって、モバイルノードに答えます。 モバイルノードの操作はセクション11で指定されます、そして、ホームのエージェントの操作はセクション10で指定されます。
Any node communicating with a mobile node is referred to in this document as a "correspondent node" of the mobile node, and may itself be either a stationary node or a mobile node. Mobile nodes can provide information about their current location to correspondent nodes. This happens through the correspondent registration. As a part of this procedure, a return routability test is performed in order to authorize the establishment of the binding. The operation of the correspondent node is specified in Section 9.
そして、モバイルノードとコミュニケートするどんなノードも本書ではモバイルノードの「通信員ノード」と呼ばれる、それ自体、静止したノードかモバイルノードのどちらかになるかもしれなくなってください。 モバイルノードはそれらの現在の位置の情報を通信員ノードに備えることができます。 これは通信員登録で起こります。 この手順の一部として、リターンroutabilityテストは、結合の設立を認可するために実行されます。 通信員ノードの操作はセクション9で指定されます。
There are two possible modes for communications between the mobile
node and a correspondent node. The first mode, bidirectional
tunneling, does not require Mobile IPv6 support from the
correspondent node and is available even if the mobile node has not
registered its current binding with the correspondent node. Packets
from the correspondent node are routed to the home agent and then
tunneled to the mobile node. Packets to the correspondent node are
tunneled from the mobile node to the home agent ("reverse tunneled")
and then routed normally from the home network to the correspondent
node. In this mode, the home agent uses proxy Neighbor Discovery to
intercept any IPv6 packets addressed to the mobile node's home
モバイルノードと通信員ノードとのコミュニケーションのための2つの可能なモードがあります。 最初のモード(双方向のトンネリング)は、通信員ノードからモバイルIPv6サポートを必要としないで、モバイルノードが通信員ノードに現在の結合を登録していなくても、利用可能です。 通信員ノードからのパケットは、ホームのエージェントに発送されて、次に、モバイルノードにトンネルを堀られます。 通常、通信員ノードへのパケットは、ホームネットワークから通信員ノードまでモバイルノードからホームのエージェント(「逆はトンネルを堀った」)までトンネルを堀られて、次に、発送されます。 このモードで、ホームのエージェントは、モバイルノードのホームに扱われたどんなIPv6パケットも妨害するのにプロキシNeighborディスカバリーを使用します。
Johnson, et al. Standard Track [Page 14] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[14ページ]のRFC3775移動性サポート
address (or home addresses) on the home link. Each intercepted packet is tunneled to the mobile node's primary care-of address. This tunneling is performed using IPv6 encapsulation [15].
ホームのリンクに関するアドレス(または、ホームアドレス)。 それぞれの妨害されたパケットがモバイルノードのものにトンネルを堀られる、初期医療、-、アドレス。 このトンネリングは、IPv6カプセル化[15]を使用することで実行されます。
The second mode, "route optimization", requires the mobile node to register its current binding at the correspondent node. Packets from the correspondent node can be routed directly to the care-of address of the mobile node. When sending a packet to any IPv6 destination, the correspondent node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node uses a new type of IPv6 routing header [11] (see Section 6.4) to route the packet to the mobile node by way of the care-of address indicated in this binding.
「経路最適化」という2番目のモードは、通信員ノードに現在の結合を登録するためにモバイルノードを必要とします。 直接通信員ノードからのパケットを発送できる、注意、-、モバイルノードのアドレス。 どんなIPv6の目的地にもパケットを送るとき、通信員ノードはパケットの送付先アドレスがないかどうかエントリーのためのキャッシュされた結合をチェックします。 を通してこの送付先アドレスのためのキャッシュされた結合が見つけられるなら、ノードがモバイルノードにパケットを発送するのに、新しいタイプのIPv6ルーティングヘッダー[11](セクション6.4を見ます)を使用する、注意、-、この結合で示されたアドレス。
Routing packets directly to the mobile node's care-of address allows the shortest communications path to be used. It also eliminates congestion at the mobile node's home agent and home link. In addition, the impact of any possible failure of the home agent or networks on the path to or from it is reduced.
直接モバイルノードのものへのルート設定パケット、注意、-、アドレスは、最も短いコミュニケーション経路が使用されるのを許容します。 また、それはモバイルノードのホームのエージェントとホームのリンクで混雑を排除します。 さらに、それかそれからの経路のホームのエージェントかネットワークのどんな可能な失敗の影響も減少します。
When routing packets directly to the mobile node, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. A new type of IPv6 routing header (see Section 6.4) is also added to the packet to carry the desired home address. Similarly, the mobile node sets the Source Address in the packet's IPv6 header to its current care-of addresses. The mobile node adds a new IPv6 "Home Address" destination option (see Section 6.3) to carry its home address. The inclusion of home addresses in these packets makes the use of the care-of address transparent above the network layer (e.g., at the transport layer).
直接モバイルノードへのルーティングパケット、通信員ノードがいつまでIPv6ヘッダーにDestination Addressをはめ込むか、注意、-、モバイルノードのアドレス。 また、新しいタイプのIPv6ルーティングヘッダー(セクション6.4を見る)は、必要なホームアドレスを運ぶためにパケットに加えられます。 同様に、モバイルノードがパケットのIPv6ヘッダーのSource Addressを設定する、電流、注意、-、アドレス モバイルノードは、ホームアドレスを運ぶために、新しいIPv6「ホームアドレス」目的地オプション(セクション6.3を見る)を加えます。 これらのパケットでのホームアドレスの包含が使用をする、注意、-、ネットワーク層(例えば、トランスポート層の)を超えて見え透いたアドレス。
Mobile IPv6 also provides support for multiple home agents, and a limited support for the reconfiguration of the home network. In these cases, the mobile node may not know the IP address of its own home agent, and even the home subnet prefixes may change over time. A mechanism, known as "dynamic home agent address discovery" allows a mobile node to dynamically discover the IP address of a home agent on its home link, even when the mobile node is away from home. Mobile nodes can also learn new information about home subnet prefixes through the "mobile prefix discovery" mechanism. These mechanisms are described starting from Section 6.5.
また、モバイルIPv6は複数のホームのエージェントのサポート、およびホームネットワークの再構成のための限定的なサポートを提供します。 これらの場合では、モバイルノードはそれ自身のホームのエージェントのIPアドレスを知らないかもしれません、そして、ホームサブネット接頭語さえ時間がたつにつれて、変化するかもしれません。 モバイルノードがホームのリンクの上に「ダイナミックなホームエージェントアドレス発見」でダイナミックにホームのエージェントのIPアドレスを発見できて知られていて、モバイルノードが家にいないと同等のメカニズム。 また、モバイルノードは「モバイル接頭語発見」メカニズムを通してホームサブネット接頭語に関する新情報を学ぶことができます。 セクション6.5から始めて、これらのメカニズムは説明されます。
4.2. New IPv6 Protocol
4.2. 新しいIPv6プロトコル
Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header (see Section 6.1). This Header is used to carry the following messages:
Mobility Headerを使用して、モバイルIPv6は新しいIPv6プロトコルを定義します(セクション6.1を見てください)。 このHeaderは以下のメッセージを伝えるのに使用されます:
Johnson, et al. Standard Track [Page 15] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[15ページ]のRFC3775移動性サポート
Home Test Init
ホームテストイニット
Home Test
ホームテスト
Care-of Test Init
注意、-、イニットをテストしてください。
Care-of Test
注意、-、テスト
These four messages are used to perform the return routability
procedure from the mobile node to a correspondent node. This
ensures authorization of subsequent Binding Updates, as described
in Section 5.2.5.
これらの4つのメッセージが、モバイルノードから通信員ノードまでリターンroutability手順を実行するのに使用されます。 これはセクション5.2.5で説明されるようにその後のBinding Updatesの承認を確実にします。
Binding Update
拘束力があるアップデート
A Binding Update is used by a mobile node to notify a
correspondent node or the mobile node's home agent of its current
binding. The Binding Update sent to the mobile node's home agent
to register its primary care-of address is marked as a "home
registration".
Binding Updateはモバイルノードによって使用されて、現在の結合について通信員ノードかモバイルノードのホームのエージェントに通知します。 Binding Updateが登録するためにモバイルノードのホームのエージェントに発信した、それ、初期医療、-、アドレス、「本国登録」として、マークされます。
Binding Acknowledgement
拘束力がある承認
A Binding Acknowledgement is used to acknowledge receipt of a
Binding Update, if an acknowledgement was requested in the Binding
Update, the binding update was sent to a home agent, or an error
occurred.
Binding AcknowledgementはBinding Updateの領収書を受け取ったことを知らせるのに使用されます、承認がBinding Updateで要求されたか、拘束力があるアップデートをホームのエージェントに送ったか、または誤りが発生したなら。
Binding Refresh Request
付いて、要求をリフレッシュしてください。
A Binding Refresh Request is used by a correspondent node to
request a mobile node to re-establish its binding with the
correspondent node. This message is typically used when the
cached binding is in active use but the binding's lifetime is
close to expiration. The correspondent node may use, for
instance, recent traffic and open transport layer connections as
an indication of active use.
Binding Refresh Requestは通信員ノードによって使用されて、通信員ノードで付くのを復職するようモバイルノードに要求します。 キャッシュされた結合が能動的使用であるとき、このメッセージは通常使用されますが、満了の近くに結合の寿命があります。 通信員ノードは能動的使用のしるしとして例えば、最近のトラフィックとオープンなトランスポート層接続を使用するかもしれません。
Binding Error
拘束力がある誤り
The Binding Error is used by the correspondent node to signal an
error related to mobility, such as an inappropriate attempt to use
the Home Address destination option without an existing binding.
Binding Errorは通信員ノードによって使用されて、移動性に関連する誤りに合図します、既存の結合なしでホームAddress目的地オプションを使用する不適当な試みのように。
Johnson, et al. Standard Track [Page 16] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[16ページ]のRFC3775移動性サポート
4.3. New IPv6 Destination Option
4.3. 新しいIPv6目的地オプション
Mobile IPv6 defines a new IPv6 destination option, the Home Address destination option. This option is described in detail in Section 6.3.
モバイルIPv6は新しいIPv6目的地オプション、ホームAddress目的地オプションを定義します。 このオプションはセクション6.3で詳細に説明されます。
4.4. New IPv6 ICMP Messages
4.4. 新しいIPv6 ICMPメッセージ
Mobile IPv6 also introduces four new ICMP message types, two for use in the dynamic home agent address discovery mechanism, and two for renumbering and mobile configuration mechanisms. As described in Section 10.5 and Section 11.4.1, the following two new ICMP message types are used for home agent address discovery:
また、モバイルIPv6は4つの新しいICMPメッセージタイプ、ダイナミックなホームエージェントアドレス発見メカニズムにおける使用のための2、および番号を付け替えていてモバイルの構成メカニズムのための2を導入します。セクション10.5とセクション11.4.1で説明されるように、以下の2つの新しいICMPメッセージタイプがホームエージェントアドレス発見に使用されます:
o Home Agent Address Discovery Request, described in Section 6.5.
o セクション6.5で説明されたホームエージェントAddressディスカバリーRequest。
o Home Agent Address Discovery Reply, described in Section 6.6.
o セクション6.6で説明されたホームエージェントAddressディスカバリーReply。
The next two message types are used for network renumbering and address configuration on the mobile node, as described in Section 10.6:
次の2つのメッセージタイプがモバイルノードでのネットワークの番号を付け替えるのとアドレス構成に使用されます、セクション10.6で説明されるように:
o Mobile Prefix Solicitation, described in Section 6.7.
o セクション6.7で説明されたモバイルPrefix Solicitation。
o Mobile Prefix Advertisement, described in Section 6.8.
o セクション6.8で説明されたモバイルPrefix Advertisement。
4.5. Conceptual Data Structure Terminology
4.5. 概念的なデータ構造用語
This document describes the Mobile IPv6 protocol in terms of the following conceptual data structures:
このドキュメントは以下の概念的なデータ構造に関してモバイルIPv6プロトコルについて説明します:
Binding Cache
拘束力があるキャッシュ
A cache of bindings for other nodes. This cache is maintained by
home agents and correspondent nodes. The cache contains both
"correspondent registration" entries (see Section 9.1) and "home
registration" entries (see Section 10.1).
他のノードのための結合のキャッシュ。 このキャッシュはホームのエージェントと通信員ノードによって維持されます。 キャッシュは「通信員登録」エントリー(セクション9.1を見る)と「本国登録」エントリーの両方を含んでいます(セクション10.1を見てください)。
Binding Update List
拘束力があるアップデートリスト
This list is maintained by each mobile node. The list has an item
for every binding that the mobile node has or is trying to
establish with a specific other node. Both correspondent and home
registrations are included in this list. Entries from the list
are deleted as the lifetime of the binding expires. See Section
11.1.
このリストはそれぞれのモバイルノードによって維持されます。 リストには、モバイルノードが持っていようとするか、または他の特定のノードで確立しようとしているあらゆる結合のための項目があります。 通信員とホーム登録証明書の両方がこのリストに含まれています。 結合の寿命が期限が切れて、リストからのエントリーは削除されます。 セクション11.1を見てください。
Johnson, et al. Standard Track [Page 17] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[17ページ]のRFC3775移動性サポート
Home Agents List
ホームエージェントリスト
Home agents need to know which other home agents are on the same
link. This information is stored in the Home Agents List, as
described in more detail in Section 10.1. The list is used for
informing mobile nodes during dynamic home agent address
discovery.
ホームのエージェントは、どの他のホームのエージェントが同じリンクの上にいるかを知る必要があります。 この情報はさらに詳細にセクション10.1で説明されるようにホームエージェントListに保存されます。 リストは、ダイナミックなホームエージェントアドレス発見の間、モバイルノードを知らせるのに使用されます。
4.6. Site-Local Addressability
4.6. サイト地方のアドレス指定能力
This specification requires that home and care-of addresses MUST be unicast routable addresses. Site-local addresses may be usable on networks that are not connected to the Internet, but this specification does not define when such usage is safe and when it is not. Mobile nodes may not be aware of which site they are currently in, it is hard to prevent accidental attachment to other sites, and ambiguity of site-local addresses can cause problems if the home and visited networks use the same addresses. Therefore, site-local addresses SHOULD NOT be used as home or care-of addresses.
そして、この仕様がそのホームが必要である、注意、-、アドレスはユニキャスト発送可能アドレスであるに違いありません。 サイトローカルのアドレスはインターネットに接続されないネットワークで使用可能であるかもしれませんが、この仕様はそのような用法がいつ安全であるか、そして、いつでないかを定義しません。 モバイルノードは中に現在、どのサイトについてそれらがあるかを意識していないかもしれません、そして、他のサイトへの偶然の付属を防ぎにくくて、ホームと訪問されたネットワークが同じアドレスを使用するなら、サイトローカルのアドレスのあいまいさは問題を起こすことができます。 または、したがって、サイトローカルがSHOULD NOTを扱う、ホームとして使用されてください、注意、-、アドレス。
5. Overview of Mobile IPv6 Security
5. モバイルIPv6セキュリティの概要
This specification provides a number of security features. These include the protection of Binding Updates both to home agents and correspondent nodes, the protection of mobile prefix discovery, and the protection of the mechanisms that Mobile IPv6 uses for transporting data packets.
この仕様は多くのセキュリティ機能を提供します。 これらはホームのエージェントと通信員ノードへのBinding Updatesの保護、モバイル接頭語発見の保護、およびモバイルIPv6がデータ・パケットを輸送するのに使用するメカニズムの保護を含んでいます。
Binding Updates are protected by the use of IPsec extension headers, or by the use of the Binding Authorization Data option. This option employs a binding management key, Kbm, which can be established through the return routability procedure. Mobile prefix discovery is protected through the use of IPsec extension headers. Mechanisms related to transporting payload packets - such as the Home Address destination option and type 2 routing header - have been specified in a manner which restricts their use in attacks.
拘束力があるUpdatesはIPsec拡張ヘッダーの使用、またはBinding Authorization Dataオプションの使用で保護されます。 このオプションは拘束力がある管理キー、Kbmを使います。(リターンroutability手順でKbmを設立できます)。 モバイル接頭語発見はIPsec拡張ヘッダーの使用で保護されます。 ホームAddress目的地オプションとタイプ2ルーティングヘッダーなどのペイロードパケットを輸送すると関連するメカニズムは攻撃における彼らの使用を制限する方法で指定されました。
5.1. Binding Updates to Home Agents
5.1. ホームのエージェントにアップデートを縛ります。
The mobile node and the home agent MUST use an IPsec security association to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [6] header in transport mode and MUST use a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. Note that Authentication Header (AH) [5] is also possible but for brevity not discussed in this specification.
モバイルノードとホームのエージェントはBinding UpdatesとAcknowledgementsの保全と信憑性を保護するIPsecセキュリティ協会を使用しなければなりません。 モバイルノードとホームのエージェントが支えなければならない両方とSHOULDは、交通機関でEncapsulating Security有効搭載量(超能力)[6]ヘッダーを使用して、データ発生源認証、コネクションレスな保全、および任意の反反復操作による保護を提供するのに非NULLペイロード認証アルゴリズムを使用しなければなりません。 Authentication Header(AH)[5]についてまた、可能であり、簡潔さのためにこの仕様で議論しないことに注意してください。
Johnson, et al. Standard Track [Page 18] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[18ページ]のRFC3775移動性サポート
In order to protect messages exchanged between the mobile node and the home agent with IPsec, appropriate security policy database entries must be created. A mobile node must be prevented from using its security association to send a Binding Update on behalf of another mobile node using the same home agent. This MUST be achieved by having the home agent check that the given home address has been used with the right security association. Such a check is provided in the IPsec processing, by having the security policy database entries unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent. In order to make this possible, it is necessary that the home address of the mobile node is visible in the Binding Updates and Acknowledgements. The home address is used in these packets as a source or destination, or in the Home Address Destination option or the type 2 routing header.
モバイルノードとIPsecのホームのエージェントの間で交換されたメッセージを保護するために、適切な安全保障政策データベースエントリーを作成しなければなりません。 同じホームのエージェントを使用することで別のモバイルノードを代表してBinding Updateを送るセキュリティ協会を使用するのをモバイルノードを防がなければなりません。 ホームのエージェントに与えられたホームアドレスが正しいセキュリティ関係と共に使用されたのをチェックさせることによって、これを達成しなければなりません。 そのようなチェックをIPsec処理に提供します、安全保障政策データベースエントリーにBinding Updatesを保護するために明確にどんな与えられたホームアドレスとホームのエージェントの間でも単一のセキュリティ協会を特定させることによって。 これを可能にするように、モバイルノードのホームアドレスがBinding UpdatesとAcknowledgementsで目に見えるのが必要です。 ホームアドレスはソースか目的地としてのこれらのパケット、ホームAddress Destinationオプションまたはタイプ2ルーティングヘッダーで使用されます。
As with all IPsec security associations in this specification, manual configuration of security associations MUST be supported. The used shared secrets MUST be random and unique for different mobile nodes, and MUST be distributed off-line to the mobile nodes.
この仕様によるすべてのIPsecセキュリティ関係と共にセキュリティ協会の手動の構成をサポートしなければならないので。 中古の共有秘密キーを異なったモバイルノードに無作為であって、ユニークでなければならなく、モバイルノードにオフラインで分配しなければなりません。
Automatic key management with IKE [9] MAY be supported. When IKE is used, either the security policy database entries or the Mobile IPv6 processing MUST unequivocally identify the IKE phase 1 credentials which can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address. How these mappings are maintained is outside the scope of this specification, but they may be maintained, for instance, as a locally administered table in the home agent. If the phase 1 identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS may also be used.
IKE[9]との自動かぎ管理はサポートされるかもしれません。 IKEが使用されているとき、安全保障政策データベースエントリーかモバイルIPv6処理のどちらかが明確に、特定のホームアドレスのためにBinding Updatesを保護するためにセキュリティ協会の創設を認可するのに使用できるIKEフェーズ1資格証明書を特定しなければなりません。 この仕様の範囲の外にこれらのマッピングがどう維持されるかがありますが、例えば、それらは局所的に管理されたテーブルとしてホームのエージェントで維持されるかもしれません。 また、フェーズ1のアイデンティティがFully Qualified Domain Name(FQDN)であるなら、DNSの安全なフォームは使用されるかもしれません。
Section 11.3.2 discusses how IKE connections to the home agent need a careful treatment of the addresses used for transporting IKE. This is necessary to ensure that a Binding Update is not needed before the IKE exchange which is needed for securing the Binding Update.
セクション11.3 .2 ホームのエージェントとのIKE接続が、どうIKEを輸送するのにアドレスの慎重な処理を使用する必要であるかについて議論します。 これが、Binding UpdateはBinding Updateを固定するのに必要であるIKE交換の前に必要でないことを保証するのに必要です。
When IKE version 1 is used with preshared secret authentication between the mobile node and the home agent, aggressive mode MUST be used.
IKEバージョン1がモバイルノードとホームのエージェントの間の前共有された秘密の認証と共に使用されるとき、攻撃的なモードを使用しなければなりません。
The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1.
IKEv1フェーズ1にID_IPV6_ADDR Identity有効搭載量を使用してはいけません。
Reference [21] contains a more detailed description and examples on using IPsec to protect the communications between the mobile node and the home agent.
参照[21]はモバイルノードとホームのエージェントとのコミュニケーションを保護するのにIPsecを使用することに関する、より詳細な記述と例を含んでいます。
Johnson, et al. Standard Track [Page 19] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[19ページ]のRFC3775移動性サポート
5.2. Binding Updates to Correspondent Nodes
5.2. 通信員ノードへの拘束力があるアップデート
The protection of Binding Updates sent to correspondent nodes does not require the configuration of security associations or the existence of an authentication infrastructure between the mobile nodes and correspondent nodes. Instead, a method called the return routability procedure is used to assure that the right mobile node is sending the message. This method does not protect against attackers who are on the path between the home network and the correspondent node. However, attackers in such a location are capable of performing the same attacks even without Mobile IPv6. The main advantage of the return routability procedure is that it limits the potential attackers to those having an access to one specific path in the Internet, and avoids forged Binding Updates from anywhere else in the Internet. For a more in depth explanation of the security properties of the return routability procedure, see Section 15.
通信員ノードに送られたBinding Updatesの保護はモバイルノードと通信員ノードの間のセキュリティ協会の構成か認証インフラストラクチャの存在を必要としません。 代わりに、リターンroutability手順と呼ばれるメソッドは、正しいモバイルノードがメッセージを送ることを保証するのに使用されます。 このメソッドはホームネットワークと通信員ノードの間の経路にいる攻撃者から守りません。 しかしながら、そのような位置の攻撃者はモバイルIPv6がなくても同じ攻撃を実行できます。 リターンroutability手順の主な利点はインターネットで潜在的攻撃者を1つの特定の経路に近づく手段を持っているものに制限して、インターネットで他のどこかから偽造Binding Updatesを避けるということです。 リターンroutability手順のセキュリティの特性の、より徹底的な説明に関しては、セクション15を見てください。
The integrity and authenticity of the Binding Updates messages to correspondent nodes is protected by using a keyed-hash algorithm. The binding management key, Kbm, is used to key the hash algorithm for this purpose. Kbm is established using data exchanged during the return routability procedure. The data exchange is accomplished by use of node keys, nonces, cookies, tokens, and certain cryptographic functions. Section 5.2.5 outlines the basic return routability procedure. Section 5.2.6 shows how the results of this procedure are used to authorize a Binding Update to a correspondent node.
通信員ノードへのBinding Updatesメッセージの保全と信憑性は、合わせられたハッシュアルゴリズムを使用することによって、保護されます。 拘束力がある管理キー(Kbm)は、このためにハッシュアルゴリズムを合わせるのに使用されます。 Kbmは、リターンroutability手順の間に交換されたデータを使用することで設立されます。 データ交換はノードキー、一回だけ、クッキー、トークン、およびある暗号の機能の使用で実行されます。 セクション5.2 .5 基本的なリターンroutability手順について概説します。 セクション5.2 .6 この手順の結果が通信員ノードにBinding Updateを認可するのにどう使用されるかを示しています。
5.2.1. Node Keys
5.2.1. ノードキー
Each correspondent node has a secret key, Kcn, called the "node key", which it uses to produce the keygen tokens sent to the mobile nodes. The node key MUST be a random number, 20 octets in length. The node key allows the correspondent node to verify that the keygen tokens used by the mobile node in authorizing a Binding Update are indeed its own. This key MUST NOT be shared with any other entity.
それぞれの通信員ノードには、秘密鍵(それがモバイルノードに送られたkeygenトークンを生産するのに使用する「ノードキー」と呼ばれるKcn)があります。 ノードキーは乱数、長さが20の八重奏であるに違いありません。 ノードキーで、通信員ノードは、本当に、モバイルノードによってBinding Updateを認可する際に使用されるkeygenトークンがそれ自身であることを確かめることができます。 いかなる他の実体ともこのキーを共有してはいけません。
A correspondent node MAY generate a fresh node key at any time; this avoids the need for secure persistent key storage. Procedures for optionally updating the node key are discussed later in Section 5.2.7.
通信員ノードはいつでも主要な新鮮なノードを作るかもしれません。 これは安全な永続的な主要なストレージの必要性を避けます。 後でセクション5.2.7で任意にノードキーをアップデートするための手順について議論します。
5.2.2. Nonces
5.2.2. 一回だけ
Each correspondent node also generates nonces at regular intervals. The nonces should be generated by using a random number generator that is known to have good randomness properties [1]. A correspondent node may use the same Kcn and nonce with all the mobiles it is in communication with.
また、それぞれの通信員ノードは一定の間隔を置いて一回だけを生成します。 一回だけは、良い偶発性の特性[1]を持っているのが知られている乱数発生器を使用することによって、生成されるべきです。 通信員ノードはコミュニケーションにそれとあるすべてのモバイルがある同じKcnと一回だけを使用するかもしれません。
Johnson, et al. Standard Track [Page 20] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[20ページ]のRFC3775移動性サポート
Each nonce is identified by a nonce index. When a new nonce is generated, it must be associated with a new nonce index; this may be done, for example, by incrementing the value of the previous nonce index, if the nonce index is used as an array pointer into a linear array of nonces. However, there is no requirement that nonces be stored that way, or that the values of subsequent nonce indices have any particular relationship to each other. The index value is communicated in the protocol, so that if a nonce is replaced by new nonce during the run of a protocol, the correspondent node can distinguish messages that should be checked against the old nonce from messages that should be checked against the new nonce. Strictly speaking, indices are not necessary in the authentication, but allow the correspondent node to efficiently find the nonce value that it used in creating a keygen token.
各一回だけは一回だけのインデックスによって特定されます。 新しい一回だけが発生しているとき、それは新しい一回だけのインデックスに関連しているに違いありません。 例えば、前の一回だけのインデックスの値を増加することによって、これをするかもしれません、一回だけのインデックスが配列指針として一回だけの線形配列に使用されるなら。 しかしながら、一回だけがそのように保存されるか、またはその後の一回だけのインデックスリストの値には互いとのどんな特定の関係もあるという要件が全くありません。 インデックス値はプロトコルで伝えられます、プロトコルの走行の間、一回だけを新しい一回だけに取り替えるなら、通信員ノードが古い一回だけに対して新しい一回だけに対してチェックされるべきであるメッセージからチェックされるべきであるメッセージを区別できるように。 厳密に言うと、インデックスリストは認証では必要ではありませんが、通信員ノードにそれがkeygenトークンを作成する際に使用した一回だけの値を効率的に、見つけさせてください。
Correspondent nodes keep both the current nonce and a small set of valid previous nonces whose lifetime has not yet expired. Expired values MUST be discarded, and messages using stale or unknown indices will be rejected.
通信員ノードは、両方が寿命がまだ期限が切れていない現在の一回だけと小さいセットの前の有効な一回だけであることを保ちます。 満期の値を捨てなければなりません、そして、聞き古した未知のインデックスリストを使用するメッセージが拒絶されるでしょう。
The specific nonce index values cannot be used by mobile nodes to determine the validity of the nonce. Expected validity times for the nonces values and the procedures for updating them are discussed later in Section 5.2.7.
特定の一回だけのインデックス値はモバイルノードによって使用されて、一回だけの正当性を決定することがないことができます。 後でセクション5.2.7で一回だけ値のための予想された正当性回とそれらをアップデートするための手順について議論します。
A nonce is an octet string of any length. The recommended length is 64 bits.
一回だけはどんな長さの八重奏ストリングです。 お勧めの長さは64ビットです。
5.2.3. Cookies and Tokens
5.2.3. クッキーとトークン
The return routability address test procedure uses cookies and keygen tokens as opaque values within the test init and test messages, respectively.
リターンroutabilityアドレステスト手順は不透明な値としてテストイニットとテストメッセージの中でそれぞれクッキーとkeygenトークンを使用します。
o The "home init cookie" and "care-of init cookie" are 64 bit values
sent to the correspondent node from the mobile node, and later
returned to the mobile node. The home init cookie is sent in the
Home Test Init message, and returned in the Home Test message.
The care-of init cookie is sent in the Care-of Test Init message,
and returned in the Care-of Test message.
o そして、「ホームイニットクッキー」、「注意、-、イニットクッキー、」 モバイルノードからの対応であっているノードに送られた64ビットの値であり、モバイルノードに返して、後でそのような値です。 ホームイニットクッキーをホームTest Initメッセージで送って、ホームTestメッセージで返します。 注意、-、イニットクッキー、送られる、Care、-、Test Initメッセージ、戻る、Care、-、Testメッセージ
o The "home keygen token" and "care-of keygen token" are 64-bit
values sent by the correspondent node to the mobile node via the
home agent (via the Home Test message) and the care-of address (by
the Care-of Test message), respectively.
o The "home keygen token" and "care-of keygen token" are 64-bit values sent by the correspondent node to the mobile node via the home agent (via the Home Test message) and the care-of address (by the Care-of Test message), respectively.
Johnson, et al. Standard Track [Page 21] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[21ページ]のRFC3775移動性サポート
The mobile node should set the home init or care-of init cookie to a newly generated random number in every Home or Care-of Test Init message it sends. The cookies are used to verify that the Home Test or Care-of Test message matches the Home Test Init or Care-of Test Init message, respectively. These cookies also serve to ensure that parties who have not seen the request cannot spoof responses.
または、または、モバイルノードがホームイニットを設定するはずである、注意、-、あらゆるホームにおける新たに生成している乱数へのイニットクッキー、Care、-、それが送るTest Initメッセージ。 または、または、クッキーがそれについて確かめるのに使用される、ホームTest、Care、-、TestメッセージがホームTest Initを合わせる、Care、-、それぞれTest Initメッセージ。 また、これらのクッキーは、要求を見ていないパーティーが応答を偽造することができないのを保証するのに役立ちます。
Home and care-of keygen tokens are produced by the correspondent node based on its currently active secret key (Kcn) and nonces, as well as the home or care-of address (respectively). A keygen token is valid as long as both the secret key (Kcn) and the nonce used to create it are valid.
または、そして、家、注意、-、keygenトークンはその現在アクティブな秘密鍵(Kcn)と一回だけに基づく通信員ノードによって生産されます、ホームと同様に注意、-、アドレス(それぞれ)。 秘密鍵(Kcn)とそれを作成するのに使用される一回だけの両方が有効である限り、keygenトークンは有効です。
5.2.4. Cryptographic Functions
5.2.4. 暗号の機能
In this specification, the function used to compute hash values is SHA1 [20]. Message Authentication Codes (MACs) are computed using HMAC_SHA1 [25, 20]. HMAC_SHA1(K,m) denotes such a MAC computed on message m with key K.
この仕様では、ハッシュ値を計算するのに使用される機能はSHA1[20]です。 メッセージ立証コード(MACs)は、HMAC_SHA1[25、20]を使用することで計算されます。 HMAC_SHA1(K、m)はメッセージmでキーKで計算されたそのようなMACを指示します。
5.2.5. Return Routability Procedure
5.2.5. リターンRoutability手順
The Return Routability Procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed care-of address.
Return Routability Procedureが、通信員ノードが事実上モバイルノードがアドレス可能である何らかの手頃な保証を得るのを可能にする、それが要求された、注意、-、また、ホームアドレスのように、扱います。 通信員ノードが単にこの保証で次にそのモバイルノードのデータ通信量を指示するよう通信員ノードに命令するモバイルノードからBinding Updatesを受け入れることができる、それが要求された、注意、-、アドレス
This is done by testing whether packets addressed to the two claimed addresses are routed to the mobile node. The mobile node can pass the test only if it is able to supply proof that it received certain data (the "keygen tokens") which the correspondent node sends to those addresses. These data are combined by the mobile node into a binding management key, denoted Kbm.
2に扱われたパケットが、アドレスがモバイルノードに発送されると主張したか否かに関係なく、テストすることによって、これをします。 通信員ノードがそれらのアドレスに送るあるデータ(「keygenトークン」)を受け取ったという証拠を供給できる場合にだけ、モバイルノードはテストに合格できます。 Kbmは、これらのデータがモバイルノードによって拘束力がある管理キーに結合されるのを指示しました。
The figure below shows the message flow for the return routability procedure.
以下の図はリターンroutability手順のためにメッセージ流動を示しています。
Johnson, et al. Standard Track [Page 22] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[22ページ]のRFC3775移動性サポート
Mobile node Home agent Correspondent node
| |
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| |
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| | |
| Care-of Test (CoT) |
|<----------------------------------------------------|
| |
モバイルノードホームエージェントCorrespondentノード| | | ホームテストイニット(HoTI)| | |------------------------->|------------------------->| | | | | 注意、-、イニット(CoTI)をテストしてください。| |---------------------------------------------------->| | | | | ホームテスト(熱い)| |<-------------------------|<-------------------------| | | | | 注意、-、テスト(簡易寝台)| |<----------------------------------------------------| | |
The Home and Care-of Test Init messages are sent at the same time. The procedure requires very little processing at the correspondent node, and the Home and Care-of Test messages can be returned quickly, perhaps nearly simultaneously. These four messages form the return routability procedure.
そして、ホーム、Care、-、同時に、Test Initメッセージを送ります。 そして、手順が通信員ノードでの非常に少ない処理、およびホームが必要である、Care、-、すぐに、そして、恐らくほとんど同時に、Testメッセージを返すことができます。 これらの4つのメッセージがリターンroutability手順を形成します。
Home Test Init
ホームテストイニット
A mobile node sends a Home Test Init message to the correspondent
node (via the home agent) to acquire the home keygen token. The
contents of the message can be summarized as follows:
モバイルノードは、ホームkeygenトークンを取得するために通信員ノード(ホームのエージェントを通した)にホームTest Initメッセージを送ります。 以下の通りメッセージのコンテンツをまとめることができます:
* Source Address = home address
* ソースAddressはホームアドレスと等しいです。
* Destination Address = correspondent
* 目的地Address=通信員
* Parameters:
* パラメタ:
+ home init cookie
+ ホームイニットクッキー
The Home Test Init message conveys the mobile node's home address
to the correspondent node. The mobile node also sends along a
home init cookie that the correspondent node must return later.
The Home Test Init message is reverse tunneled through the home
agent. (The headers and addresses related to reverse tunneling
have been omitted from the above discussion of the message
contents.) The mobile node remembers these cookie values to
obtain some assurance that its protocol messages are being
processed by the desired correspondent node.
ホームTest Initメッセージはモバイルノードのホームアドレスを通信員ノードに伝えます。 また、モバイルノードは通信員ノードが後で返さなければならないホームイニットクッキーを送ります。 ホームTest Initメッセージはホームのエージェントを通してトンネルを堀られた状態で逆です。 (トンネリングを逆にするために関係づけられたヘッダーとアドレスはメッセージ内容の上の議論から省略されました。) モバイルノードは、プロトコルメッセージが必要な通信員ノードによって処理されているという何らかの保証を得るためにこれらのクッキー値を覚えています。
Johnson, et al. Standard Track [Page 23] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[23ページ]のRFC3775移動性サポート
Care-of Test Init
注意、-、イニットをテストしてください。
The mobile node sends a Care-of Test Init message to the
correspondent node (directly, not via the home agent) to acquire
the care-of keygen token. The contents of this message can be
summarized as follows:
モバイルノードが発信する、Care、-、Test Initメッセージ、帯びる通信員ノード(直接ホームのエージェントを通した)、注意、-、keygenトークン 以下の通りこのメッセージのコンテンツをまとめることができます:
* Source Address = care-of address
* ソースAddressが等しい、注意、-、アドレス
* Destination Address = correspondent
* 目的地Address=通信員
* Parameters:
* パラメタ:
+ care-of init cookie
+、注意、-、イニットクッキー
The Care-of Test Init message conveys the mobile node's care-of
address to the correspondent node. The mobile node also sends
along a care-of init cookie that the correspondent node must
return later. The Care-of Test Init message is sent directly to
the correspondent node.
Care、-、Test Initメッセージ、モバイルノードのものが運ぶ、注意、-、通信員ノードへのアドレス。 また、モバイルノードがaを送る、注意、-、通信員ノードが後で返さなければならないイニットクッキー。 Care、-、直接通信員ノードにTest Initメッセージを送ります。
Home Test
ホームテスト
The Home Test message is sent in response to a Home Test Init
message. It is sent via the home agent. The contents of the
message are:
ホームTest Initメッセージに対応してホームTestメッセージを送ります。 ホームのエージェントを通してそれを送ります。 メッセージの内容は以下の通りです。
* Source Address = correspondent
* ソースAddressは通信員と等しいです。
* Destination Address = home address
* 目的地Address=ホームアドレス
* Parameters:
* パラメタ:
+ home init cookie
+ ホームイニットクッキー
+ home keygen token
+ ホームkeygenトークン
+ home nonce index
+ ホーム一回だけインデックス
Johnson, et al. Standard Track [Page 24] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[24ページ]のRFC3775移動性サポート
When the correspondent node receives the Home Test Init message,
it generates a home keygen token as follows:
通信員ノードがホームTest Initメッセージを受け取るとき、以下のホームkeygenトークンを生成します:
home keygen token :=
First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0)))
ホームは最初に、トークン:=をkeygenします。(64、HMAC_SHA1(Kcn、(ホームアドレス|一回だけ|0)))
where | denotes concatenation. The final "0" inside the HMAC_SHA1
function is a single zero octet, used to distinguish home and
care-of cookies from each other.
どこ| 連結を指示します。 そして、決勝、「HMAC_SHA1機能における0インチが八重奏がなくて、ホームを区別するのにおいて中古のシングルである、注意、-、互いからのクッキー、」
The home keygen token is formed from the first 64 bits of the MAC.
The home keygen token tests that the mobile node can receive were
messages sent to its home address. Kcn is used in the production
of home keygen token in order to allow the correspondent node to
verify that it generated the home and care-of nonces, without
forcing the correspondent node to remember a list of all tokens it
has handed out.
ホームkeygenトークンはMACの最初の64ビットから形成されます。 モバイルノードが受けることができるホームkeygenトークンテストはホームアドレスに送られたメッセージでした。 そして、Kcnが通信員ノードが、ホームを生成したことを確かめるのを許容するのにホームkeygenトークンの生産に使用される、注意、-、通信員ノードにそれが与えたすべてのトークンのリストを覚えていさせることのない一回だけ。
The Home Test message is sent to the mobile node via the home
network, where it is presumed that the home agent will tunnel the
message to the mobile node. This means that the mobile node needs
to already have sent a Binding Update to the home agent, so that
the home agent will have received and authorized the new care-of
address for the mobile node before the return routability
procedure. For improved security, the data passed between the
home agent and the mobile node is made immune to inspection and
passive attacks. Such protection is gained by encrypting the home
keygen token as it is tunneled from the home agent to the mobile
node as specified in Section 10.4.6. The security properties of
this additional security are discussed in Section 15.4.1.
ホームネットワークを通したモバイルノードにホームTestメッセージを送ります。ノードでは、ホームのエージェントがモバイルノードにメッセージにトンネルを堀ると推定されます。 これは、モバイルノードが、既にホームのエージェントにBinding Updateを送った必要を意味します、ホームのエージェントが新しさを受けて、認可してしまうだろうというように注意、-、モバイルノードには、リターンの前にroutabilityが手順であると扱ってください。 向上したセキュリティのために、ホームのエージェントとモバイルノードの間で通過されたデータを点検と受け身の攻撃に免疫があるようにします。 それがホームのエージェントからセクション10.4.6における指定されるとしてのモバイルノードにトンネルを堀られるのでホームkeygenトークンを暗号化することによって、そのような保護を獲得します。 セクション15.4.1でこの追加担保のセキュリティの特性について議論します。
The home init cookie from the mobile node is returned in the Home
Test message, to ensure that the message comes from a node on the
route between the home agent and the correspondent node.
メッセージがホームのエージェントと通信員ノードの間のルートの上のノードから来るのを保証するためにホームTestメッセージでモバイルノードからのホームイニットクッキーを返します。
The home nonce index is delivered to the mobile node to later
allow the correspondent node to efficiently find the nonce value
that it used in creating the home keygen token.
ホーム一回だけインデックスは、後で通信員ノードが効率的に、それがホームkeygenトークンを作成する際に使用した一回だけの値を見つけるのを許容するためにモバイルノードに提供されます。
Care-of Test
注意、-、テスト
This message is sent in response to a Care-of Test Init message.
This message is not sent via the home agent, it is sent directly
to the mobile node. The contents of the message are:
aに対応してこのメッセージを送る、Care、-、Test Initメッセージ。 ホームのエージェントを通してこのメッセージを送らないで、直接モバイルノードにそれを送ります。 メッセージの内容は以下の通りです。
* Source Address = correspondent
* ソースAddressは通信員と等しいです。
* Destination Address = care-of address
* 目的地Address=、注意、-、アドレス
Johnson, et al. Standard Track [Page 25] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[25ページ]のRFC3775移動性サポート
* Parameters:
* パラメタ:
+ care-of init cookie
+、注意、-、イニットクッキー
+ care-of keygen token
+、注意、-、keygenトークン
+ care-of nonce index
+、注意、-、一回だけのインデックス
When the correspondent node receives the Care-of Test Init
message, it generates a care-of keygen token as follows:
通信員ノードが受信する、Care、-、Test Initメッセージ、aを生成する、注意、-、以下のkeygenトークン:
care-of keygen token :=
First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))
注意、-、最初に、トークン:=をkeygenします。(64、HMAC_SHA1、(Kcn、(注意、-、アドレス|一回だけ|1)
Here, the final "1" inside the HMAC_SHA1 function is a single
octet containing the hex value 0x01, and is used to distinguish
home and care-of cookies from each other. The keygen token is
formed from the first 64 bits of the MAC, and sent directly to the
mobile node at its care-of address. The care-of init cookie from
the Care-of Test Init message is returned to ensure that the
message comes from a node on the route to the correspondent node.
そして、ここ、決勝、「HMAC_SHA1機能における1インチが十六進法値0x01を含むただ一つの八重奏であり、ホームを区別するのに使用される、注意、-、互いからのクッキー、」 keygenトークンをMACの最初の64ビットから形成して、直接モバイルノードに送る、それ、注意、-、アドレス 注意、-、イニットクッキー、Care、-、Test Initメッセージ、メッセージがルートの上のノードから通信員ノードに来るのを保証するために、返します。
The care-of nonce index is provided to identify the nonce used for
the care-of keygen token. The home and care-of nonce indices MAY
be the same, or different, in the Home and Care-of Test messages.
注意、-、使用されていた状態で一回だけを特定するために一回だけのインデックスを提供する、注意、-、keygenトークン そして、そして、ホーム、注意、-、一回だけのインデックスリストが同じであるか、またはホームにおいて異なるかもしれない、Care、-、Testメッセージ。
When the mobile node has received both the Home and Care-of Test messages, the return routability procedure is complete. As a result of the procedure, the mobile node has the data it needs to send a Binding Update to the correspondent node. The mobile node hashes the tokens together to form a 20 octet binding key Kbm:
そして、モバイルノードが両方のホームを受けた、Care、-、Testメッセージであり、リターンroutability手順は完全です。 手順の結果、モバイルノードには、それが通信員ノードにBinding Updateを送るために必要とするデータがあります。 モバイルノードは主要なKbmを縛る20八重奏を形成するためにトークンを一緒に論じ尽くします:
Kbm = SHA1 (home keygen token | care-of keygen token)
KbmはSHA1と等しいです。(ホームkeygenトークン|、注意、-、keygenトークン)
A Binding Update may also be used to delete a previously established binding (Section 6.1.7). In this case, the care-of keygen token is not used. Instead, the binding management key is generated as follows:
また、Binding Updateは、以前に確立した結合(セクション6.1.7)を削除するのに使用されるかもしれません。 この場合、注意、-、keygenトークンは使用されていません。 代わりに、拘束力がある管理キーは以下の通り生成されます:
Kbm = SHA1(home keygen token)
KbmはSHA1と等しいです。(ホームkeygenトークン)
Note that the correspondent node does not create any state specific to the mobile node, until it receives the Binding Update from that mobile node. The correspondent node does not maintain the value for the binding management key Kbm; it creates Kbm when given the nonce indices and the mobile node's addresses.
通信員ノードがモバイルノードに特定の状態で少しの状態も創設しないことに注意してください、そのモバイルノードからBinding Updateを受けるまで。 通信員ノードは拘束力がある管理の主要なKbmのために値を維持しません。 一回だけのインデックスリストとモバイルノードのアドレスを与えるとき、それはKbmを作成します。
Johnson, et al. Standard Track [Page 26] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[26ページ]のRFC3775移動性サポート
5.2.6. Authorizing Binding Management Messages
5.2.6. 管理メッセージを縛るのを認可します。
After the mobile node has created the binding management key (Kbm), it can supply a verifiable Binding Update to the correspondent node. This section provides an overview of this registration. The below figure shows the message flow.
モバイルノードが拘束力がある管理キー(Kbm)を作成した後に、それは証明可能なBinding Updateを通信員ノードに供給できます。 このセクションはこの登録の概要を提供します。 以下の図はメッセージ流動を示しています。
Mobile node Correspondent node
| |
| Binding Update (BU) |
|---------------------------------------------->|
| (MAC, seq#, nonce indices, care-of address) |
| |
| |
| Binding Acknowledgement (BA) (if sent) |
|<----------------------------------------------|
| (MAC, seq#, status) |
モバイルノードCorrespondentノード| | | 拘束力があるアップデート(BU)| |---------------------------------------------->| | (MAC、seq#、一回だけのインデックスリスト、注意、-、アドレス) | | | | | | 拘束力があるAcknowledgement(BA)(送るなら)| |<----------------------------------------------| | (MAC、seq#、状態) |
Binding Update
拘束力があるアップデート
To authorize a Binding Update, the mobile node creates a binding
management key Kbm from the keygen tokens as described in the
previous section. The contents of the Binding Update include the
following:
Binding Updateを認可するために、モバイルノードは前項で説明されるようにkeygenトークンから拘束力がある管理主要なKbmを作成します。 Binding Updateの内容は以下を含んでいます:
* Source Address = care-of address
* ソースAddressが等しい、注意、-、アドレス
* Destination Address = correspondent
* 目的地Address=通信員
* Parameters:
* パラメタ:
+ home address (within the Home Address destination option if
different from the Source Address)
+ ホームアドレス(Source Addressと異なるならAddressの目的地がゆだねるホームの中の)
+ sequence number (within the Binding Update message header)
+ 一連番号(Binding Updateメッセージヘッダーの中の)
+ home nonce index (within the Nonce Indices option)
+ ホーム一回だけインデックス(Nonce Indicesオプションの中の)
+ care-of nonce index (within the Nonce Indices option)
+、注意、-、一回だけのインデックス(Nonce Indicesオプションの中の)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))
+ 最初に(96、HMAC_SHA1、(Kbm、(注意、-、アドレス|通信員|BU)
Johnson, et al. Standard Track [Page 27] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[27ページ]のRFC3775移動性サポート
The Binding Update contains a Nonce Indices option, indicating to
the correspondent node which home and care-of nonces to use to
recompute Kbm, the binding management key. The MAC is computed as
described in Section 6.2.7, using the correspondent node's address
as the destination address and the Binding Update message itself
("BU" above) as the MH Data.
そして、Binding UpdateはNonce Indicesオプションを含んでいます、どのホームを通信員ノードに示して注意、-、recompute Kbm(拘束力がある管理キー)に使用する一回だけ MACはセクション6.2.7で説明されるように計算されます、MHデータとしての送付先アドレスとBinding Updateメッセージ(上の"BU")自体として通信員ノードのアドレスを使用して。
Once the correspondent node has verified the MAC, it can create a
Binding Cache entry for the mobile.
通信員ノードがいったんMACについて確かめると、それはモバイルのためのBinding Cacheエントリーを作成できます。
Binding Acknowledgement
拘束力がある承認
The Binding Update is in some cases acknowledged by the
correspondent node. The contents of the message are as follows:
いくつかの場合、Binding Updateは通信員ノードによって承認されます。 メッセージの内容は以下の通りです:
* Source Address = correspondent
* ソースAddressは通信員と等しいです。
* Destination Address = care-of address
* 目的地Address=、注意、-、アドレス
* Parameters:
* パラメタ:
+ sequence number (within the Binding Update message header)
+ 一連番号(Binding Updateメッセージヘッダーの中の)
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
+ 最初に(96、HMAC_SHA1、(Kbm、(注意、-、アドレス|通信員|BA)
The Binding Acknowledgement contains the same sequence number as
the Binding Update. The MAC is computed as described in Section
6.2.7, using the correspondent node's address as the destination
address and the message itself ("BA" above) as the MH Data.
Binding AcknowledgementはBinding Updateと同じ一連番号を含んでいます。 MACはセクション6.2.7で説明されるように計算されます、MHデータとしての送付先アドレスとメッセージ(上の「Ba」)自体として通信員ノードのアドレスを使用して。
Bindings established with correspondent nodes using keys created
by way of the return routability procedure MUST NOT exceed
MAX_RR_BINDING_LIFETIME seconds (see Section 12).
通信員ノードがリターンroutability手順を通して作成されたキーを使用している状態で確立された結合はマックス_RR_BINDING_LIFETIME秒を超えてはいけません(セクション12を見てください)。
The value in the Source Address field in the IPv6 header carrying
the Binding Update is normally also the care-of address which is
used in the binding. However, a different care-of address MAY be
specified by including an Alternate Care-of Address mobility
option in the Binding Update (see Section 6.2.5). When such a
message is sent to the correspondent node and the return
routability procedure is used as the authorization method, the
Care-of Test Init and Care-of Test messages MUST have been
performed for the address in the Alternate Care-of Address option
(not the Source Address). The nonce indices and MAC value MUST be
based on information gained in this test.
通常また、Binding Updateを運ぶIPv6ヘッダーのSource Address分野の値がそうである、注意、-、結合に使用されるアドレス。 しかしながら、a異なる、注意、-、含んでいることによってアドレスが指定されているかもしれないAlternate Care、-、Binding Update(セクション6.2.5を見る)のAddress移動性オプション。 そして、いつ通信員ノードとリターンroutability手順にそのようなメッセージを送るかが承認メソッドとして使用される、Care、-、Test Init、Care、-、Testメッセージがアドレスのために中で実行されたに違いない、Alternate Care、-、Addressオプション(Source Addressでない)。 一回だけのインデックスリストとMAC値をこのテストで獲得された情報に基礎づけなければなりません。
Johnson, et al. Standard Track [Page 28] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[28ページ]のRFC3775移動性サポート
Binding Updates may also be sent to delete a previously
established binding. In this case, generation of the binding
management key depends exclusively on the home keygen token and
the care-of nonce index is ignored.
また、以前に確立した結合を削除するために拘束力があるUpdatesを送るかもしれません。 そして、この場合拘束力がある管理キーの世代を排他的にホームkeygenトークンに依存する、注意、-、一回だけのインデックスは無視されます。
5.2.7. Updating Node Keys and Nonces
5.2.7. ノードキーと一回だけをアップデートします。
Correspondent nodes generate nonces at regular intervals. It is recommended to keep each nonce (identified by a nonce index) acceptable for at least MAX_TOKEN_LIFETIME seconds (see Section 12) after it has been first used in constructing a return routability message response. However, the correspondent node MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 12) after the first use. As the difference between these two constants is 30 seconds, a convenient way to enforce the above lifetimes is to generate a new nonce every 30 seconds. The node can then continue to accept tokens that have been based on the last 8 (MAX_NONCE_LIFETIME / 30) nonces. This results in tokens being acceptable MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been sent to the mobile node, depending on whether the token was sent at the beginning or end of the first 30 second period. Note that the correspondent node may also attempt to generate new nonces on demand, or only if the old nonces have been used. This is possible, as long as the correspondent node keeps track of how long a time ago the nonces were used for the first time, and does not generate new nonces on every return routability request.
通信員ノードは一定の間隔を置いて一回だけを生成します。 _それが最初にリターンroutabilityメッセージ応答を構成する際に使用されたTOKEN_LIFETIME秒(セクション12を見る)後に各一回だけ(一回だけのインデックスで、特定される)を少なくともマックスにとって許容できるように保つのはお勧めです。 しかしながら、通信員ノードは最初の使用のNONCE_LIFETIME秒(セクション12を見る)後にマックス_を超えて一回だけを受け入れてはいけません。 これらの2つの定数の違いが30秒であるので、上の生涯を実施する便利な方法は新しい一回だけが30秒毎であると生成することです。 そして、ノードは、ベスト8(マックス_NONCE_LIFETIME / 30)一回だけに基づいたトークンを受け入れ続けることができます。 _モバイルノードにそれらを送ったNONCE_LIFETIME秒後にこれは許容できる_マックス_TOKEN LIFETIMEであるトークンをマックスにもたらします、最初の30第2ピリオドの始めか終わりにトークンを送ったかどうかによって。 また、要求に応じて、または古い一回だけが使用された場合にだけ通信員ノードが、新しい一回だけを生成するのを試みるかもしれないことに注意してください。 これは、通信員ノードが動向をおさえる限り、一回だけが初めて時前にどれくらい長い間使用されたかに可能であり、あらゆるリターンroutability要求のときに新しい一回だけを生成するというわけではありません。
Due to resource limitations, rapid deletion of bindings, or reboots the correspondent node may not in all cases recognize the nonces that the tokens were based on. If a nonce index is unrecognized, the correspondent node replies with an error code in the Binding Acknowledgement (either 136, 137, or 138 as discussed in Section 6.1.8). The mobile node can then retry the return routability procedure.
リソース制限、結合の急速な削除、またはリブートのため、通信員ノードはすべての場合でトークンが基づいた一回だけを認識しないかもしれません。 一回だけのインデックスが認識されていないなら、エラーコードがBinding Acknowledgement(セクション6.1.8で議論する136、137、または138)にある状態で、通信員ノードは返答します。 そして、モバイルノードはリターンroutability手順を再試行できます。
An update of Kcn SHOULD be done at the same time as an update of a nonce, so that nonce indices can identify both the nonce and the key. Old Kcn values have to be therefore remembered as long as old nonce values.
一回だけのアップデートと同時にKcn SHOULDのアップデートをして、したがって、その一回だけのインデックスリストは一回だけとキーの両方を特定できます。 したがって、古いKcn値は古い一回だけの値と同じくらい長い間、覚えていられなければなりません。
Given that the tokens are normally expected to be usable for MAX_TOKEN_LIFETIME seconds, the mobile node MAY use them beyond a single run of the return routability procedure until MAX_TOKEN_LIFETIME expires. After this the mobile node SHOULD NOT use the tokens. A fast moving mobile node MAY reuse a recent home keygen token from a correspondent node when moving to a new location, and just acquire a new care-of keygen token to show routability in the new location.
トークンがマックス_TOKEN_LIFETIME秒の間、使用可能であると通常予想されるなら、マックス_TOKEN_LIFETIMEが期限が切れるまで、モバイルノードはリターンroutability手順のただ一つの走行を超えてそれらを使用するかもしれません。 この後、モバイルノードSHOULD NOTはトークンを使用します。 速い感動的なモバイルノードが新しい状態で新しい位置に移行するとき、通信員ノードから最近のホームkeygenトークンを再利用して、ただaを取得するかもしれない、注意、-、新しい位置でroutabilityを見せているkeygenトークン。
Johnson, et al. Standard Track [Page 29] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[29ページ]のRFC3775移動性サポート
While this does not save the number of round-trips due to the simultaneous processing of home and care-of return routability tests, there are fewer messages being exchanged, and a potentially long round-trip through the home agent is avoided. Consequently, this optimization is often useful. A mobile node that has multiple home addresses, MAY also use the same care-of keygen token for Binding Updates concerning all of these addresses.
そして、これがホームの同時処理による周遊旅行の数を節約しない、注意、-、routabilityテストを返してください、そして、交換されるより少ないメッセージがあって、長く潜在的にホームのエージェントを通した往復のaは避けられます。 その結果、この最適化はしばしば役に立ちます。 複数のホームアドレスを持って、また同じくらい使用するかもしれないモバイルノード、注意、-、これらのアドレスのすべてに関するBinding Updatesのためのkeygenトークン。
5.2.8. Preventing Replay Attacks
5.2.8. 反射攻撃を防ぎます。
The return routability procedure also protects the participants against replayed Binding Updates through the use of the sequence number and a MAC. Care must be taken when removing bindings at the correspondent node, however. Correspondent nodes must retain bindings and the associated sequence number information at least as long as the nonces used in the authorization of the binding are still valid. Alternatively, if memory is very constrained, the correspondent node MAY invalidate the nonces that were used for the binding being deleted (or some larger group of nonces that they belong to). This may, however, impact the ability to accept Binding Updates from mobile nodes that have recently received keygen tokens. This alternative is therefore recommended only as a last measure.
また、リターンroutability手順は再演されたBinding Updatesに対して一連番号とMACの使用で関係者を保護します。 しかしながら、通信員ノードで結合を取り除くとき、注意しなければなりません。結合の承認に使用される一回だけがまだ有効である限り、通信員ノードは結合と少なくとも関連一連番号情報を保有しなければなりません。 あるいはまた、メモリが非常に制約つきであるなら、通信員ノードは削除される結合(または、それらが属す一回だけの何らかのより大きいグループ)に使用された一回だけを無効にするかもしれません。 しかしながら、これは最近keygenトークンを受けたモバイルノードからBinding Updatesを受け入れる能力に影響を与えるかもしれません。 したがって、この代替手段は最後の手段としてだけお勧めです。
5.3. Dynamic Home Agent Address Discovery
5.3. ダイナミックなホームエージェントアドレス発見
No security is required for dynamic home agent address discovery.
セキュリティは全くダイナミックなホームエージェントアドレス発見に必要ではありません。
5.4. Mobile Prefix Discovery
5.4. モバイル接頭語発見
The mobile node and the home agent SHOULD use an IPsec security association to protect the integrity and authenticity of the Mobile Prefix Solicitations and Advertisements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) header in transport mode with a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection.
モバイルノードとホームのエージェントSHOULDはモバイルPrefix SolicitationsとAdvertisementsの保全と信憑性を保護するIPsecセキュリティ協会を使用します。 モバイルノードとホームのエージェントが支えなければならない両方とSHOULDは、データ発生源認証、コネクションレスな保全、および任意の反反復操作による保護を提供するのに非NULLペイロード認証アルゴリズムで交通機関でEncapsulating Security有効搭載量(超能力)ヘッダーを使用します。
5.5. Payload Packets
5.5. 有効搭載量パケット
Payload packets exchanged with mobile nodes can be protected in the usual manner, in the same way as stationary hosts can protect them. However, Mobile IPv6 introduces the Home Address destination option, a routing header, and tunneling headers in the payload packets. In the following we define the security measures taken to protect these, and to prevent their use in attacks against other parties.
常法でモバイルノードで交換された有効搭載量パケットは保護できます、静止したホストが彼らを保護できるのと同様に。 しかしながら、モバイルIPv6はペイロードパケットでホームAddress目的地オプション、ルーティングヘッダー、およびトンネリングヘッダーを紹介します。 以下では、私たちはこれらを保護して、相手に対して攻撃における彼らの使用を防ぐために取られた安全策を定義します。
Johnson, et al. Standard Track [Page 30] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[30ページ]のRFC3775移動性サポート
This specification limits the use of the Home Address destination option to the situation where the correspondent node already has a Binding Cache entry for the given home address. This avoids the use of the Home Address option in attacks described in Section 15.1.
この仕様はホームAddress目的地オプションの使用を通信員ノードが既に与えられたホームアドレスのためのBinding Cacheエントリーを持っている状況に制限します。 これはセクション15.1で説明された攻撃におけるホームAddressオプションの使用を避けます。
Mobile IPv6 uses a Mobile IPv6 specific type of a routing header. This type provides the necessary functionality but does not open vulnerabilities discussed in Section 15.1.
モバイルIPv6はルーティングヘッダーのモバイルIPv6特定のタイプを使用します。 このタイプは、必要な機能性を提供しますが、セクション15.1で議論した脆弱性を開きません。
Tunnels between the mobile node and the home agent are protected by ensuring proper use of source addresses, and optional cryptographic protection. The mobile node verifies that the outer IP address corresponds to its home agent. The home agent verifies that the outer IP address corresponds to the current location of the mobile node (Binding Updates sent to the home agents are secure). The home agent identifies the mobile node through the source address of the inner packet. (Typically, this is the home address of the mobile node, but it can also be a link-local address, as discussed in Section 10.4.2. To recognize the latter type of addresses, the home agent requires that the Link-Local Address Compatibility (L) was set in the Binding Update.) These measures protect the tunnels against vulnerabilities discussed in Section 15.1.
モバイルノードとホームのエージェントの間のトンネルは、ソースアドレスの適切な使用、および任意の暗号の保護を確実にすることによって、保護されます。 モバイルノードは、外側のIPアドレスがホームのエージェントに文通されることを確かめます。 ホームのエージェントは、外側のIPアドレスがモバイルノードの現在の位置に一致していることを確かめます(ホームのエージェントに送られた拘束力があるUpdatesは安全です)。 ホームのエージェントは内側のパケットのソースアドレスを通してモバイルノードを特定します。 (また、それが後者のタイプのアドレスを認識するためにセクション10.4で.2に議論するようにリンクローカルアドレスであるかもしれない、これは通常、モバイルノードに関するホームアドレスですが、ホームのエージェントはLink地方のAddress Compatibility(L)がBinding Updateで用意ができていたのを必要とします。) これらの測定はセクション15.1で議論した脆弱性に対してトンネルを保護します。
For traffic tunneled via the home agent, additional IPsec ESP encapsulation MAY be supported and used. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported.
ホームのエージェントを通してトンネルを堀られたトラフィックのために、追加IPsec超能力カプセル化は、サポートされて、使用されるかもしれません。 マルチキャストグループ会員資格制御プロトコルかstatefulアドレス自動構成プロトコルがサポートされるなら、ペイロードデータ保護をサポートしなければなりません。
6. New IPv6 Protocol, Message Types, and Destination Option
6. 新しいIPv6プロトコル、メッセージタイプ、および目的地オプション
6.1. Mobility Header
6.1. 移動性ヘッダー
The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. The subsections within this section describe the message types that may be sent using the Mobility Header.
Mobility Headerは結合の作成と管理に関連するすべてのメッセージングでモバイルノード、通信員ノード、およびホームのエージェントによって使用された拡張ヘッダーです。 このセクションの中の小区分はMobility Headerが使用させられるかもしれないメッセージタイプについて説明します。
Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section 9.5.4 for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Section 11.7.1 and Section 11.7.2 for Binding Update. Binding Update List or Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass both the Binding Cache check described in Section 9.3.2 and the Binding Update List check described in Section
タイプ2ルーティングヘッダーと共に移動性Headerメッセージを送ってはいけません、Binding Acknowledgementのためにセクション9.5.4で説明されるのを除いて。 ホームAddress目的地オプションと共に移動性Headerメッセージも使用してはいけません、Binding Updateのためにセクション11.7.1とセクション11.7.2で説明されるのを除いて。 送付Mobility Headerメッセージで目的地のための拘束力があるUpdate ListかBinding Cache情報(存在しているとき)を使用してはいけません。 すなわち、Mobility Headerメッセージはセクション9.3.2で説明されたBinding Cacheチェックとセクションで説明されたBinding Update Listチェックの両方を迂回させます。
Johnson, et al. Standard Track [Page 31] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[31ページ]のRFC3775移動性サポート
11.3.1 which are normally performed for all packets. This applies even to messages sent to or from a correspondent node which is itself a mobile node.
11.3.1 通常、どれがすべてのパケットのために実行されますか? これは通信員ノードからノード、または、それ自体でモバイルノードである送られたメッセージにさえ適用されます。
6.1.1. Format
6.1.1. 形式
The Mobility Header is identified by a Next Header value of 135 in the immediately preceding header, and has the following format:
Mobility Headerはすぐに前のヘッダーの135のNext Header値によって特定されて、以下の形式を持っています:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効搭載量プロト| ヘッダーレン| MHはタイプします。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . メッセージデータ…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Proto
有効搭載量プロト
8-bit selector. Identifies the type of header immediately
following the Mobility Header. Uses the same values as the IPv6
Next Header field [11].
8ビットのセレクタ。 すぐにMobility Headerに続いて、ヘッダーのタイプを特定します。 同じくらいがIPv6 Next Headerとして評価する用途は[11]をさばきます。
This field is intended to be used by a future extension (see
Appendix B.1).
今後の拡大でこの分野が使用されることを意図します(Appendix B.1を見てください)。
Implementations conforming to this specification SHOULD set the
payload protocol type to IPPROTO_NONE (59 decimal).
この仕様SHOULDセットにペイロードプロトコルを従わせる実装が(59小数)をIPPROTO_NONEにタイプします。
Header Len
ヘッダーレン
8-bit unsigned integer, representing the length of the Mobility
Header in units of 8 octets, excluding the first 8 octets.
最初の8つの八重奏を除いて、8つの八重奏のユニットのMobility Headerの長さを表す8ビットの符号のない整数。
The length of the Mobility Header MUST be a multiple of 8 octets.
Mobility Headerの長さは8つの八重奏の倍数であるに違いありません。
MH Type
MHはタイプします。
8-bit selector. Identifies the particular mobility message in
question. Current values are specified in Section 6.1.2 and
onward. An unrecognized MH Type field causes an error indication
to be sent.
8ビットのセレクタ。 問題の特定の移動性メッセージを特定します。 現行価値はセクション6.1.2、そして前方へ指定されます。 認識されていないMH Type分野で、誤り表示を送ります。
Johnson, et al. Standard Track [Page 32] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[32ページ]のRFC3775移動性サポート
Reserved
予約されます。
8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
今後の使用のために予約された8ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Checksum
チェックサム
16-bit unsigned integer. This field contains the checksum of the
Mobility Header. The checksum is calculated from the octet string
consisting of a "pseudo-header" followed by the entire Mobility
Header starting with the Payload Proto field. The checksum is the
16-bit one's complement of the one's complement sum of this
string.
16ビットの符号のない整数。 この分野はMobility Headerのチェックサムを含んでいます。 チェックサムは有効搭載量プロト野原から始まる全体のMobility Headerによって続かれた「疑似ヘッダー」から成る八重奏ストリングで計算されます。 チェックサムはこのストリングの1の補数合計の16ビットの1の補数です。
The pseudo-header contains IPv6 header fields, as specified in
Section 8.1 of RFC 2460 [11]. The Next Header value used in the
pseudo-header is 2. The addresses used in the pseudo-header are
the addresses that appear in the Source and Destination Address
fields in the IPv6 packet carrying the Mobility Header.
疑似ヘッダーはRFC2460[11]のセクション8.1で指定されるようにIPv6ヘッダーフィールドを含んでいます。 疑似ヘッダーで使用されるNext Header値は2です。 疑似ヘッダーで使用されるアドレスはMobility Headerを運びながらIPv6パケットのSourceとDestination Address分野に現れるアドレスです。
Note that the procedures of calculating upper layer checksums
while away from home described in Section 11.3.1 apply even for
the Mobility Header. If a mobility message has a Home Address
destination option, then the checksum calculation uses the home
address in this option as the value of the IPv6 Source Address
field. The type 2 routing header is treated as explained in [11].
計算の上側の層のチェックサムの手順がセクション11.3.1で説明されたホームから離れている間Mobility Headerにさえ申し込むことに注意してください。 移動性メッセージにホームAddress目的地オプションがあるなら、チェックサム計算はIPv6 Source Address分野の値としてこのオプションにホームアドレスを使用します。 タイプ2ルーティングヘッダーは[11]で説明されるように扱われます。
The Mobility Header is considered as the upper layer protocol for
the purposes of calculating the pseudo-header. The Upper-Layer
Packet Length field in the pseudo-header MUST be set to the total
length of the Mobility Header.
Mobility Headerは疑似ヘッダーについて計算する目的のための上側の層のプロトコルであるとみなされます。 疑似ヘッダーのUpper-層のPacket Length分野をMobility Headerの全長に設定しなければなりません。
For computing the checksum, the checksum field is set to zero.
チェックサムを計算するのにおいて、チェックサム分野はゼロに設定されます。
Message Data
メッセージデータ
A variable length field containing the data specific to the
indicated Mobility Header type.
示されたMobility Headerタイプに、特定のデータを含む可変長フィールド。
Mobile IPv6 also defines a number of "mobility options" for use within these messages; if included, any options MUST appear after the fixed portion of the message data specified in this document. The presence of such options will be indicated by the Header Len field within the message. When the Header Len value is greater than the length required for the message specified here, the remaining octets are interpreted as mobility options. These options include padding options that can be used to ensure that other options are aligned
また、モバイルIPv6はこれらのメッセージの中の使用のための多くの「移動性オプション」を定義します。 含まれているなら、メッセージデータの固定部分が本書では指定した後にどんなオプションも現れなければなりません。 そのようなオプションの存在はメッセージの中にHeaderレン分野によって示されるでしょう。 Headerレン価値が長さがここで指定されたメッセージに必要であるというよりも大きいときに、残っている八重奏は移動性オプションとして解釈されます。 これらのオプションは、別の選択肢が並べられるのを保証するのに使用できるオプションを水増しするのを含んでいます。
Johnson, et al. Standard Track [Page 33] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[33ページ]のRFC3775移動性サポート
properly, and that the total length of the message is divisible by 8. The encoding and format of defined options are described in Section 6.2.
適切である、メッセージの全長は8で分割可能です。 定義されたオプションのコード化と形式はセクション6.2で説明されます。
Alignment requirements for the Mobility Header are the same as for any IPv6 protocol Header. That is, they MUST be aligned on an 8- octet boundary.
Mobility Headerのための整列要求はどんなIPv6プロトコルHeaderのようにも同じです。 8八重奏境界ですなわち、それらを並べなければなりません。
6.1.2. Binding Refresh Request Message
6.1.2. 付いて、要求メッセージをリフレッシュしてください。
The Binding Refresh Request (BRR) message requests a mobile node to update its mobility binding. This message is sent by correspondent nodes according to the rules in Section 9.5.5. When a mobile node receives a packet containing a Binding Refresh Request message it processes the message according to the rules in Section 11.7.4.
Binding Refresh Request(BRR)メッセージは、移動性結合をアップデートするようモバイルノードに要求します。 セクション9.5.5における規則に従って、通信員ノードはこのメッセージを送ります。 モバイルノードがBinding Refresh Requestメッセージを含むパケットを受けるとき、セクション11.7.4における規則に従って、それはメッセージを処理します。
The Binding Refresh Request message uses the MH Type value 0. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
Binding Refresh RequestメッセージはMH Type値0を使用します。 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約されます。
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
今後の使用のために予約された16ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2. The
receiver MUST ignore and skip any options which it does not
understand.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 定義されたオプションのコード化と形式はセクション6.2で説明されます。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。
Johnson, et al. Standard Track [Page 34] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[34ページ]のRFC3775移動性サポート
There MAY be additional information, associated with this Binding
Refresh Request message that need not be present in all Binding
Refresh Request messages sent. Mobility options allow future
extensions to the format of the Binding Refresh Request message to
be defined. This specification does not define any options valid
for the Binding Refresh Request message.
追加情報があるかもしれません、Binding Refresh Requestメッセージが送ったすべてで必要性が存在していないというこのBinding Refresh Requestメッセージに関連しています。 移動性オプションは定義されるべきBinding Refresh Requestメッセージの形式に今後の拡大を許します。 この仕様はBinding Refresh Requestメッセージに、有効な少しのオプションも定義しません。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 0.
どんな実際のオプションもこのメッセージに存在していないなら、水増しでないのが必要です、そして、Headerレン分野は0に設定されるでしょう。
6.1.3. Home Test Init Message
6.1.3. ホームテストイニットメッセージ
A mobile node uses the Home Test Init (HoTI) message to initiate the return routability procedure and request a home keygen token from a correspondent node (see Section 11.6.1). The Home Test Init message uses the MH Type value 1. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
モバイルノードはリターンroutability手順に着手して、通信員ノードからホームkeygenトークンを要求するホームTest Init(HoTI)メッセージを使用します(セクション11.6.1を見てください)。 ホームTest InitメッセージはMH Type値1を使用します。 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ホームイニットクッキー+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約されます。
16-bit field reserved for future use. This value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
今後の使用のために予約された16ビットの分野。 この値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Home Init Cookie
ホームイニットクッキー
64-bit field which contains a random value, the home init cookie.
無作為の値、ホームイニットクッキーを含む64ビットの分野。
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 受信機
Johnson, et al. Standard Track [Page 35] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[35ページ]のRFC3775移動性サポート
MUST ignore and skip any options which it does not understand.
This specification does not define any options valid for the Home
Test Init message.
それが理解していない少しのオプションも無視して、サボらなければなりません。 この仕様はホームTest Initメッセージに、有効な少しのオプションも定義しません。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 1.
どんな実際のオプションもこのメッセージに存在していないなら、水増しでないのが必要です、そして、Headerレン分野は1に設定されるでしょう。
This message is tunneled through the home agent when the mobile node is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between the home agent and the mobile node. This protection is indicated by the IPsec security policy database. The protection of Home Test Init messages is unrelated to the requirement to protect regular payload traffic, which MAY use such tunnels as well.
モバイルノードが家にいないときに、このメッセージはホームのエージェントを通してトンネルを堀られます。 そのようなトンネリングSHOULDはIPsecを使います。ホームのエージェントとモバイルノードの間のトンネルモードにおける超能力。 この保護はIPsec安全保障政策データベースによって示されます。 ホームTest Initメッセージの保護はまた、そのようなトンネルを使用するかもしれない通常のペイロードトラフィックを保護するという要件に関係ありません。
6.1.4. Care-of Test Init Message
6.1.4. 注意、-、テストイニットメッセージ
A mobile node uses the Care-of Test Init (CoTI) message to initiate the return routability procedure and request a care-of keygen token from a correspondent node (see Section 11.6.1). The Care-of Test Init message uses the MH Type value 2. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
モバイルノードが使用する、Care、-、リターンroutability手順と要求に着手するTest Init(CoTI)メッセージ、注意、-、keygenトークン、通信員ノード(セクション11.6.1を見る)から。 Care、-、MH Typeが2に評価するTest Initメッセージ用途 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +、注意、-、イニットクッキー+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
予約されます。
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
今後の使用のために予約された16ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Care-of Init Cookie
注意、-、イニットクッキー
64-bit field which contains a random value, the care-of init
cookie.
無作為の値を含む64ビットの分野、注意、-、イニットクッキー
Johnson, et al. Standard Track [Page 36] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[36ページ]のRFC3775移動性サポート
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options which it does not understand.
This specification does not define any options valid for the
Care-of Test Init message.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。 この仕様が有効な状態で少しのオプションも定義しない、Care、-、Test Initメッセージ。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 1.
どんな実際のオプションもこのメッセージに存在していないなら、水増しでないのが必要です、そして、Headerレン分野は1に設定されるでしょう。
6.1.5. Home Test Message
6.1.5. ホームテストメッセージ
The Home Test (HoT) message is a response to the Home Test Init message, and is sent from the correspondent node to the mobile node (see Section 5.2.5). The Home Test message uses the MH Type value 3. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
ホームTest(HoT)メッセージをホームTest Initメッセージへの応答であり、通信員ノードからモバイルノードに送ります(セクション5.2.5を見てください)。 ホームTestメッセージはMH Type値3を使用します。 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホーム一回だけインデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ホームイニットクッキー+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ホームKeygenトークン+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Nonce Index
ホーム一回だけインデックス
This field will be echoed back by the mobile node to the
correspondent node in a subsequent Binding Update.
この分野はモバイルノードによってその後のBinding Updateの通信員ノードにecho backにされるでしょう。
Home Init Cookie
ホームイニットクッキー
64-bit field which contains the home init cookie.
ホームイニットクッキーを含む64ビットの分野。
Johnson, et al. Standard Track [Page 37] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[37ページ]のRFC3775移動性サポート
Home Keygen Token
ホームKeygenトークン
This field contains the 64 bit home keygen token used in the
return routability procedure.
この分野はリターンroutability手順で使用される64ビットのホームkeygenトークンを含んでいます。
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options which it does not understand.
This specification does not define any options valid for the Home
Test message.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。 この仕様はホームTestメッセージに、有効な少しのオプションも定義しません。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2.
どんな実際のオプションもこのメッセージに存在していないなら、水増しでないのが必要です、そして、Headerレン分野は2に設定されるでしょう。
6.1.6. Care-of Test Message
6.1.6. 注意、-、テストメッセージ
The Care-of Test (CoT) message is a response to the Care-of Test Init message, and is sent from the correspondent node to the mobile node (see Section 11.6.2). The Care-of Test message uses the MH Type value 4. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
Care、-、Test(CoT)メッセージが応答である、Care、-、Test Initメッセージ、通信員ノードからモバイルノード(セクション11.6.2を見る)に送ります。 Care、-、MH Typeが4に評価するTestメッセージ用途 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意、-、一回だけのインデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +、注意、-、イニットクッキー+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +、注意、-、Keygenトークン+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Care-of Nonce Index
注意、-、一回だけのインデックス
This value will be echoed back by the mobile node to the
correspondent node in a subsequent Binding Update.
この値はモバイルノードによってその後のBinding Updateの通信員ノードにecho backにされるでしょう。
Johnson, et al. Standard Track [Page 38] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[38ページ]のRFC3775移動性サポート
Care-of Init Cookie
注意、-、イニットクッキー
64-bit field which contains the care-of init cookie.
64ビットがどれをさばくか、含有、注意、-、イニットクッキー。
Care-of Keygen Token
注意、-、Keygenトークン
This field contains the 64 bit care-of keygen token used in the
return routability procedure.
この分野が64ビットを含んでいる、注意、-、リターンroutability手順で使用されるkeygenトークン。
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options which it does not understand.
This specification does not define any options valid for the
Care-of Test message.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。 この仕様が有効な状態で少しのオプションも定義しない、Care、-、Testメッセージ。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2.
どんな実際のオプションもこのメッセージに存在していないなら、水増しでないのが必要です、そして、Headerレン分野は2に設定されるでしょう。
6.1.7. Binding Update Message
6.1.7. 拘束力があるアップデートメッセージ
The Binding Update (BU) message is used by a mobile node to notify other nodes of a new care-of address for itself. Binding Updates are sent as described in Section 11.7.1 and Section 11.7.2.
Binding Update(BU)メッセージがモバイルノードによって使用されて、新しい状態でaの他のノードに通知する、注意、-、それ自体のためのアドレス。 セクション11.7.1とセクション11.7.2で説明されるように拘束力があるUpdatesを送ります。
The Binding Update uses the MH Type value 5. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
Binding UpdateはMH Type値5を使用します。 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| 予約されます。| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledge (A)
承認します。(A)
The Acknowledge (A) bit is set by the sending mobile node to
request a Binding Acknowledgement (Section 6.1.8) be returned upon
receipt of the Binding Update.
送付のモバイルノードで、Acknowledge(A)ビットが、Binding Acknowledgement(セクション6.1.8)がBinding Updateを受け取り次第返されるよう要求するように設定されます。
Johnson, et al. Standard Track [Page 39] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[39ページ]のRFC3775移動性サポート
Home Registration (H)
本国登録(H)
The Home Registration (H) bit is set by the sending mobile node to
request that the receiving node should act as this node's home
agent. The destination of the packet carrying this message MUST
be that of a router sharing the same subnet prefix as the home
address of the mobile node in the binding.
送付のモバイルノードで、ホームRegistration(H)ビットが、受信ノードがこのノードのホームのエージェントとして務めるはずであるよう要求するように設定されます。 ルータのものがモバイルノードに関するホームアドレスと同じ共有しているサブネット接頭語であったに違いないなら結合でこのメッセージを伝えるパケットの目的地。
Link-Local Address Compatibility (L)
リンクローカルアドレスの互換性(L)
The Link-Local Address Compatibility (L) bit is set when the home
address reported by the mobile node has the same interface
identifier as the mobile node's link-local address.
モバイルノードによって報告されたホームアドレスがモバイルノードのリンクローカルアドレスと同じインタフェース識別子を持っていると、Link地方のAddress Compatibility(L)ビットは設定されます。
Key Management Mobility Capability (K)
Key Management移動性能力(K)
If this bit is cleared, the protocol used for establishing the
IPsec security associations between the mobile node and the home
agent does not survive movements. It may then have to be rerun.
(Note that the IPsec security associations themselves are expected
to survive movements.) If manual IPsec configuration is used, the
bit MUST be cleared.
このビットがきれいにされるなら、モバイルノードとホームのエージェントとのIPsecセキュリティ仲間を設立するのに使用されるプロトコルは動きを乗り切っていません。 そして、それは再放送されなければならないかもしれません。 (IPsecセキュリティ協会自体が動きを乗り切ると予想されることに注意してください。) 手動のIPsec構成が使用されているなら、ビットをきれいにしなければなりません。
This bit is valid only in Binding Updates sent to the home agent,
and MUST be cleared in other Binding Updates. Correspondent nodes
MUST ignore this bit.
このビットをホームのエージェントに送られたBinding Updatesだけで有効であり、他のBinding Updatesできれいにしなければなりません。 通信員ノードはこのビットを無視しなければなりません。
Reserved
予約されます。
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
これらの分野は未使用です。 それらを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Sequence #
系列#
A 16-bit unsigned integer used by the receiving node to sequence
Binding Updates and by the sending node to match a returned
Binding Acknowledgement with this Binding Update.
系列Binding Updatesへの受信ノードと送付ノードによって使用される、返されたBinding AcknowledgementをこのBinding Updateに合わせる16ビットの符号のない整数。
Lifetime
生涯
16-bit unsigned integer. The number of time units remaining
before the binding MUST be considered expired. A value of zero
indicates that the Binding Cache entry for the mobile node MUST be
deleted. (In this case the specified care-of address MUST also be
set equal to the home address.) One time unit is 4 seconds.
16ビットの符号のない整数。 結合を考えなければならない前に残っているタイム・ユニットの数は期限が切れました。 ゼロの値は、モバイルノードのためのBinding Cacheエントリーを削除しなければならないのを示します。 (この場合指定、注意、-、また、アドレスがホームアドレスと等しいセットであるに違いない、) あるとき、ユニットは4秒です。
Johnson, et al. Standard Track [Page 40] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[40ページ]のRFC3775移動性サポート
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2. The
receiver MUST ignore and skip any options which it does not
understand.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 定義されたオプションのコード化と形式はセクション6.2で説明されます。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。
The following options are valid in a Binding Update:
以下のオプションはBinding Updateで有効です:
* Binding Authorization Data option (this option is mandatory in
Binding Updates sent to a correspondent node)
* 拘束力があるAuthorization Dataオプション(このオプションは通信員ノードに送られたBinding Updatesで義務的です)
* Nonce Indices option.
* 一回だけのIndicesオプション。
* Alternate Care-of Address option
* 代替のCare、-、Addressオプション
If no options are present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1.
どんなオプションもこのメッセージに存在していないなら、詰め物の4つの八重奏が必要です、そして、Headerレン分野は1に設定されるでしょう。
The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. The care-of address MUST be a unicast routable address. IPv6 Source Address MUST be a topologically correct source address. Binding Updates for a care-of address which is not a unicast routable address MUST be silently discarded. Similarly, the Binding Update MUST be silently discarded if the care-of address appears as a home address in an existing Binding Cache entry, with its current location creating a circular reference back to the home address specified in the Binding Update (possibly through additional entries).
注意、-、アドレス、指定される、Alternate Care、-、Addressオプション存在しているなら。 注意、-、アドレスはユニキャスト発送可能アドレスであるに違いありません。 IPv6 Source Addressによるaがソースアドレスを位相的に修正するということでなければなりません。 aのための拘束力があるUpdates、注意、-、静かにユニキャスト発送可能アドレスでないアドレスを捨てなければなりません。 同様に、静かにBinding Updateを捨てなければならない、注意、-、アドレス、現在の位置がホームアドレスの循環参照を作成している既存のBinding Cacheエントリーにおけるホームアドレスとして、Binding Update(ことによると追加エントリーによる)で指定されているのに現れます。
The deletion of a binding can be indicated by setting the Lifetime field to 0 and by setting the care-of address equal to the home address. In deletion, the generation of the binding management key depends exclusively on the home keygen token, as explained in Section 5.2.5. (Note that while the senders are required to set both the Lifetime field to 0 and the care-of address equal to the home address, Section 9.5.1 rules for receivers are more liberal, and interpret either condition as a deletion.)
Lifetime分野を0に設定して、設定で結合の削除を示すことができる、注意、-、同輩にホームアドレスに演説してください。 削除では、拘束力がある管理キーの世代を排他的にホームkeygenトークンに依存します、セクション5.2.5で説明されるように。 そして、(送付者がLifetimeが0としてさばく両方を設定しなければならない間、それに注意してください、注意、-、ホームアドレスと等しいアドレス、受信機のためのセクション9.5.1の規則が、より寛容であり、a削除としてどちらの状態も解釈してください、)
Correspondent nodes SHOULD NOT delete the Binding Cache entry before the lifetime expires, if any application hosted by the correspondent node is still likely to require communication with the mobile node. A Binding Cache entry that is de-allocated prematurely might cause subsequent packets to be dropped from the mobile node, if they contain the Home Address destination option. This situation is recoverable, since a Binding Error message is sent to the mobile node
寿命が期限が切れる前に通信員ノードSHOULD NOTはBinding Cacheエントリーを削除します、通信員ノードによって主催されたどれかアプリケーションがまだモバイルノードとのコミュニケーションが必要でありそうであるなら。 早まって反-割り当てられるBinding Cacheエントリーでモバイルノードからその後のパケットを下げるかもしれません、ホームAddress目的地オプションを含んでいるなら。 この状況は、Binding Errorメッセージをモバイルノードに送るので、回復可能です。
Johnson, et al. Standard Track [Page 41] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[41ページ]のRFC3775移動性サポート
(see Section 6.1.9); however, it causes unnecessary delay in the communications.
(セクション6.1.9を)見てください。 しかしながら、それはコミュニケーションの不要な遅れを引き起こします。
6.1.8. Binding Acknowledgement Message
6.1.8. 拘束力がある確認メッセージ
The Binding Acknowledgement is used to acknowledge receipt of a Binding Update (Section 6.1.7). This packet is sent as described in Section 9.5.4 and Section 10.3.1.
Binding Acknowledgementは、Binding Update(セクション6.1.7)の領収書を受け取ったことを知らせるのに使用されます。 セクション9.5.4とセクション10.3.1で説明されるようにこのパケットを送ります。
The Binding Acknowledgement has the MH Type value 6. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
Binding Acknowledgementには、MH Type値6があります。 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態|K| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Management Mobility Capability (K)
Key Management移動性能力(K)
If this bit is cleared, the protocol used by the home agent for
establishing the IPsec security associations between the mobile
node and the home agent does not survive movements. It may then
have to be rerun. (Note that the IPsec security associations
themselves are expected to survive movements.)
このビットがきれいにされるなら、モバイルノードとホームのエージェントとのIPsecセキュリティ仲間を設立するのにホームのエージェントによって使用されたプロトコルは動きを乗り切っていません。 そして、それは再放送されなければならないかもしれません。 (IPsecセキュリティ協会自体が動きを乗り切ると予想されることに注意してください。)
Correspondent nodes MUST set the K bit to 0.
通信員ノードはKビットを0に設定しなければなりません。
Reserved
予約されます。
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
これらの分野は未使用です。 それらを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Johnson, et al. Standard Track [Page 42] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[42ページ]のRFC3775移動性サポート
Status
状態
8-bit unsigned integer indicating the disposition of the Binding
Update. Values of the Status field less than 128 indicate that
the Binding Update was accepted by the receiving node. Values
greater than or equal to 128 indicate that the Binding Update was
rejected by the receiving node. The following Status values are
currently defined:
Binding Updateの気質を示す8ビットの符号のない整数。 128未満のStatus分野の値は、Binding Updateが受信ノードによって受け入れられたのを示します。 値より多くの128は、Binding Updateが受信ノードによって拒絶されたのを示します。 以下のStatus値は現在、定義されます:
0 Binding Update accepted
0 拘束力があるUpdateは受け入れました。
1 Accepted but prefix discovery necessary
1は、接頭語発見だけが必要であると受け入れました。
128 Reason unspecified
128は不特定の状態で推論します。
129 Administratively prohibited
129は行政上禁止しました。
130 Insufficient resources
130 不十分なリソース
131 Home registration not supported
131 登録がサポートしなかったホーム
132 Not home subnet
132 ホームサブネットでない
133 Not home agent for this mobile node
133 このモバイルノードのためのホームのエージェントでない
134 Duplicate Address Detection failed
134 写しAddress Detectionは失敗しました。
135 Sequence number out of window
窓からの135一連番号
136 Expired home nonce index
136の満期のホーム一回だけインデックス
137 Expired care-of nonce index
137が期限が切れた、注意、-、一回だけのインデックス
138 Expired nonces
138 満期の一回だけ
139 Registration type change disallowed
139 禁じられた登録タイプ変化
Up-to-date values of the Status field are to be specified in the IANA registry of assigned numbers [19].
Status分野の最新の値は規定番号[19]のIANA登録で指定されることです。
Sequence #
系列#
The Sequence Number in the Binding Acknowledgement is copied from
the Sequence Number field in the Binding Update. It is used by
the mobile node in matching this Binding Acknowledgement with an
outstanding Binding Update.
Binding AcknowledgementのSequence NumberはBinding UpdateのSequence Number分野からコピーされます。 それはモバイルノードによってこのBinding Acknowledgementを傑出しているBinding Updateに合わせる際に使用されます。
Johnson, et al. Standard Track [Page 43] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[43ページ]のRFC3775移動性サポート
Lifetime
生涯
The granted lifetime, in time units of 4 seconds, for which this
node SHOULD retain the entry for this mobile node in its Binding
Cache.
4秒のタイム・ユニットの与えられた生涯。(このノードSHOULDは秒の間、Binding Cacheのこのモバイルノードのためのエントリーを保有します)。
The value of this field is undefined if the Status field indicates
that the Binding Update was rejected.
Status分野が、Binding Updateが拒絶されたのを示すなら、この分野の値は未定義です。
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The encoding
and format of defined options are described in Section 6.2. The
receiver MUST ignore and skip any options which it does not
understand.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 定義されたオプションのコード化と形式はセクション6.2で説明されます。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。
There MAY be additional information, associated with this Binding
Acknowledgement that need not be present in all Binding
Acknowledgements sent. Mobility options allow future extensions
to the format of the Binding Acknowledgement to be defined. The
following options are valid for the Binding Acknowledgement:
必要性がBinding Acknowledgementsが送ったすべてに存在していないというこのBinding Acknowledgementに関連づけられた追加情報があるかもしれません。 移動性オプションは、Binding Acknowledgementの形式への今後の拡大が定義されるのを許容します。 Binding Acknowledgementに、以下のオプションは有効です:
* Binding Authorization Data option (this option is mandatory in
Binding Acknowledgements sent by a correspondent node, except
where otherwise noted in Section 9.5.4)
* 拘束力があるAuthorization Dataオプション(このオプションは別の方法でセクション9.5.4で述べられるところを除いて、通信員ノードによって送られたBinding Acknowledgementsで義務的です)
* Binding Refresh Advice option
* 拘束力があるRefresh Adviceオプション
If no options are present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1.
どんなオプションもこのメッセージに存在していないなら、詰め物の4つの八重奏が必要です、そして、Headerレン分野は1に設定されるでしょう。
6.1.9. Binding Error Message
6.1.9. 拘束力があるエラーメッセージ
The Binding Error (BE) message is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding; see Section 9.3.3 for details.
Binding Error(ある)メッセージは通信員ノードによって使用されて、移動性に関連する誤りに合図します、既存の結合なしでホームAddress目的地オプションを使用する不適当な試みのように。 詳細に関してセクション9.3.3を見てください。
Johnson, et al. Standard Track [Page 44] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[44ページ]のRFC3775移動性サポート
The Binding Error message uses the MH Type value 7. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
Binding ErrorメッセージはMH Type値7を使用します。 この値がMH Type分野で示されるとき、Mobility HeaderのMessage Data分野の形式は以下の通りです:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + ホームアドレス+| | + + | | +++++++++++++++++++++++++++++++++… 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
状態
8-bit unsigned integer indicating the reason for this message.
The following values are currently defined:
このメッセージの理由を示す8ビットの符号のない整数。 以下の値は現在、定義されます:
1 Unknown binding for Home Address destination option
1 ホームAddress目的地オプションのための未知の結合
2 Unrecognized MH Type value
2 認識されていないMH Type値
Reserved
予約されます。
A 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
今後の使用のために予約された8ビットの分野。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Home Address
ホームアドレス
The home address that was contained in the Home Address
destination option. The mobile node uses this information to
determine which binding does not exist, in cases where the mobile
node has several home addresses.
ホームAddress目的地オプションに含まれたホームアドレス。 モバイルノードはどの結合が存在しないかを決定するのにこの情報を使用します、モバイルノードがいくつかのホームアドレスを持っている場合で。
Johnson, et al. Standard Track [Page 45] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[45ページ]のRFC3775移動性サポート
Mobility Options
移動性オプション
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. The receiver
MUST ignore and skip any options which it does not understand.
完全なMobility Headerが長い間8つの八重奏の整数倍数である長さの可変長の分野。 この分野はゼロかTLVによって、よりコード化された移動性オプションを含んでいます。 受信機は、それが理解していない少しのオプションも無視して、サボらなければなりません。
There MAY be additional information, associated with this Binding
Error message that need not be present in all Binding Error
messages sent. Mobility options allow future extensions to the
format of the format of the Binding Error message to be defined.
The encoding and format of defined options are described in
Section 6.2. This specification does not define any options valid
for the Binding Error message.
追加情報があるかもしれません、Binding Errorメッセージが送ったすべてで必要性が存在していないというこのBinding Errorメッセージに関連しています。 移動性オプションは定義されるべきBinding Errorメッセージの形式の形式に今後の拡大を許します。 定義されたオプションのコード化と形式はセクション6.2で説明されます。 この仕様はBinding Errorメッセージに、有効な少しのオプションも定義しません。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2.
どんな実際のオプションもこのメッセージに存在していないなら、水増しでないのが必要です、そして、Headerレン分野は2に設定されるでしょう。
6.2. Mobility Options
6.2. 移動性オプション
Mobility messages can include zero or more mobility options. This allows optional fields that may not be needed in every use of a particular Mobility Header, as well as future extensions to the format of the messages. Such options are included in the Message Data field of the message itself, after the fixed portion of the message data specified in the message subsections of Section 6.1.
移動性メッセージはゼロか、より多くの移動性オプションを含むことができます。 これは特定のMobility Headerをあらゆる使用で必要であるかもしれないというわけではない任意の分野を許容します、メッセージの形式への今後の拡大と同様に。 そのようなオプションはメッセージ自体のMessage Data分野に含まれています、メッセージデータの固定部分がセクション6.1のメッセージ小区分で指定した後に。
The presence of such options will be indicated by the Header Len of the Mobility Header. If included, the Binding Authorization Data option (Section 6.2.7) MUST be the last option and MUST NOT have trailing padding. Otherwise, options can be placed in any order.
そのようなオプションの存在はMobility HeaderのHeaderレンによって示されるでしょう。 含まれているなら、Binding Authorization Dataオプション(セクション6.2.7)は、最後のオプションでなければならなく、引きずっている詰め物を持ってはいけません。 さもなければ、順不同にオプションを置くことができます。
6.2.1. Format
6.2.1. 形式
Mobility options are encoded within the remaining space of the Message Data field of a mobility message, using a type-length-value (TLV) format as follows:
移動性オプションは移動性メッセージのMessage Data分野の残っているスペースの中でコード化されます、以下のタイプ長さの価値(TLV)の形式を使用して:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| オプションデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, et al. Standard Track [Page 46] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[46ページ]のRFC3775移動性サポート
Option Type
オプションタイプ
8-bit identifier of the type of mobility option. When processing
a Mobility Header containing an option for which the Option Type
value is not recognized by the receiver, the receiver MUST quietly
ignore and skip over the option, correctly handling any remaining
options in the message.
移動性オプションのタイプの8ビットの識別子。 Option Type値が受信機によって認識されないオプションを含むMobility Headerを処理するとき、受信機は、静かにオプションを無視して、飛ばさなければなりません、正しくメッセージにおけるどんな残っているオプションも扱って。
Option Length
オプションの長さ
8-bit unsigned integer, representing the length in octets of the
mobility option, not including the Option Type and Option Length
fields.
Option TypeとOption Length分野を含んでいるのではなく、移動性オプションの八重奏における長さを表す8ビットの符号のない整数。
Option Data
オプションデータ
A variable length field that contains data specific to the option.
オプションに特定のデータを含む可変長フィールド。
The following subsections specify the Option types which are currently defined for use in the Mobility Header.
以下の小区分は現在Mobility Headerにおける使用のために定義されるOptionタイプを指定します。
Implementations MUST silently ignore any mobility options that they do not understand.
実装は静かに、彼らが理解していない少しの移動性オプションも無視しなければなりません。
Mobility options may have alignment requirements. Following the convention in IPv6, these options are aligned in a packet so that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8) [11].
移動性オプションには、整列要求があるかもしれません。 IPv6のコンベンションに続いて、これらのオプションは、それぞれのオプションのOption Data分野の中のマルチ八重奏値が固有の境界(すなわち、幅のn八重奏の野原はヘッダーの始まりからn八重奏の整数倍数に置かれます、n=1、2、4、または8のために)[11]の責任となるように、パケットで並べられます。
6.2.2. Pad1
6.2.2. Pad1
The Pad1 option does not have any alignment requirements. Its format is as follows:
Pad1オプションには、どんな整列要求もありません。 形式は以下の通りです:
0
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | =0をタイプしてください。| +-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 option is a special case - it has neither Option Length nor Option Data fields.
注意!Pad1オプションの形式は特別なケースです--それには、Option LengthもOption Data分野もありません。
Johnson, et al. Standard Track [Page 47] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[47ページ]のRFC3775移動性サポート
The Pad1 option is used to insert one octet of padding in the Mobility Options area of a Mobility Header. If more than one octet of padding is required, the PadN option, described next, should be used rather than multiple Pad1 options.
Pad1オプションは、Mobility HeaderのMobility Options領域でそっと歩く1つの八重奏を挿入するのに使用されます。 詰め物の1つ以上の八重奏が必要であるなら、次に説明されたPadNオプションは複数のPad1オプションよりむしろ使用されるべきです。
6.2.3. PadN
6.2.3. PadN
The PadN option does not have any alignment requirements. Its format is as follows:
PadNオプションには、どんな整列要求もありません。 形式は以下の通りです:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Type = 1 | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | =1をタイプしてください。| オプションの長さ| データ+++++++++++++++++をゆだねてください、-、--、--、--、--、--、--、--、-
The PadN option is used to insert two or more octets of padding in the Mobility Options area of a mobility message. For N octets of padding, the Option Length field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. PadN Option data MUST be ignored by the receiver.
PadNオプションは、移動性メッセージのMobility Options領域でそっと歩く2つ以上の八重奏を挿入するのに使用されます。 詰め物のN八重奏のために、Option Length分野は値のN-2を含んでいます、そして、Option DataはN-2の無貴重な八重奏から成ります。 受信機でPadN Optionデータを無視しなければなりません。
6.2.4. Binding Refresh Advice
6.2.4. 付いて、アドバイスをリフレッシュしてください。
The Binding Refresh Advice option has an alignment requirement of 2n. Its format is as follows:
Binding Refresh Adviceオプションには、2nの整列要求があります。 形式は以下の通りです:
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 = 2 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =2をタイプしてください。| 長さ=2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 間隔をリフレッシュしてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Refresh Advice option is only valid in the Binding Acknowledgement, and only on Binding Acknowledgements sent from the mobile node's home agent in reply to a home registration. The Refresh Interval is measured in units of four seconds, and indicates remaining time until the mobile node SHOULD send a new home registration to the home agent. The Refresh Interval MUST be set to indicate a smaller time interval than the Lifetime value of the Binding Acknowledgement.
Binding Refresh AdviceオプションはBinding Acknowledgementと、そして、本国登録に対してモバイルノードのホームのエージェントから送られたBinding Acknowledgementsだけの上で有効であるだけです。 Refresh Intervalは4秒の単位で測定されて、モバイルノードSHOULDが新しい本国登録をホームのエージェントに送るまで、残っている時間を示します。 Refresh IntervalはBinding AcknowledgementのLifetime値より小さい時間間隔を示すように用意ができなければなりません。
Johnson, et al. Standard Track [Page 48] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[48ページ]のRFC3775移動性サポート
6.2.5. Alternate Care-of Address
6.2.5. 代替治療、-、アドレス
The Alternate Care-of Address option has an alignment requirement of 8n+6. Its format is as follows:
Alternate Care、-、Addressオプションには、8n+6の整列要求があります。 形式は以下の通りです:
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 = 3 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =3をタイプしてください。| 長さ=16| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 代替治療、-、+であると扱います。| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Normally, a Binding Update specifies the desired care-of address in the Source Address field of the IPv6 header. However, this is not possible in some cases, such as when the mobile node wishes to indicate a care-of address which it cannot use as a topologically correct source address (Section 6.1.7 and Section 11.7.2) or when the used security mechanism does not protect the IPv6 header (Section 11.7.1).
通常、Binding Updateが指定する、必要である、注意、-、アドレス、IPv6ヘッダーのSource Address分野で。 しかしながら、いくつかの場合、これは可能ではありません、モバイルノードがaを示したがっている時のように注意、-、それがaがソースアドレス(セクション6.1.7とセクション11.7.2)を位相的に修正するか、中古のセキュリティー対策であるときに時使用できないアドレスがIPv6ヘッダー(セクション11.7.1)を保護しません。
The Alternate Care-of Address option is provided for these situations. This option is valid only in Binding Update. The Alternate Care-of Address field contains an address to use as the care-of address for the binding, rather than using the Source Address of the packet as the care-of address.
Alternate Care、-、Addressオプションをこれらの状況に提供します。 このオプションはBinding Updateだけで有効です。 Alternate Care、-、Address分野が使用するアドレスを含んでいる、注意、-、パケットのSource Addressを使用するよりむしろ結合のためのアドレス、注意、-、アドレス
6.2.6. Nonce Indices
6.2.6. 一回だけのインデックスリスト
The Nonce Indices option has an alignment requirement of 2n. Its format is as follows:
Nonce Indicesオプションには、2nの整列要求があります。 形式は以下の通りです:
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 = 4 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =4をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ホーム一回だけインデックス| 注意、-、一回だけのインデックス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, et al. Standard Track [Page 49] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[49ページ]のRFC3775移動性サポート
The Nonce Indices option is valid only in the Binding Update message sent to a correspondent node, and only when present together with a Binding Authorization Data option. When the correspondent node authorizes the Binding Update, it needs to produce home and care-of keygen tokens from its stored random nonce values.
Nonce IndicesオプションはBinding Authorization Dataオプションに伴う現在の通信員ノード、およびいつだけに送られたBinding Updateメッセージだけで有効です。 そして、通信員ノードがBinding Updateを認可すると、ホームを生産するのが必要である、注意、-、保存された無作為の一回だけの値からのkeygenトークン。
The Home Nonce Index field tells the correspondent node which nonce value to use when producing the home keygen token.
ホームNonce Index分野は、ホームkeygenトークンを生産するとき、どの一回だけの値を使用したらよいかを通信員ノードに言います。
The Care-of Nonce Index field is ignored in requests to delete a binding. Otherwise, it tells the correspondent node which nonce value to use when producing the care-of keygen token.
Care、-、Nonce Index分野は結合を削除するという要求で無視されます。 そうでなく、生産するとき、どの一回だけの値を使用したらよいかを通信員ノードに言う、注意、-、keygenトークン
6.2.7. Binding Authorization Data
6.2.7. 拘束力がある承認データ
The Binding Authorization Data option does not have alignment requirements as such. However, since this option must be the last mobility option, an implicit alignment requirement is 8n + 2. The format of this option is as follows:
Binding Authorization Dataオプションには、そういうものの整列要求がありません。 しかしながら、このオプションが最後の移動性オプションであるに違いないので、暗黙の整列要求は8n+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 = 5 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =5をタイプしてください。| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | 固有識別文字| + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Authorization Data option is valid in the Binding Update and Binding Acknowledgement.
Binding Authorization DataオプションはBinding UpdateとBinding Acknowledgementで有効です。
The Option Length field contains the length of the authenticator in octets.
Option Length分野は八重奏における、固有識別文字の長さを含んでいます。
The Authenticator field contains a cryptographic value which can be used to determine that the message in question comes from the right authority. Rules for calculating this value depends on the used authorization procedure.
Authenticator分野は問題のメッセージが正しい権威から来ることを決定するのに使用できる暗号の値を含んでいます。 この値を中古の承認手順に依存すると見込むための規則。
Johnson, et al. Standard Track [Page 50] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[50ページ]のRFC3775移動性サポート
For the return routability procedure, this option can appear in the Binding Update and Binding Acknowledgements. Rules for calculating the Authenticator value are the following:
リターンroutability手順に関しては、このオプションはBinding UpdateとBinding Acknowledgementsに現れることができます。 Authenticator値について計算するための規則は以下です:
Mobility Data = care-of address | correspondent | MH Data
Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
移動性Dataが等しい、注意、-、アドレス| 通信員| MHデータ固有識別文字は1番目と等しいです。(96、HMAC_SHA1(Kbm、移動性データ))
Where | denotes concatenation. "Care-of address" is the care-of address which will be registered for the mobile node if the Binding Update succeeds, or the home address of the mobile node if this option is used in de-registration. Note also that this address might be different from the source address of the Binding Update message, if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero.
どこ| 連結を指示します。 「注意、-、アドレス、」、注意、-、このオプションが反-登録に使用されるなら、Binding Updateが成功するとどれがモバイルノードのために登録されるだろうか、そして、モバイルノードに関するホームアドレスを扱ってください。 また、このアドレスがBinding Updateメッセージのソースアドレスと異なるかもしれないことに注意してください、Alternative Care、-、Address移動性オプションが使用されているか、またはいつ、結合の寿命があるかはゼロにセットしました。
The "correspondent" is the IPv6 address of the correspondent node. Note that, if the message is sent to a destination which is itself mobile, the "correspondent" address may not be the address found in the Destination Address field of the IPv6 header; instead the home address from the type 2 Routing header should be used.
「通信員」は通信員ノードのIPv6アドレスです。 それ自体でモバイルである目的地にメッセージを送るなら「通信員」アドレスがIPv6ヘッダーのDestination Address野原で発見されるアドレスでないかもしれないことに注意してください。 代わりに、タイプ2ルート設定ヘッダーからのホームアドレスは使用されるべきです。
"MH Data" is the content of the Mobility Header, excluding the Authenticator field itself. The Authenticator value is calculated as if the Checksum field in the Mobility Header was zero. The Checksum in the transmitted packet is still calculated in the usual manner, with the calculated Authenticator being a part of the packet protected by the Checksum. Kbm is the binding management key, which is typically created using nonces provided by the correspondent node (see Section 9.4). Note that while the contents of a potential Home Address destination option are not covered in this formula, the rules for the calculation of the Kbm do take the home address in account. This ensures that the MAC will be different for different home addresses.
Authenticator分野自体を除いて、"MH Data"はMobility Headerの内容です。 Authenticator値はまるでMobility HeaderのChecksum分野がゼロであるかのように計算されます。 伝えられたパケットのChecksumはまだ常法で計算されています、Checksumによって保護されたパケットの一部である計算されたAuthenticatorで。 Kbmは拘束力がある管理キー(セクション9.4を見る)です。(そのキーは、通信員ノードによって提供された一回だけを使用することで通常作成されます)。 潜在的ホームAddress目的地オプションの内容がこの公式でカバーされていない間Kbmの計算のための規則がホームアドレスを考慮に入れることに注意してください。 これは、MACが異なったホームアドレスにおいて異なるようになるのを確実にします。
The first 96 bits from the MAC result are used as the Authenticator field.
MAC結果から最初の96ビットはAuthenticator分野として使用されます。
6.3. Home Address Option
6.3. ホームアドレスオプション
The Home Address option is carried by the Destination Option extension header (Next Header value = 60). It is used in a packet sent by a mobile node while away from home, to inform the recipient of the mobile node's home address.
ホームAddressオプションはDestination Option拡張ヘッダー(次のHeader値の=60)によって運ばれます。 それはホームから離れていますが、モバイルノードによって送られた、モバイルノードのホームアドレスについて受取人に知らせたパケットで使用されます。
Johnson, et al. Standard Track [Page 51] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[51ページ]のRFC3775移動性サポート
The Home Address option is encoded in type-length-value (TLV) format as follows:
ホームAddressオプションは以下のタイプ長さの価値(TLV)の形式でコード化されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + ホームアドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
201 = 0xC9
201 = 0 xC9
Option Length
オプションの長さ
8-bit unsigned integer. Length of the option, in octets,
excluding the Option Type and Option Length fields. This field
MUST be set to 16.
8ビットの符号のない整数。 Option TypeとOption Length分野を除いた八重奏における、オプションの長さ。 この分野を16に設定しなければなりません。
Home Address
ホームアドレス
The home address of the mobile node sending the packet. This
address MUST be a unicast routable address.
パケットを送るモバイルノードに関するホームアドレス。 このアドレスはユニキャスト発送可能アドレスであるに違いありません。
The alignment requirement [11] for the Home Address option is 8n+6.
ホームAddressオプションのための整列要求[11]は8n+6です。
The three highest-order bits of the Option Type field are encoded to indicate specific processing of the option [11]; for the Home Address option, these three bits are set to 110. This indicates the following processing requirements:
Option Type分野の3最上位ビットがオプション[11]の特定の処理を示すためにコード化されます。 ホームAddressオプションにおいて、これらの3ビットは110に設定されます。 これは以下の処理所要を示します:
o Any IPv6 node that does not recognize the Option Type must discard
the packet, and if the packet's Destination Address was not a
multicast address, return an ICMP Parameter Problem, Code 2,
message to the packet's Source Address. The Pointer field in the
ICMP message SHOULD point at the Option Type field. Otherwise,
for multicast addresses, the ICMP message MUST NOT be sent.
o Option Typeを認識しないどんなIPv6ノードもパケットを捨てなければなりません、そして、パケットのDestination Addressがマルチキャストアドレスでなかったなら、ICMP Parameter Problemを返してください、Code2、パケットのSource Addressへのメッセージ。 Option Type分野のICMPメッセージSHOULDポイントのPointer分野。 さもなければ、マルチキャストアドレスにおいて、ICMPメッセージを送ってはいけません。
o The data within the option cannot change en route to the packet's
final destination.
o オプションの中のデータは途中で、パケットの最終的な目的地に変わらせることができません。
Johnson, et al. Standard Track [Page 52] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[52ページ]のRFC3775移動性サポート
The Home Address option MUST be placed as follows:
以下の通りホームAddressオプションを置かなければなりません:
o After the routing header, if that header is present
o そのヘッダーはルーティングヘッダーの後出席しています。
o Before the Fragment Header, if that header is present
o そのヘッダーはFragment Headerの前出席しています。
o Before the AH Header or ESP Header, if either one of those headers
are present
o AH Headerか超能力Headerの前では、ヘッダーはそれらのどちらかなら出席しています。
For each IPv6 packet header, the Home Address Option MUST NOT appear more than once. However, an encapsulated packet [15] MAY contain a separate Home Address option associated with each encapsulating IP header.
それぞれのIPv6パケットのヘッダーに関しては、ホームAddress Optionは一度より多く見えてはいけません。 しかしながら、カプセル化されたパケット[15]はそれぞれの要約のIPヘッダーに関連している別々のホームAddressオプションを含むかもしれません。
The inclusion of a Home Address destination option in a packet affects the receiving node's processing of only this single packet. No state is created or modified in the receiving node as a result of receiving a Home Address option in a packet. In particular, the presence of a Home Address option in a received packet MUST NOT alter the contents of the receiver's Binding Cache and MUST NOT cause any changes in the routing of subsequent packets sent by this receiving node.
パケットでのホームAddress目的地オプションの包含は受信ノードのこの単一のパケットだけの処理に影響します。 パケットにホームAddressオプションを受け取ることの結果、状態は、全く受信ノードで創設もされませんし、変更もされません。 容認されたパケットでのホームAddressオプションの存在は、特に、受信機のBinding Cacheのコンテンツを変更してはいけなくて、この受信ノードによって送られたその後のパケットのルーティングにおける少しの変化も引き起こしてはいけません。
6.4. Type 2 Routing Header
6.4. 2ルート設定ヘッダーをタイプしてください。
Mobile IPv6 defines a new routing header variant, the type 2 routing header, to allow the packet to be routed directly from a correspondent to the mobile node's care-of address. The mobile node's care-of address is inserted into the IPv6 Destination Address field. Once the packet arrives at the care-of address, the mobile node retrieves its home address from the routing header, and this is used as the final destination address for the packet.
モバイルIPv6がパケットが直接aから対応であっていた状態で発送されるのを許容するために新しいルーティングヘッダー異形、タイプ2ルーティングヘッダーを定義する、モバイルノードのもの、注意、-、アドレス モバイルノードのもの、注意、-、アドレスはIPv6 Destination Address分野に挿入されます。 一度、パケットが到着する、注意、-、アドレス、モバイルノードはルーティングヘッダーからのホームアドレスを検索して、これはパケットに最終的な送付先アドレスとして使用されます。
The new routing header uses a different type than defined for "regular" IPv6 source routing, enabling firewalls to apply different rules to source routed packets than to Mobile IPv6. This routing header type (type 2) is restricted to carry only one IPv6 address. All IPv6 nodes which process this routing header MUST verify that the address contained within is the node's own home address in order to prevent packets from being forwarded outside the node. The IP address contained in the routing header, since it is the mobile node's home address, MUST be a unicast routable address. Furthermore, if the scope of the home address is smaller than the scope of the care-of address, the mobile node MUST discard the packet (see Section 4.6).
新しいルーティングヘッダーが「通常」のIPv6ソースルーティングのために定義されるのと異なったタイプを使用して、ファイアウォールが異なった規則をソースに適用するのを可能にするのがモバイルIPv6よりパケットを発送しました。 このルーティングヘッダータイプ(2をタイプする)は、1つのIPv6アドレスだけを運ぶために制限されます。 このルーティングヘッダーを処理するすべてのIPv6ノードが、含まれたアドレスがパケットがノードの外で進められるのを防ぐ中のノードの自己のホームアドレスであることを確かめなければなりません。 それがモバイルノードのホームアドレスであるのでルーティングヘッダーに含まれたIPアドレスはユニキャスト発送可能アドレスであるに違いありません。 その上、ホームアドレスの範囲が範囲より小さい、注意、-、アドレス、モバイルノードはパケットを捨てなければなりません(セクション4.6を見てください)。
Johnson, et al. Standard Track [Page 53] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[53ページ]のRFC3775移動性サポート
6.4.1. Format
6.4.1. 形式
The type 2 routing header has the following format:
タイプ2ルーティングヘッダーには、以下の形式があります:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のヘッダー| Hdr Extレン=2| ルート設定タイプ=2|セグメントは=を1に残しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + ホームアドレス+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
次のヘッダー
8-bit selector. Identifies the type of header immediately
following the routing header. Uses the same values as the IPv6
Next Header field [11].
8ビットのセレクタ。 すぐにルーティングヘッダーに続いて、ヘッダーのタイプを特定します。 同じくらいがIPv6 Next Headerとして評価する用途は[11]をさばきます。
Hdr Ext Len
Hdr Extレン
2 (8-bit unsigned integer); length of the routing header in 8-
octet units, not including the first 8 octets.
2(8ビットの符号のない整数)。 最初の8つの八重奏を含まない8八重奏ユニットのルーティングヘッダーの長さ。
Routing Type
ルート設定タイプ
2 (8-bit unsigned integer).
2 (8ビットの符号のない整数。)
Segments Left
セグメントは残っています。
1 (8-bit unsigned integer).
1 (8ビットの符号のない整数。)
Reserved
予約されます。
32-bit reserved field. The value MUST be initialized to zero by
the sender, and MUST be ignored by the receiver.
32ビットは分野を予約しました。 値を送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Home Address
ホームアドレス
The Home Address of the destination Mobile Node.
目的地のモバイルNodeのホームAddress。
Johnson, et al. Standard Track [Page 54] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[54ページ]のRFC3775移動性サポート
For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments Left value describes the number of route segments remaining; i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. Segments Left MUST be 1. The ordering rules for extension headers in an IPv6 packet are described in Section 4.1 of RFC 2460 [11]. The type 2 routing header defined for Mobile IPv6 follows the same ordering as other routing headers. If both a type 0 and a type 2 routing header are present, the type 2 routing header should follow the other routing header. A packet containing such nested encapsulation should be created as if the inner (type 2) routing header was constructed first and then treated as an original packet by the outer (type 0) routing header construction process.
タイプ2ルーティングヘッダーにおいて、Hdr Extレンは2歳であるに違いありません。 Segments Left値はルートセグメントの残りの数について説明します。 すなわち、最終的な目的地に達する前にまだ訪問されるべき中間的明らかに記載されたノードの数。 セグメントLeftは1歳であるに違いありません。 注文は、拡大のためにIPv6パケットのヘッダーがRFC2460[11]のセクション4.1で説明されると裁決します。 2ルーティングヘッダーがモバイルIPv6のために定義したタイプはヘッダーを発送する他と同じ注文の後をつけます。 タイプ0とタイプ2ルーティングヘッダーの両方が出席しているなら、タイプ2ルーティングヘッダーはもう片方のルーティングヘッダーについて来るべきです。 そのような入れ子にされたカプセル化を含むパケットは、まるで内側(2をタイプする)のルーティングヘッダーが最初に組み立てられるかのように作成されて、次に、外側(0をタイプする)のルーティングヘッダー工事プロセスによってオリジナルのパケットとして扱われるべきです。
In addition, the general procedures defined by IPv6 for routing headers suggest that a received routing header MAY be automatically "reversed" to construct a routing header for use in any response packets sent by upper-layer protocols, if the received packet is authenticated [6]. This MUST NOT be done automatically for type 2 routing headers.
さらに、ルーティングヘッダーが、容認されたルーティングヘッダーがそうであると示唆するので、IPv6によって定義された基本手順は容認されたパケットが認証されるなら上側の層のプロトコルによって送られたどんな応答パケットでも使用のためにルーティングヘッダーを組み立てるために自動的に[6]を「逆にしました」。 タイプ2ルーティングヘッダーのために自動的にこれをしてはいけません。
6.5. ICMP Home Agent Address Discovery Request Message
6.5. ICMPホームエージェントアドレス発見要求メッセージ
The ICMP Home Agent Address Discovery Request message is used by a mobile node to initiate the dynamic home agent address discovery mechanism, as described in Section 11.4.1. The mobile node sends the Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its own home subnet prefix. (Note that the currently defined anycast addresses may not work with all prefix lengths other than those defined in RFC 2373 [3, 35].)
ICMPホームエージェントAddressディスカバリーRequestメッセージはモバイルノードによって使用されて、ダイナミックなホームエージェントアドレス発見メカニズムを開始します、セクション11.4.1で説明されるように。 モバイルノードはそれ自身のホームサブネット接頭語のためのモバイルIPv6ホームエージェントanycastアドレス[16]にホームエージェントAddressディスカバリーRequestメッセージを送ります。 (現在定義されたanycastアドレスがRFC2373[3、35]で定義されたもの以外のすべての接頭語の長さで働かないかもしれないことに注意してください。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
144
144
Code
コード
0
0
Johnson, et al. Standard Track [Page 55] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[55ページ]のRFC3775移動性サポート
Checksum
チェックサム
The ICMP checksum [14].
ICMPチェックサム[14]。
Identifier
識別子
An identifier to aid in matching Home Agent Address Discovery
Reply messages to this Home Agent Address Discovery Request
message.
合っているホームエージェントAddressディスカバリーReplyメッセージでこのホームエージェントAddressディスカバリーRequestメッセージに支援する識別子。
Reserved
予約されます。
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
この分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
The Source Address of the Home Agent Address Discovery Request message packet is typically one of the mobile node's current care-of addresses. At the time of performing this dynamic home agent address discovery procedure, it is likely that the mobile node is not registered with any home agent. Therefore, neither the nature of the address nor the identity of the mobile node can be established at this time. The home agent MUST then return the Home Agent Address Discovery Reply message directly to the Source Address chosen by the mobile node.
通常、ホームエージェントAddressディスカバリーRequestメッセージパケットのSource Addressが1歳である、モバイルノードの電流、注意、-、アドレス このダイナミックなホームエージェントアドレス発見手順を実行する時点で、モバイルノードはどんなホームのエージェントにも登録されそうにはありません。 したがって、このとき、アドレスの本質もモバイルノードのアイデンティティも確立できません。 そして、ホームのエージェントはホームエージェントAddressディスカバリーReplyメッセージを直接モバイルノードによって選ばれたSource Addressに返さなければなりません。
6.6. ICMP Home Agent Address Discovery Reply Message
6.6. ICMPホームエージェントアドレス発見応答メッセージ
The ICMP Home Agent Address Discovery Reply message is used by a home agent to respond to a mobile node that uses the dynamic home agent address discovery mechanism, as described in Section 10.5.
ICMPホームエージェントAddressディスカバリーReplyメッセージはダイナミックなホームエージェントアドレス発見メカニズムを使用するモバイルノードに応じるのにホームのエージェントによって使用されます、セクション10.5で説明されるように。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +… ホームエージェントアドレス… + +| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, et al. Standard Track [Page 56] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[56ページ]のRFC3775移動性サポート
Type
タイプ
145
145
Code
コード
0
0
Checksum
チェックサム
The ICMP checksum [14].
ICMPチェックサム[14]。
Identifier
識別子
The identifier from the invoking Home Agent Address Discovery
Request message.
呼び出しているホームエージェントAddressディスカバリーRequestメッセージからの識別子。
Reserved
予約されます。
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
この分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Home Agent Addresses
ホームエージェントアドレス
A list of addresses of home agents on the home link for the mobile
node. The number of addresses presented in the list is indicated
by the remaining length of the IPv6 packet carrying the Home Agent
Address Discovery Reply message.
モバイルノードのためのホームのリンクの上のホームのエージェントの住所録。 リストに提示されたアドレスの数はホームエージェントAddressディスカバリーReplyメッセージを伝えるIPv6パケットの残っている長さによって示されます。
6.7. ICMP Mobile Prefix Solicitation Message Format
6.7. ICMPのモバイル接頭語懇願メッセージ・フォーマット
The ICMP Mobile Prefix Solicitation Message is sent by a mobile node to its home agent while it is away from home. The purpose of the message is to solicit a Mobile Prefix Advertisement from the home agent, which will allow the mobile node to gather prefix information about its home network. This information can be used to configure and update home address(es) according to changes in prefix information supplied by the home agent.
それが家にいない間、モバイルノードはICMPのモバイルPrefix Solicitation Messageをホームのエージェントに送ります。 メッセージの目的はホームのエージェントからモバイルPrefix Advertisementに請求することです。(そのエージェントは、モバイルノードにホームネットワークの接頭語情報を集めさせるでしょう)。 ホームのエージェントによって提供された接頭語情報における変化に従って、ホームアドレス(es)を構成して、アップデートするのにこの情報を使用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Johnson, et al. Standard Track [Page 57] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[57ページ]のRFC3775移動性サポート
IP Fields:
IP分野:
Source Address
ソースアドレス
The mobile node's care-of address.
モバイルノードのもの、注意、-、アドレス。
Destination Address
送付先アドレス
The address of the mobile node's home agent. This home agent must
be on the link that the mobile node wishes to learn prefix
information about.
モバイルノードのホームのエージェントのアドレス。 このホームのエージェントはモバイルノードが接頭語情報を学びたがっているリンクの上にいるに違いありません。
Hop Limit
ホップ限界
Set to an initial hop limit value, similarly to any other unicast
packet sent by the mobile node.
モバイルノードによって同様にいかなる他のユニキャストパケットにも送られた初期のホップ制限値にセットしてください。
Destination Option:
目的地オプション:
A Home Address destination option MUST be included.
ホームAddress目的地オプションを含まなければなりません。
ESP header:
超能力ヘッダー:
IPsec headers MUST be supported and SHOULD be used as described in
Section 5.4.
ヘッダーを支えなければならないIPsecとSHOULD、セクション5.4で説明されるように、使用されてください。
ICMP Fields:
ICMP分野:
Type
タイプ
146
146
Code
コード
0
0
Checksum
チェックサム
The ICMP checksum [14].
ICMPチェックサム[14]。
Identifier
識別子
An identifier to aid in matching a future Mobile Prefix
Advertisement to this Mobile Prefix Solicitation.
将来のモバイルPrefix AdvertisementをこのモバイルPrefix Solicitationに合わせる際に支援する識別子。
Johnson, et al. Standard Track [Page 58] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[58ページ]のRFC3775移動性サポート
Reserved
予約されます。
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
この分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
The Mobile Prefix Solicitation messages may have options. These options MUST use the option format defined in RFC 2461 [12]. This document does not define any option types for the Mobile Prefix Solicitation message, but future documents may define new options. Home agents MUST silently ignore any options they do not recognize and continue processing the message.
モバイルPrefix Solicitationメッセージには、オプションがあるかもしれません。 これらのオプションはRFC2461[12]で定義されたオプション書式を使用しなければなりません。 このドキュメントはモバイルPrefix Solicitationメッセージのために少しのオプションタイプも定義しませんが、将来のドキュメントは新しいオプションを定義するかもしれません。 ホームのエージェントは、静かに彼らが認識しない少しのオプションも無視して、メッセージを処理し続けなければなりません。
6.8. ICMP Mobile Prefix Advertisement Message Format
6.8. ICMPのモバイル接頭語広告メッセージ・フォーマット
A home agent will send a Mobile Prefix Advertisement to a mobile node to distribute prefix information about the home link while the mobile node is traveling away from the home network. This will occur in response to a Mobile Prefix Solicitation with an Advertisement, or by an unsolicited Advertisement sent according to the rules in Section 10.6.
ホームのエージェントは、モバイルノードが遠くをホームネットワークから旅している間、ホームのリンクの接頭語情報を分配するためにモバイルPrefix Advertisementをモバイルノードに送るでしょう。 これはAdvertisementとモバイルPrefix Solicitationに対応したセクション10.6の規則に従って送られた求められていないAdvertisementで起こるでしょう。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |M|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子|M|O| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
IP分野:
Source Address
ソースアドレス
The home agent's address as the mobile node would expect to see it
(i.e., same network prefix).
モバイルノードとしてのホームのエージェントのアドレスは、それ(すなわち、同じネットワーク接頭語)を見ると予想するでしょう。
Destination Address
送付先アドレス
If this message is a response to a Mobile Prefix Solicitation,
this field contains the Source Address field from that packet.
For unsolicited messages, the mobile node's care-of address SHOULD
be used. Note that unsolicited messages can only be sent if the
mobile node is currently registered with the home agent.
このメッセージがモバイルPrefix Solicitationへの応答であるなら、この分野はそのパケットからのSource Address分野を含んでいます。 SHOULDを扱ってください。お節介なメッセージ、モバイルノードのもの、注意、-、使用されます。 モバイルノードが現在ホームのエージェントに登録される場合にだけお節介なメッセージを送ることができることに注意してください。
Johnson, et al. Standard Track [Page 59] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[59ページ]のRFC3775移動性サポート
Routing header:
ルート設定ヘッダー:
A type 2 routing header MUST be included.
タイプ2ルーティングヘッダーを含まなければなりません。
ESP header:
超能力ヘッダー:
IPsec headers MUST be supported and SHOULD be used as described in
Section 5.4.
ヘッダーを支えなければならないIPsecとSHOULD、セクション5.4で説明されるように、使用されてください。
ICMP Fields:
ICMP分野:
Type
タイプ
147
147
Code
コード
0
0
Checksum
チェックサム
The ICMP checksum [14].
ICMPチェックサム[14]。
Identifier
識別子
An identifier to aid in matching this Mobile Prefix Advertisement
to a previous Mobile Prefix Solicitation.
このモバイルPrefix Advertisementを前のモバイルPrefix Solicitationに合わせる際に支援する識別子。
M
M
1-bit Managed Address Configuration flag. When set, hosts use the
administered (stateful) protocol for address autoconfiguration in
addition to any addresses autoconfigured using stateless address
autoconfiguration. The use of this flag is described in [12, 13].
1ビットのManaged Address Configurationは弛みます。 設定されると、ホストはアドレス自動構成に状態がないアドレス自動構成を使用することで自動構成されたどんなアドレスに加えて管理された(stateful)プロトコルを使用します。 この旗の使用は[12、13]で説明されます。
O
O
1-bit Other Stateful Configuration flag. When set, hosts use the
administered (stateful) protocol for autoconfiguration of other
(non-address) information. The use of this flag is described in
[12, 13].
1ビットのOther Stateful Configurationは弛みます。 設定されると、ホストは他の(非アドレス)情報の自動構成に管理された(stateful)プロトコルを使用します。 この旗の使用は[12、13]で説明されます。
Reserved
予約されます。
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
この分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Johnson, et al. Standard Track [Page 60] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[60ページ]のRFC3775移動性サポート
The Mobile Prefix Advertisement messages may have options. These options MUST use the option format defined in RFC 2461 [12]. This document defines one option which may be carried in a Mobile Prefix Advertisement message, but future documents may define new options. Mobile nodes MUST silently ignore any options they do not recognize and continue processing the message.
モバイルPrefix Advertisementメッセージには、オプションがあるかもしれません。 これらのオプションはRFC2461[12]で定義されたオプション書式を使用しなければなりません。 このドキュメントはモバイルPrefix Advertisementメッセージで運ばれるかもしれない1つのオプションを定義しますが、将来のドキュメントは新しいオプションを定義するかもしれません。 モバイルノードは、静かに彼らが認識しない少しのオプションも無視して、メッセージを処理し続けなければなりません。
Prefix Information
接頭語情報
Each message contains one or more Prefix Information options.
Each option carries the prefix(es) that the mobile node should use
to configure its home address(es). Section 10.6 describes which
prefixes should be advertised to the mobile node.
各メッセージは1つ以上のPrefix情報オプションを含んでいます。 各オプションはモバイルノードがホームアドレス(es)を構成するのに使用するはずである接頭語(es)を運びます。 セクション10.6は、どの接頭語がモバイルノードに広告を出すべきであるかを説明します。
The Prefix Information option is defined in Section 4.6.2 of RFC
2461 [12], with modifications defined in Section 7.2 of this
specification. The home agent MUST use this modified Prefix
Information option to send home network prefixes as defined in
Section 10.6.1.
Prefix情報オプションは.2セクション4.6RFC2461[12]で定義されます、変更がこの仕様のセクション7.2で定義されている状態で。 ホームのエージェントは、セクション10.6.1で定義されるようにホームネットワーク接頭語を送るのにこの変更されたPrefix情報オプションを使用しなければなりません。
If the Advertisement is sent in response to a Mobile Prefix Solicitation, the home agent MUST copy the Identifier value from that message into the Identifier field of the Advertisement.
モバイルPrefix Solicitationに対応してAdvertisementを送るなら、ホームのエージェントはAdvertisementのIdentifier分野にIdentifier値をそのメッセージを回避しなければなりません。
The home agent MUST NOT send more than one Mobile Prefix Advertisement message per second to any mobile node.
ホームのエージェントはどんなモバイルノードへの1秒あたり1つ以上のモバイルPrefix Advertisementメッセージも送ってはいけません。
The M and O bits MUST be cleared if the Home Agent DHCPv6 support is not provided. If such support is provided then they are set in concert with the home network's administrative settings.
ホームエージェントDHCPv6サポートが提供されないなら、MとOビットをきれいにしなければなりません。 そのようなサポートを提供するなら、ホームネットワークの管理設定と協力してそれらを設定します。
7. Modifications to IPv6 Neighbor Discovery
7. IPv6隣人発見への変更
7.1. Modified Router Advertisement Message Format
7.1. 変更されたルータ通知メッセージ・フォーマット
Mobile IPv6 modifies the format of the Router Advertisement message [12] by the addition of a single flag bit to indicate that the router sending the Advertisement message is serving as a home agent on this link. The format of the Router Advertisement message is as follows:
モバイルIPv6は、Advertisementメッセージを送るルータがこのリンクの上のホームのエージェントとして勤めているのを示すように1フラグビットの追加でRouter Advertisementメッセージ[12]の形式を変更します。 Router Advertisementメッセージの形式は以下の通りです:
Johnson, et al. Standard Track [Page 61] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[61ページ]の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 野良犬ホップ限界|M|O|H| 予約されます。| ルータ生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 届いている時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retransタイマ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… +-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally specified for Neighbor Discovery [12]:
この形式は元々Neighborディスカバリー[12]に指定されたそれの上の以下の変化を表します:
Home Agent (H)
ホームのエージェント(H)
The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is also
functioning as a Mobile IPv6 home agent on this link.
Router Advertisementでは、ホームエージェント(H)ビットが、また、このRouter Advertisementを送るルータがモバイルIPv6ホームのエージェントとしてこのリンクの上に機能しているのを示すように設定されます。
Reserved
予約されます。
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit.
上のビットの追加を説明するために6ビットの分野から5ビットの分野に減少します。
7.2. Modified Prefix Information Option Format
7.2. 変更された接頭語情報オプション形式
Mobile IPv6 requires knowledge of a router's global address in building a Home Agents List as part of the dynamic home agent address discovery mechanism.
モバイルIPv6はダイナミックなホームエージェントアドレス発見メカニズムの一部としてホームエージェントListを造る際にルータのグローバルアドレスに関する知識を必要とします。
However, Neighbor Discovery [12] only advertises a router's link- local address, by requiring this address to be used as the IP Source Address of each Router Advertisement.
しかしながら、Neighborディスカバリー[12]はルータリンクのローカルアドレスの広告を出すだけです、このアドレスがそれぞれのRouter AdvertisementのIP Source Addressとして使用されるのを必要とすることによって。
Mobile IPv6 extends Neighbor Discovery to allow a router to advertise its global address, by the addition of a single flag bit in the format of a Prefix Information option for use in Router Advertisement messages. The format of the Prefix Information option is as follows:
モバイルIPv6はグローバルアドレスの広告を出すためにルータを許容するためにNeighborディスカバリーを広げています、Router Advertisementメッセージにおける使用のためのPrefix情報オプションの形式の1フラグビットの追加で。 Prefix情報オプションの形式は以下の通りです:
Johnson, et al. Standard Track [Page 62] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[62ページ]の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 接頭語の長さ|L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効な生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 都合のよい生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 接頭語+| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally specified for Neighbor Discovery [12]:
この形式は元々Neighborディスカバリー[12]に指定されたそれの上の以下の変化を表します:
Router Address (R)
ルータアドレス(R)
1-bit router address flag. When set, indicates that the Prefix
field contains a complete IP address assigned to the sending
router. The indicated prefix is the first Prefix Length bits of
the Prefix field. The router IP address has the same scope and
conforms to the same lifetime values as the advertised prefix.
This use of the Prefix field is compatible with its use in
advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits.
1ビットのルータアドレス旗。 いつが、セットして、Prefix分野が送付ルータに割り当てられた完全なIPアドレスを含むのを示しますか? 示された接頭語はPrefix分野の最初のPrefix Lengthビットです。 ルータIPアドレスは、広告を出している接頭語として同じ範囲を持って、同じ生涯値に従います。 Prefix分野のこの使用は接頭語自体の広告を出すことにおける使用と互換性があります、Prefix Advertisementが主なビットだけを使用するので。 その結果、このフラグビットの解釈はOn-リンク(L)とAutonomous Address-構成(A)フラグビット必要である処理から独立しています。
Reserved1
Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit.
上のビットの追加を説明するために6ビットの分野から5ビットの分野に減少します。
In a Router Advertisement, a home agent MUST, and all other routers MAY, include at least one Prefix Information option with the Router Address (R) bit set. Neighbor Discovery specifies that, if including all options in a Router Advertisement causes the size of the Advertisement to exceed the link MTU, multiple Advertisements can be sent, each containing a subset of the options [12]. Also, when sending unsolicited multicast Router Advertisements more frequently
Router Advertisementでは、ホームのエージェントは含めなければなりません、そして、他のすべてのルータ5月に、Router Address(R)ビットがセットしたことでの少なくとも1つのPrefix情報オプションを含めてください。 隣人ディスカバリーはそれを指定して、Router Advertisement原因にすべてのオプションを含んでいるなら、リンクMTU、複数のAdvertisementsを超えるAdvertisementのサイズを送ることができます、それぞれオプション[12]の部分集合を含んでいて。 また、より頻繁に求められていないマルチキャストRouter Advertisementsを送ります。
Johnson, et al. Standard Track [Page 63] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[63ページ]のRFC3775移動性サポート
than the limit specified in RFC 2461 [12], the sending router need not include all options in each of these Advertisements. However, in both of these cases the router SHOULD include at least one Prefix Information option with the Router Address (R) bit set in each such advertisement, if this bit is set in some advertisement sent by the router.
送付ルータは限界がRFC2461[12]で指定したよりそれぞれのこれらのAdvertisementsのすべてのオプションを含まなければならないというわけではありません。 しかしながら、ルータSHOULDが含むこれらのケースの両方では、Router Address(R)ビットによる少なくとも1つのPrefix情報オプションがそのような各広告にセットしました、このビットがルータによって送られた何らかの広告に設定されるなら。
In addition, the following requirement can assist mobile nodes in movement detection. Barring changes in the prefixes for the link, routers that send multiple Router Advertisements with the Router Address (R) bit set in some of the included Prefix Information options SHOULD provide at least one option and router address which stays the same in all of the Advertisements.
さらに、以下の要件は動き検出にモバイルノードを助けることができます。 接頭語における変化をリンクに禁じて、Router Address(R)ビットがいくらかの含まれているPrefix情報オプションSHOULDにセットした状態で複数のRouter Advertisementsを送るルータがAdvertisementsで全部で同じ状態で残っている少なくとも1つのオプションとルータアドレスを提供します。
7.3. New Advertisement Interval Option Format
7.3. 新しい広告間隔オプション形式
Mobile IPv6 defines a new Advertisement Interval option, used in Router Advertisement messages to advertise the interval at which the sending router sends unsolicited multicast Router Advertisements. The format of the Advertisement Interval option is as follows:
モバイルIPv6は新しいAdvertisement Intervalオプションを定義します、送付ルータが求められていないマルチキャストRouter Advertisementsを送る間隔の広告を出すRouter Advertisementメッセージでは、使用されています。 Advertisement Intervalオプションの形式は以下の通りです:
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
7
7
Length
長さ
8-bit unsigned integer. The length of the option (including the
type and length fields) is in units of 8 octets. The value of
this field MUST be 1.
8ビットの符号のない整数。 オプション(タイプと長さの分野を含んでいる)の長さが8つの八重奏のユニットにあります。 この分野の値は1でなければなりません。
Reserved
予約されます。
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
この分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Johnson, et al. Standard Track [Page 64] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[64ページ]のRFC3775移動性サポート
Advertisement Interval
広告間隔
32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited Router Advertisement messages sent
by this router on this network interface. Using the conceptual
router configuration variables defined by Neighbor Discovery [12],
this field MUST be equal to the value MaxRtrAdvInterval, expressed
in milliseconds.
32ビットの符号のない整数。 このネットワーク・インターフェースでこのルータによって送られた連続した求められていないRouter Advertisementメッセージの間のミリセカンドで表現される最大の時間。 Neighborディスカバリー[12]によって定義された概念的なルータ構成変数を使用して、この分野はミリセカンドで急送された値のMaxRtrAdvIntervalと等しいに違いありません。
Routers MAY include this option in their Router Advertisements. A mobile node receiving a Router Advertisement containing this option SHOULD utilize the specified Advertisement Interval for that router in its movement detection algorithm, as described in Section 11.5.1.
ルータはそれらのRouter Advertisementsのこのオプションを含むかもしれません。 このオプションSHOULDを含むRouter Advertisementを受けるモバイルノードは動き検出アルゴリズムでそのルータに指定されたAdvertisement Intervalを利用します、セクション11.5.1で説明されるように。
This option MUST be silently ignored for other Neighbor Discovery messages.
他のNeighborディスカバリーメッセージのために静かにこのオプションを無視しなければなりません。
7.4. New Home Agent Information Option Format
7.4. 新しいホームエージェント情報オプション形式
Mobile IPv6 defines a new Home Agent Information option, used in Router Advertisements sent by a home agent to advertise information specific to this router's functionality as a home agent. The format of the Home Agent Information option is as follows:
モバイルIPv6は新しいホームエージェント情報オプションを定義します、ホームのエージェントとしてこのルータの機能性に特定の情報の広告を出すためにホームのエージェントによって送られたRouter Advertisementsでは、使用されています。 ホームエージェント情報オプションの形式は以下の通りです:
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
8
8
Length
長さ
8-bit unsigned integer. The length of the option (including the
type and length fields) in units of 8 octets. The value of this
field MUST be 1.
8ビットの符号のない整数。 8つの八重奏のユニットのオプション(タイプと長さの分野を含んでいる)の長さ。 この分野の値は1でなければなりません。
Reserved
予約されます。
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
この分野は未使用です。 それを送付者がゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Johnson, et al. Standard Track [Page 65] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[65ページ]のRFC3775移動性サポート
Home Agent Preference
ホームエージェント好み
16-bit unsigned integer. The preference for the home agent
sending this Router Advertisement, for use in ordering the
addresses returned to a mobile node in the Home Agent Addresses
field of a Home Agent Address Discovery Reply message. Higher
values mean more preferable. If this option is not included in a
Router Advertisement in which the Home Agent (H) bit is set, the
preference value for this home agent MUST be considered to be 0.
Greater values indicate a more preferable home agent than lower
values.
16ビットの符号のない整数。 このRouter Advertisementを送るホームのエージェントのための好み、注文における使用のために、アドレスはホームエージェントAddressディスカバリーReplyメッセージのホームエージェントAddresses分野のモバイルノードに戻りました。 より高い値は、より望ましいことを意味します。 このオプションがホームエージェント(H)ビットが設定されるRouter Advertisementに含まれていないなら、0であるとこのホームのエージェントのための好みの値を考えなければなりません。 大値は値を下げるより望ましいホームのエージェントを示します。
The manual configuration of the Home Agent Preference value is
described in Section 8.4. In addition, the sending home agent MAY
dynamically set the Home Agent Preference value, for example
basing it on the number of mobile nodes it is currently serving or
on its remaining resources for serving additional mobile nodes;
such dynamic settings are beyond the scope of this document. Any
such dynamic setting of the Home Agent Preference, however, MUST
set the preference appropriately, relative to the default Home
Agent Preference value of 0 that may be in use by some home agents
on this link (i.e., a home agent not including a Home Agent
Information option in its Router Advertisements will be considered
to have a Home Agent Preference value of 0).
ホームエージェントPreference価値の手動の構成はセクション8.4で説明されます。 さらに、送付ホームのエージェントはダイナミックにホームエージェントPreference価値を設定するかもしれません、例えば、それをそれが現在役立っているモバイルノードの数、または、それが追加モバイルノードに役立つようにリソースのままで残っていることに基礎づけて。 そのようなダイナミックな設定はこのドキュメントの範囲を超えています。 しかしながら、ホームのエージェントPreferenceのどんなそのようなダイナミックな設定も適切に好みを設定しなければなりません、このリンクの上の何人かのホームのエージェントで使用中であるかもしれない0のデフォルトホームエージェントPreference価値に比例して(すなわち、Router Advertisementsのホームエージェント情報オプションを含まないホームのエージェントが0のホームエージェントPreference価値を持っていると考えられるでしょう)。
Home Agent Lifetime
家、エージェント生涯
16-bit unsigned integer. The lifetime associated with the home
agent in units of seconds. The default value is the same as the
Router Lifetime, as specified in the main body of the Router
Advertisement. The maximum value corresponds to 18.2 hours. A
value of 0 MUST NOT be used. The Home Agent Lifetime applies only
to this router's usefulness as a home agent; it does not apply to
information contained in other message fields or options.
16ビットの符号のない整数。 ユニットの秒でホームのエージェントに関連している生涯。 デフォルト値はRouter Advertisementの本体でRouter Lifetime、指定されるのと同じです。 最大値は18.2時間に対応しています。 0の値を使用してはいけません。 ホームのエージェントLifetimeはホームのエージェントとしてこのルータの有用性だけに適用します。 それは他のメッセージ分野かオプションに含まれた情報に適用されません。
Home agents MAY include this option in their Router Advertisements. This option MUST NOT be included in a Router Advertisement in which the Home Agent (H) bit (see Section 7.1) is not set. If this option is not included in a Router Advertisement in which the Home Agent (H) bit is set, the lifetime for this home agent MUST be considered to be the same as the Router Lifetime in the Router Advertisement. If multiple Advertisements are being sent instead of a single larger unsolicited multicast Advertisement, all of the multiple Advertisements with the Router Address (R) bit set MUST include this option with the same contents, otherwise this option MUST be omitted from all Advertisements.
ホームのエージェントは彼らのRouter Advertisementsのこのオプションを入れるかもしれません。 ホームエージェント(H)ビット(セクション7.1を見る)が設定されないRouter Advertisementにこのオプションを含んではいけません。 このオプションがホームエージェント(H)ビットが設定されるRouter Advertisementに含まれていないなら、Router AdvertisementでRouter Lifetimeと同じであるとこのホームのエージェントのための生涯を考えなければなりません。 倍数であるなら、ただ一つの、より大きい求められていないマルチキャストAdvertisementの代わりにAdvertisementsを送ります。Router Address(R)ビットがあるAdvertisementsが設定する倍数のすべてが同じコンテンツがあるこのオプションを含まなければなりません。さもなければ、すべてのAdvertisementsからこのオプションを省略しなければなりません。
Johnson, et al. Standard Track [Page 66] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[66ページ]のRFC3775移動性サポート
This option MUST be silently ignored for other Neighbor Discovery messages.
他のNeighborディスカバリーメッセージのために静かにこのオプションを無視しなければなりません。
If both the Home Agent Preference and Home Agent Lifetime are set to their default values specified above, this option SHOULD NOT be included in the Router Advertisement messages sent by this home agent.
ホームのエージェントPreferenceとホームのエージェントLifetimeの両方であるなら、Router Advertisementメッセージでこのホームのエージェントによって送られて、上でそれらのデフォルト値に指定されたセット、このオプションSHOULD NOTは含まれていますか?
7.5. Changes to Sending Router Advertisements
7.5. 送付ルータ通知への変化
The Neighbor Discovery protocol specification [12] limits routers to a minimum interval of 3 seconds between sending unsolicited multicast Router Advertisement messages from any given network interface (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
Neighborディスカバリープロトコル仕様[12]はルータをネットワーク・インターフェース(MinRtrAdvIntervalとMaxRtrAdvIntervalによって制限される)を考えて、いずれからも求められていないマルチキャストRouter Advertisementメッセージを送ることの間の3秒の最小間隔に制限します、以下のことと述べて
"Routers generate Router Advertisements frequently enough that
hosts will learn of their presence within a few minutes, but not
frequently enough to rely on an absence of advertisements to
detect router failure; a separate Neighbor Unreachability
Detection algorithm provides failure detection."
「ルータは、ホストが検出する頻繁に不在に依存でなできるくらいの数分の広告の中で彼らの存在を知るくらいの頻繁にRouter Advertisementsがルータ失敗であると生成します」。 「別々のNeighbor Unreachability Detectionアルゴリズムは失敗検出を提供します。」
This limitation, however, is not suitable to providing timely movement detection for mobile nodes. Mobile nodes detect their own movement by learning the presence of new routers as the mobile node moves into wireless transmission range of them (or physically connects to a new wired network), and by learning that previous routers are no longer reachable. Mobile nodes MUST be able to quickly detect when they move to a link served by a new router, so that they can acquire a new care-of address and send Binding Updates to register this care-of address with their home agent and to notify correspondent nodes as needed.
しかしながら、この制限はモバイルノードのためのタイムリーな動き検出を提供するのに適当ではありません。 モバイルノードが放送範囲のそれら(または、物理的に、新しい有線ネットワークに接続する)に移行するので新しいルータの存在を学んで、前のルータがもう届いていないことを学ぶことによって、モバイルノードはそれら自身の動きを検出します。 そして、モバイルノードは、それらがいつ新しいルータによって役立たれるリンクに移行するかをすぐに検出できなければなりません、新しい状態でaを取得できるように注意、-、Binding Updatesを扱って、送って、これを登録してください、注意、-、彼らのホームのエージェントとのアドレス、必要に応じて通信員ノードに通知するために。
One method which can provide for faster movement detection, is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. This method can be applied where the router is expecting to provide service to visiting mobile nodes (e.g., wireless network interfaces), or on which it is serving as a home agent to one or more mobile nodes (who may return home and need to hear its Advertisements).
より速い動き検出に備えることができて、求められていないRouter Advertisementsが送られるレートを増強することである1つのメソッド。 モバイルIPv6は、ルータが、より頻繁に求められていないマルチキャストRouter Advertisementsを送ることができるように、この限界を弛緩します。 ルータが訪問のモバイルノード(例えば、ワイヤレス・ネットワークインタフェース)に対するサービスを提供すると予想しているか、またはそれがホームのエージェントとして1つ以上のモバイルノード(家に帰って、Advertisementsを聞く必要があるかもしれない)に勤めているこのメソッドを適用できます。
Routers supporting mobility SHOULD be able to be configured with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow sending of unsolicited multicast Router Advertisements more often. The minimum allowed values are:
送付を許すより小さいMinRtrAdvInterval値で構成できて、MaxRtrAdvInterval値が求められていないマルチキャストRouter Advertisementsであったなら、よりしばしば移動性がSHOULDであるとサポートするルータ。 最小の許容値は以下の通りです。
Johnson, et al. Standard Track [Page 67] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[67ページ]のRFC3775移動性サポート
o MinRtrAdvInterval 0.03 seconds
o 0.03秒のMinRtrAdvInterval
o MaxRtrAdvInterval 0.07 seconds
o 0.07秒のMaxRtrAdvInterval
In the case where the minimum intervals and delays are used, the mean time between unsolicited multicast router advertisements is 50 ms. Use of these modified limits MUST be configurable (see also the configuration variable MinDelayBetweenRas in Section 13 which may also have to be modified accordingly). Systems where these values are available MUST NOT default to them, and SHOULD default to values specified in RFC 2461. Knowledge of the type of network interface and operating environment SHOULD be taken into account in configuring these limits for each network interface. This is important with some wireless links, where increasing the frequency of multicast beacons can cause considerable overhead. Routers SHOULD adhere to the intervals specified in RFC 2461 [12], if this overhead is likely to cause service degradation.
最小間隔と遅れが使用されている、求められていないマルチキャストルータ通知の間の平均時が50である場合では、これらの変更された限界の原稿Useは構成可能であるに違いありません(また、また、それに従って、変更されなければならないかもしれないセクション13で構成の可変MinDelayBetweenRasを見てください)。 これらの値が利用可能であるシステムはそれらをデフォルトとしてはいけませんでした、そして、値へのSHOULDデフォルトはRFC2461で指定しました。 ネットワークのタイプに関する知識を連結します、そして、環境SHOULDを操作して、各ネットワーク・インターフェースのためのこれらの限界を構成する際に考慮に入れられてください。 これはいくつかのワイヤレスのリンクで重要です。マルチキャスト標識の頻度を増強すると、そこでは、かなりのオーバーヘッドが引き起こされる場合があります。 ルータSHOULDはこのオーバーヘッドがサービス退行を引き起こしそうであるならRFC2461[12]で指定された間隔に付着します。
Additionally, the possible low values of MaxRtrAdvInterval may cause some problems with movement detection in some mobile nodes. To ensure that this is not a problem, Routers SHOULD add 20 ms to any Advertisement Intervals sent in RAs, which are below 200 ms, in order to account for scheduling granularities on both the MN and the Router.
さらに、MaxRtrAdvIntervalの可能な低値はいくつかのモバイルノードにおける動き検出に関するいくつかの問題を引き起こすかもしれません。 これが問題でないことを保証するために、Routers SHOULDは、どんなAdvertisement Intervalsへの20msも200未満msであるRAsを送ったと言い足します、ミネソタとRouterの両方で粒状の計画をするのを説明するために。
Note that multicast Router Advertisements are not always required in certain wireless networks that have limited bandwidth. Mobility detection or link changes in such networks may be done at lower layers. Router advertisements in such networks SHOULD be sent only when solicited. In such networks it SHOULD be possible to disable unsolicited multicast Router Advertisements on specific interfaces. The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set to some high values.
マルチキャストRouter Advertisementsが帯域幅を制限したあるワイヤレス・ネットワークでいつも必要であるというわけではないことに注意してください。 下層でそのようなネットワークにおける移動性検出かリンク変化をするかもしれません。 そのようなもののルータ通知はSHOULDをネットワークでつなぎます。請求されて、いつだけを送ってくださいか。 そのようなものでそれをネットワークでつなぐ、SHOULD、求められていないマルチキャストが特定のインタフェースのRouter Advertisementsであると無効にするのにおいて、可能であってください。 MinRtrAdvIntervalとMaxRtrAdvIntervalはこのような場合にはいくつかの高い値に用意ができることができます。
Home agents MUST include the Source Link-Layer Address option in all Router Advertisements they send. This simplifies the process of returning home, as discussed in Section 11.5.4.
ホームのエージェントは彼らが送るすべてのRouter AdvertisementsのSource Link-層のAddressオプションを入れなければなりません。 これはセクション11.5.4で議論するように家に帰るプロセスを簡素化します。
Note that according to RFC 2461 [12], AdvDefaultLifetime is by default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime field of Router Advertisements. Given that this field is expressed in seconds, a small MaxRtrAdvInterval value can result in a zero value for this field. To prevent this, routers SHOULD keep AdvDefaultLifetime in at least one second, even if the use of MaxRtrAdvInterval would result in a smaller value.
RFC2461[12]によると、AdvDefaultLifetimeがデフォルトでMaxRtrAdvIntervalの値に基づいていることに注意してください。 AdvDefaultLifetimeはRouter AdvertisementsのRouter Lifetime分野で使用されます。 この分野が秒に言い表されるなら、a小さいMaxRtrAdvIntervalは中のaゼロがこの分野に評価する缶の結果を評価します。 これを防ぐために、ルータSHOULDは少なくとも1秒後にAdvDefaultLifetimeを保ちます、MaxRtrAdvIntervalの使用が、より小さい値をもたらしても。
Johnson, et al. Standard Track [Page 68] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[68ページ]のRFC3775移動性サポート
8. Requirements for Types of IPv6 Nodes
8. IPv6ノードのタイプのための要件
Mobile IPv6 places some special requirements on the functions provided by different types of IPv6 nodes. This section summarizes those requirements, identifying the functionality each requirement is intended to support.
モバイルIPv6は異なったタイプのIPv6ノードによって提供された機能にいくつかの特別な要件を置きます。 サポートする各要件が意図する機能性を特定して、このセクションはそれらの要件をまとめます。
The requirements are set for the following groups of nodes:
要件はノードの以下のグループに設定されます:
o All IPv6 nodes.
o すべてのIPv6ノード。
o All IPv6 nodes with support for route optimization.
o 経路最適化のサポートがあるすべてのIPv6ノード。
o All IPv6 routers.
o すべてのIPv6ルータ。
o All Mobile IPv6 home agents.
o すべてのモバイルIPv6ホームのエージェント。
o All Mobile IPv6 mobile nodes.
o すべてのモバイルIPv6モバイルノード。
It is outside the scope of this specification to specify which of these groups are mandatory in IPv6. We only describe what is mandatory for a node that supports, for instance, route optimization. Other specifications are expected to define the extent of IPv6.
これらのグループのどれがIPv6で義務的であるかを指定するために、この仕様の範囲の外にそれはあります。 私たちは、何が例えば、サポートが最適化を発送するのがノードに義務的であるかを説明するだけです。 他の仕様がIPv6の範囲を定義すると予想されます。
8.1. All IPv6 Nodes
8.1. すべてのIPv6ノード
Any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node. There are no Mobile IPv6 specific MUST requirements for such nodes, and basic IPv6 techniques are sufficient. If a mobile node attempts to set up route optimization with a node with only basic IPv6 support, an ICMP error will signal that the node does not support such optimizations (Section 11.3.5), and communications will flow through the home agent.
どんなIPv6ノードもモバイルノード、モバイルノードへのパケットを送るか、または受信の通信員ノードがモバイルノードからのパケットであったならいつでも、そうするかもしれません。 どんなモバイルIPv6もありません。詳細はそのようなノード、および基本的なIPv6のためのテクニックが十分であるという要件がそうしなければなりません。 モバイルノードが、基本的なIPv6サポートだけがあるノードで経路最適化をセットアップするのを試みると、ICMP誤りは、ノードが、そのような最適化が(セクション11.3.5)であると支えないのを示すでしょう、そして、コミュニケーションはホームのエージェントを通して流れるでしょう。
An IPv6 node MUST NOT support the Home Address destination option, type 2 routing header, or the Mobility Header unless it fully supports the requirements listed in the next sections for either route optimization, mobile node, or home agent functionality.
IPv6ノードが、ホームAddressの目的地がオプションであることを支えてはいけない、2ルーティングヘッダーをタイプしてください。さもないと、さもなければ、完全にどちらかのために次のセクションでリストアップされた要件をサポートするというわけではないなら、Mobility Headerは最適化、モバイルノード、またはホームエージェントの機能性を発送します。
8.2. IPv6 Nodes with Support for Route Optimization
8.2. 経路最適化のサポートがあるIPv6ノード
Nodes that implement route optimization are a subset of all IPv6 nodes on the Internet. The ability of a correspondent node to participate in route optimization is essential for the efficient operation of the IPv6 Internet, for the following reasons:
経路最適化を実装するノードはインターネットのすべてのIPv6ノードの部分集合です。 IPv6インターネットの効率的な操作に、通信員ノードが経路最適化に参加する能力は不可欠です、以下の理由で:
Johnson, et al. Standard Track [Page 69] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[69ページ]のRFC3775移動性サポート
o Avoidance of congestion in the home network, and enabling the use
of lower-performance home agent equipment even for supporting
thousands of mobile nodes.
o ホームネットワークにおける、混雑の回避と、何千ものモバイルノードをサポートさえするために性能の低下ホームエージェント設備の使用を可能にすること。
o Reduced network load across the entire Internet, as mobile devices
begin to predominate.
o 減少して、モバイル機器が勝ち始めるとき、全体のインターネットの向こう側に負荷をネットワークでつないでください。
o Reduction of jitter and latency for the communications.
o コミュニケーションのためのジターと潜在の減少。
o Greater likelihood of success for QoS signaling as tunneling is
avoided and, again, fewer sources of congestion.
o トンネリングとして合図するQoSのための成功のより大きな見込みは混雑の避けられて再びより少ない源です。
o Improved robustness against network partitions, congestion, and
other problems, since fewer routing path segments are traversed.
o より少ないルーティング経路セグメントが横断されるので、ネットワークパーティション、混雑、および他の問題に対して丈夫さを改良しました。
These effects combine to enable much better performance and robustness for communications between mobile nodes and IPv6 correspondent nodes. Route optimization introduces a small amount of additional state for the peers, some additional messaging, and up to 1.5 roundtrip delays before it can be turned on. However, it is believed that the benefits far outweigh the costs in most cases. Section 11.3.1 discusses how mobile nodes may avoid route optimization for some of the remaining cases, such as very short-term communications.
これらの効果は結合して、モバイルノードとIPv6通信員ノードとのコミュニケーションのためにはるかに良い性能と丈夫さを可能にします。 それをつけることができる前に経路最適化は同輩、何らかの追加メッセージング、および最大1.5の往復の遅れのために少量の追加状態を導入します。 しかしながら、それが信じられている、それ、遠くにとして利益を得る、多くの場合、コストを重くいてください。 セクション11.3 .1 モバイルノードがどう非常に短期的なコミュニケーションなどの残っているいくつかのケースの経路最適化を避けるかもしれないかについて議論します。
The following requirements apply to all correspondent nodes that support route optimization:
以下の要件はそのサポート経路最適化をすべての通信員ノードに適用します:
o The node MUST be able to validate a Home Address option using an
existing Binding Cache entry, as described in Section 9.3.1.
o ノードは既存のBinding Cacheエントリーを使用することでホームAddressオプションを有効にすることができなければなりません、セクション9.3.1で説明されるように。
o The node MUST be able to insert a type 2 routing header into
packets to be sent to a mobile node, as described in Section
9.3.2.
o ノードはタイプ2ルーティングヘッダーをモバイルノードに送られるパケットに挿入できなければなりません、セクション9.3.2で説明されるように。
o Unless the correspondent node is also acting as a mobile node, it
MUST ignore type 2 routing headers and silently discard all
packets that it has received with such headers.
o また、通信員ノードがモバイルノードとして機能していない場合、それは、タイプ2ルーティングヘッダーを無視して、静かに、そのようなヘッダーと共に受けたすべてのパケットを捨てなければなりません。
o The node SHOULD be able to interpret ICMP messages as described in
Section 9.3.4.
o ノードSHOULD、セクション9.3で.4に説明されるようにICMPメッセージを解釈できてください。
o The node MUST be able to send Binding Error messages as described
in Section 9.3.3.
o ノードはセクション9.3.3で説明されるようにメッセージをBinding Errorに送ることができなければなりません。
o The node MUST be able to process Mobility Headers as described in
Section 9.2.
o ノードはセクション9.2で説明されるようにMobility Headersを処理できなければなりません。
Johnson, et al. Standard Track [Page 70] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[70ページ]のRFC3775移動性サポート
o The node MUST be able to participate in a return routability
procedure (Section 9.4).
o ノードはリターンroutability手順(セクション9.4)に参加できなければなりません。
o The node MUST be able to process Binding Update messages (Section
9.5).
o ノードはBinding Updateメッセージ(セクション9.5)を処理できなければなりません。
o The node MUST be able to return a Binding Acknowledgement (Section
9.5.4).
o ノードはBinding Acknowledgement(セクション9.5.4)を返すことができなければなりません。
o The node MUST be able to maintain a Binding Cache of the bindings
received in accepted Binding Updates, as described in Section 9.1
and Section 9.6.
o ノードは受け入れられたBinding Updatesで受けられた結合のBinding Cacheを維持できなければなりません、セクション9.1とセクション9.6で説明されるように。
o The node SHOULD allow route optimization to be administratively
enabled or disabled. The default SHOULD be enabled.
o ノードSHOULDは、経路最適化が行政上可能にされるか、または無効にされるのを許容します。 デフォルトSHOULD、可能にされてください。
8.3. All IPv6 Routers
8.3. すべてのIPv6ルータ
All IPv6 routers, even those not serving as a home agent for Mobile IPv6, have an effect on how well mobile nodes can communicate:
すべてのIPv6ルータ(モバイルIPv6のホームのエージェントとして勤めないものさえ)がよくモバイルのノードがどう交信できるかに影響を与えます:
o Every IPv6 router SHOULD be able to send an Advertisement Interval
option (Section 7.3) in each of its Router Advertisements [12], to
aid movement detection by mobile nodes (as in Section 11.5.1).
The use of this option in Router Advertisements SHOULD be
configurable.
o あらゆるIPv6ルータSHOULD、それぞれのRouter Advertisements[12]でAdvertisement Intervalオプション(セクション7.3)を送ることができて(セクション11.5.1のように)、モバイルノードで動き検出を支援してください。 これの使用はRouter Advertisements SHOULDを中にゆだねます。構成可能であってください。
o Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Advertisements at the faster rate described in
Section 7.5. If the router supports a faster rate, the used rate
MUST be configurable.
o あらゆるIPv6ルータSHOULD、セクション7.5で説明されたより速いレートで送付の求められていないマルチキャストがRouter Advertisementsであるとサポートすることができてください。 ルータが、より速いレートをサポートするなら、中古のレートは構成可能であるに違いありません。
o Each router SHOULD include at least one prefix with the Router
Address (R) bit set and with its full IP address in its Router
Advertisements (as described in Section 7.2).
o 各ルータSHOULDはRouter Address(R)ビットがセットしてその完全なIPアドレスがRouter Advertisementsにある少なくとも1つの接頭語を含んでいます(セクション7.2で説明されるように)。
o Routers supporting filtering packets with routing headers SHOULD
support different rules for type 0 and type 2 routing headers (see
Section 6.4) so that filtering of source routed packets (type 0)
will not necessarily limit Mobile IPv6 traffic which is delivered
via type 2 routing headers.
o ソースのそのフィルタリングがパケットを発送したなら(0をタイプしてください)、ルーティングヘッダーSHOULDサポートが異なっているフィルタリングパケットにタイプ0のための規則を支えて、2個のルーティングヘッダー(セクション6.4を見る)をタイプに支えるルータは必ずタイプ2ルーティングヘッダーを通して提供されるモバイルIPv6トラフィックを制限するというわけではないでしょう。
8.4. IPv6 Home Agents
8.4. IPv6ホームのエージェント
In order for a mobile node to operate correctly while away from home, at least one IPv6 router on the mobile node's home link must function as a home agent for the mobile node. The following additional requirements apply to all IPv6 routers that serve as a home agent:
ホームから離れている間に正しく操作するモバイルノードにおいて整然とします、モバイルノードのホームのリンクの上の少なくとも1つのIPv6ルータがモバイルノードのためのホームのエージェントとして機能しなければなりません。 以下の追加要件はホームのエージェントとしてすべてのIPv6ルータにそのサーブを適用します:
Johnson, et al. Standard Track [Page 71] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[71ページ]のRFC3775移動性サポート
o Every home agent MUST be able to maintain an entry in its Binding
Cache for each mobile node for which it is serving as the home
agent (Section 10.1 and Section 10.3.1).
o すべてのホームのエージェントがそれがホームのエージェント(セクション10.1とセクション10.3.1)として勤めているそれぞれのモバイルノードのためにBinding Cacheでエントリーを維持できなければなりません。
o Every home agent MUST be able to intercept packets (using proxy
Neighbor Discovery [12]) addressed to a mobile node for which it
is currently serving as the home agent, on that mobile node's home
link, while the mobile node is away from home (Section 10.4.1).
o すべてのホームのエージェントがパケットを妨害できなければなりません。(現在ホームのエージェントとして勤めています、そのモバイルノードのホームのリンクの上にモバイルノードが家にいないモバイルノード(セクション10.4.1)に扱われたプロキシNeighborディスカバリー[12])を使用します。
o Every home agent MUST be able to encapsulate [15] such intercepted
packets in order to tunnel them to the primary care-of address for
the mobile node indicated in its binding in the home agent's
Binding Cache (Section 10.4.2).
o すべてのホームのエージェントがそれらにトンネルを堀るためにそのようなものが妨害した[15]にパケットをカプセルに入れることができなければならない、初期医療、-、ホームのエージェントのBinding Cache(セクション10.4.2)で付く際に示されたモバイルノードのためのアドレス。
o Every home agent MUST support decapsulating [15] reverse tunneled
packets sent to it from a mobile node's home address. Every home
agent MUST also check that the source address in the tunneled
packets corresponds to the currently registered location of the
mobile node (Section 10.4.5).
o すべてのホームのエージェントがモバイルノードのホームアドレスからそれに送られた[15]の逆のトンネルを堀られたパケットをdecapsulatingにサポートしなければなりません。 また、すべてのホームのエージェントが、トンネルを堀られたパケットのソースアドレスがモバイルノード(セクション10.4.5)の現在登録された位置に一致しているのをチェックしなければなりません。
o The node MUST be able to process Mobility Headers as described in
Section 10.2.
o ノードはセクション10.2で説明されるようにMobility Headersを処理できなければなりません。
o Every home agent MUST be able to return a Binding Acknowledgement
in response to a Binding Update (Section 10.3.1).
o すべてのホームのエージェントがBinding Update(セクション10.3.1)に対応してBinding Acknowledgementを返すことができなければなりません。
o Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in
Section 10.1 and Section 10.5.1.
o すべてのホームのエージェントが、それぞれのためのそれがホームのエージェントとして勤めている別々のホームエージェントListがリンクすると主張しなければなりません、セクション10.1とセクション10.5.1で説明されるように。
o Every home agent MUST be able to accept packets addressed to the
Mobile IPv6 Home-Agents anycast address [16] for the subnet on
which it is serving as a home agent, and MUST be able to
participate in dynamic home agent address discovery (Section
10.5).
o すべてのホームのエージェントが、パケットがそれがホームのエージェントとして勤めているサブネットのためのモバイルIPv6ホームエージェントanycastアドレス[16]に扱われると受け入れることができなければならなくて、ダイナミックなホームエージェントアドレス発見(セクション10.5)に参加できなければなりません。
o Every home agent SHOULD support a configuration mechanism to allow
a system administrator to manually set the value to be sent by
this home agent in the Home Agent Preference field of the Home
Agent Information Option in Router Advertisements that it sends
(Section 7.4).
o あらゆるホームのエージェントSHOULDが、システム管理者が、値にそれが送るRouter Advertisements(セクション7.4)でホームのエージェント情報OptionのホームエージェントPreference分野のこのホームのエージェントによって送られるように手動で設定するのを許容するために構成メカニズムをサポートします。
o Every home agent SHOULD support sending ICMP Mobile Prefix
Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
Solicitations (Section 6.7). If supported, this behavior MUST be
configurable, so that home agents can be configured to avoid
sending such Prefix Advertisements according to the needs of the
network administration in the home domain.
o あらゆるホームのエージェントSHOULDが、送付ICMPがモバイルPrefix Advertisements(セクション6.8)であるとサポートします、そして、SHOULDはモバイルPrefix Solicitations(セクション6.7)にこたえます。 サポートされるなら、この振舞いは構成可能であるに違いありません、ホームドメインのネットワーク管理の必要性に応じてそのようなPrefix Advertisementsを送るのを避けるためにホームのエージェントを構成できるように。
Johnson, et al. Standard Track [Page 72] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[72ページ]のRFC3775移動性サポート
o Every home agent MUST support IPsec ESP for protection of packets
belonging to the return routability procedure (Section 10.4.6).
o すべてのホームのエージェントが、リターンroutability手順(セクション10.4.6)に属すパケットの保護のためにIPsecが超能力であるとサポートしなければなりません。
o Every home agent SHOULD support the multicast group membership
control protocols as described in Section 10.4.3. If this support
is provided, the home agent MUST be capable of using it to
determine which multicast data packets to forward via the tunnel
to the mobile node.
o あらゆるホームのエージェントSHOULDが、セクション10.4.3で説明されるようにマルチキャストグループが会員資格制御プロトコルであるとサポートします。 このサポートを提供するなら、ホームのエージェントは、モバイルノードへのトンネルを通ってどのマルチキャストデータ・パケットを進めたらよいかを決定するのにそれを使用できなければなりません。
o Home agents MAY support stateful address autoconfiguration for
mobile nodes as described in Section 10.4.4.
o ホームのエージェントは、モバイルノードのためにセクション10.4.4で説明されるようにstatefulアドレスが自動構成であるとサポートするかもしれません。
8.5. IPv6 Mobile Nodes
8.5. IPv6のモバイルノード
Finally, the following requirements apply to all IPv6 nodes capable of functioning as mobile nodes:
最終的に、以下の要件はモバイルノードとして機能できるすべてのIPv6ノードに適用されます:
o The node MUST maintain a Binding Update List (Section 11.1).
o ノードはBinding Update List(セクション11.1)を維持しなければなりません。
o The node MUST support sending packets containing a Home Address
option (Section 11.3.1), and follow the required IPsec interaction
(Section 11.3.2).
o ノードは、送付がホームAddressオプション(セクション11.3.1)を含むパケットであることを支えて、必要なIPsec相互作用(セクション11.3.2)に続かなければなりません。
o The node MUST be able to perform IPv6 encapsulation and
decapsulation [15].
o ノードはIPv6カプセル化と被膜剥離術[15]を実行できなければなりません。
o The node MUST be able to process type 2 routing header as defined
in Section 6.4 and Section 11.3.3.
o ノードはセクション6.4とセクション11.3.3で定義されるようにタイプ2ルーティングヘッダーを処理できなければなりません。
o The node MUST support receiving a Binding Error message (Section
11.3.6).
o ノードは、受信がBinding Errorメッセージ(セクション11.3.6)であることを支えなければなりません。
o The node MUST support receiving ICMP errors (Section 11.3.5).
o ノードはICMP誤り(セクション11.3.5)を受信に支えなければなりません。
o The node MUST support movement detection, care-of address
formation, and returning home (Section 11.5).
o ノードが、動きが検出であることを支えなければならない、注意、-、家(セクション11.5)で構成、および帰りを扱ってください。
o The node MUST be able to process Mobility Headers as described in
Section 11.2.
o ノードはセクション11.2で説明されるようにMobility Headersを処理できなければなりません。
o The node MUST support the return routability procedure (Section
11.6).
o ノードは、リターンroutability手順が(セクション11.6)であると支えなければなりません。
o The node MUST be able to send Binding Updates, as specified in
Section 11.7.1 and Section 11.7.2.
o ノードはセクション11.7.1とセクション11.7.2で指定されるようにBinding Updatesを送ることができなければなりません。
o The node MUST be able to receive and process Binding
Acknowledgements, as specified in Section 11.7.3.
o ノードは、Binding Acknowledgementsを受けて、セクション11.7.3で指定されるように処理できなければなりません。
Johnson, et al. Standard Track [Page 73] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[73ページ]のRFC3775移動性サポート
o The node MUST support receiving a Binding Refresh Request (Section
6.1.2), by responding with a Binding Update.
o ノードは、受信がBinding Refresh Request(セクション6.1.2)であることをBinding Updateと共に応じることによって、支えなければなりません。
o The node MUST support receiving Mobile Prefix Advertisements
(Section 11.4.3) and reconfiguring its home address based on the
prefix information contained therein.
o ノードは、受信がモバイルPrefix Advertisements(セクション11.4.3)であることを支えなければなりません、そして、ホームアドレスを再構成すると、そこに含まれた情報は接頭語に基づきました。
o The node SHOULD support use of the dynamic home agent address
discovery mechanism, as described in Section 11.4.1.
o ノードSHOULDはセクション11.4.1で説明されるようにダイナミックなホームエージェントアドレス発見メカニズムの使用をサポートします。
o The node MUST allow route optimization to be administratively
enabled or disabled. The default SHOULD be enabled.
o ノードは、経路最適化が行政上可能にされるか、または無効にされるのを許容しなければなりません。 デフォルトSHOULD、可能にされてください。
o The node MAY support the multicast address listener part of a
multicast group membership protocol as described in Section
11.3.4. If this support is provided, the mobile node MUST be able
to receive tunneled multicast packets from the home agent.
o ノードは、セクション11.3.4で説明されるようにマルチキャストアドレスがマルチキャストグループ会員資格プロトコルのリスナー部分であることを支えるかもしれません。 このサポートを提供するなら、モバイルノードはホームのエージェントからトンネルを堀られたマルチキャストパケットを受けることができなければなりません。
o The node MAY support stateful address autoconfiguration mechanisms
such as DHCPv6 [29] on the interface represented by the tunnel to
the home agent.
o ノードは、statefulアドレスがトンネルによって表されたインタフェースのDHCPv6[29]などの自動構成メカニズムであることをホームのエージェントに支えるかもしれません。
9. Correspondent Node Operation
9. 通信員ノード手術
9.1. Conceptual Data Structures
9.1. 概念的なデータ構造
IPv6 nodes with route optimization support maintain a Binding Cache of bindings for other nodes. A separate Binding Cache SHOULD be maintained by each IPv6 node for each of its unicast routable addresses. The Binding Cache MAY be implemented in any manner consistent with the external behavior described in this document, for example by being combined with the node's Destination Cache as maintained by Neighbor Discovery [12]. When sending a packet, the Binding Cache is searched before the Neighbor Discovery conceptual Destination Cache [12].
経路最適化サポートがあるIPv6ノードは他のノードのための結合のBinding Cacheを維持します。 AはBinding Cache SHOULDを切り離します。それぞれのユニキャスト発送可能アドレスのためのそれぞれのIPv6ノードによって維持されてください。 Binding Cacheは本書では説明される外部の振舞いと一致したどんな方法でも実装されるかもしれません、例えば、Neighborディスカバリー[12]によって維持されるようにノードのDestination Cacheに結合されることによって。 パケットを送るとき、Binding CacheはNeighborのディスカバリーの概念的なDestination Cache[12]の前を捜されます。
Each Binding Cache entry conceptually contains the following fields:
それぞれのBinding Cacheエントリーは概念的に以下の分野を含んでいます:
o The home address of the mobile node for which this is the Binding
Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent.
o これがBinding Cacheエントリーであるモバイルノードに関するホームアドレス。 この分野は、送られるパケットの送付先アドレスのためにBinding Cacheを捜すのにキーとして使用されます。
o The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry.
o 注意、-、このBinding Cacheエントリーでホームアドレス分野によって示されたモバイルノードのためのアドレス。
Johnson, et al. Standard Track [Page 74] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[74ページ]のRFC3775移動性サポート
o A lifetime value, indicating the remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from the
Lifetime field in the Binding Update that created or last modified
this Binding Cache entry.
o このBinding Cacheエントリーに残っている生涯を示す生涯値。 生涯値はこのBinding Cacheエントリーを作成したか、または最後に変更したBinding UpdateのLifetime分野から初期化されます。
o A flag indicating whether or not this Binding Cache entry is a
home registration entry (applicable only on nodes which support
home agent functionality).
o このBinding Cacheエントリーが本国登録エントリー(ホームがエージェントの機能性であることを支えるノードだけで適切な)であるかどうかを示す旗。
o The maximum value of the Sequence Number field received in
previous Binding Updates for this home address. The Sequence
Number field is 16 bits long. Sequence Number values MUST be
compared modulo 2**16 as explained in Section 9.5.1.
o Sequence Number分野の最大値はこのホームアドレスのために前のBinding Updatesで受信されました。 Sequence Number分野は長さ16ビットです。 系列Number値はセクション9.5.1で説明されるように比較された法2**16でなければなりません。
o Usage information for this Binding Cache entry. This is needed to
implement the cache replacement policy in use in the Binding
Cache. Recent use of a cache entry also serves as an indication
that a Binding Refresh Request should be sent when the lifetime of
this entry nears expiration.
o このBinding Cacheエントリーのための用法情報。 これが、Binding Cacheで使用中のキャッシュ交換政策を実施するのに必要です。 また、キャッシュエントリーの最近の使用はこのエントリーの寿命が満了に近づくとき、Binding Refresh Requestを送るべきであるという指示として機能します。
Binding Cache entries not marked as home registrations MAY be replaced at any time by any reasonable local cache replacement policy but SHOULD NOT be unnecessarily deleted. The Binding Cache for any one of a node's IPv6 addresses may contain at most one entry for each mobile node home address. The contents of a node's Binding Cache MUST NOT be changed in response to a Home Address option in a received packet.
いつでもホーム登録証明書をどんな合理的なローカルのキャッシュ交換方針にもかかわらず、SHOULD NOTにも取り替えるかもしれないので示されないCacheエントリーを縛って、不必要に削除されてください。 ノードのIPv6アドレスのどれかのBinding Cacheは最も1つにそれぞれのモバイルノードホームアドレスのためのエントリーを含むかもしれません。 容認されたパケットのホームAddressオプションに対応してノードのBinding Cacheのコンテンツを変えてはいけません。
9.2. Processing Mobility Headers
9.2. 処理移動性ヘッダー
Mobility Header processing MUST observe the following rules:
移動性Header処理は以下の規則を守らなければなりません:
o The checksum must be verified as per Section 6.1. Otherwise, the
node MUST silently discard the message.
o セクション6.1に従ってチェックサムについて確かめなければなりません。 さもなければ、ノードは静かにメッセージを捨てなければなりません。
o The MH Type field MUST have a known value (Section 6.1.1).
Otherwise, the node MUST discard the message and issue a Binding
Error message as described in Section 9.3.3, with Status field set
to 2 (unrecognized MH Type value).
o MH Type分野には、知られている値(セクション6.1.1)がなければなりません。 さもなければ、ノードは、セクション9.3.3で説明されるようにメッセージを捨てて、Binding Errorメッセージを発行しなければなりません、2(認識されていないMH Type値)に設定されたStatus分野で。
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
Otherwise, the node MUST discard the message and SHOULD send ICMP
Parameter Problem, Code 0, directly to the Source Address of the
packet as specified in RFC 2463 [14]. Thus no Binding Cache
information is used in sending the ICMP message. The Pointer
field in the ICMP message SHOULD point at the Payload Proto field.
o 有効搭載量プロト分野はIPPROTO_NONEであるに違いありません(59小数)。 さもなければ、ノードはメッセージを捨てなければなりません、そして、SHOULDはICMP Parameter Problemを送ります、Code0、直接RFC2463[14]の指定されるとしてのパケットのSource Addressに。 したがって、Binding Cache情報は全くICMPメッセージを送る際に使用されません。 有効搭載量プロト分野のICMPメッセージSHOULDポイントのPointer分野。
Johnson, et al. Standard Track [Page 75] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[75ページ]のRFC3775移動性サポート
o The Header Len field in the Mobility Header MUST NOT be less than
the length specified for this particular type of message in
Section 6.1. Otherwise, the node MUST discard the message and
SHOULD send ICMP Parameter Problem, Code 0, directly to the Source
Address of the packet as specified in RFC 2463 [14]. (The Binding
Cache information is again not used.) The Pointer field in the
ICMP message SHOULD point at the Header Len field.
o Mobility Headerでは、Headerレン分野は長さがセクション6.1のこの特定のタイプに関するメッセージに指定したより少ないはずがありません。 さもなければ、ノードはメッセージを捨てなければなりません、そして、SHOULDはICMP Parameter Problemを送ります、Code0、直接RFC2463[14]の指定されるとしてのパケットのSource Addressに。 (Binding Cache情報は再び使用されません。) Headerレン分野のICMPメッセージSHOULDポイントのPointer分野。
Subsequent checks depend on the particular Mobility Header.
その後のチェックは特定のMobility Headerによります。
9.3. Packet Processing
9.3. パケット処理
This section describes how the correspondent node sends packets to the mobile node, and receives packets from it.
このセクションは通信員ノードがどうモバイルノードにパケットを送って、それからパケットを受けるかを説明します。
9.3.1. Receiving Packets with Home Address Option
9.3.1. ホームアドレスオプションでパケットを受けます。
Packets containing a Home Address option MUST be dropped if the given home address is not a unicast routable address.
与えられたホームアドレスがユニキャスト発送可能アドレスでないならホームAddressオプションを含むパケットを下げなければなりません。
Mobile nodes can include a Home Address destination option in a packet if they believe the correspondent node has a Binding Cache entry for the home address of a mobile node. Packets containing a Home Address option MUST be dropped if there is no corresponding Binding Cache entry. A corresponding Binding Cache entry MUST have the same home address as appears in the Home Address destination option, and the currently registered care-of address MUST be equal to the source address of the packet. These tests MUST NOT be done for packets that contain a Home Address option and a Binding Update.
彼らが、通信員ノードにはモバイルノードに関するホームアドレスのためのBinding Cacheエントリーがあると信じているなら、モバイルノードはパケットにホームAddress目的地オプションを含むことができます。 どんな対応するBinding Cacheエントリーもなければ、ホームAddressオプションを含むパケットを下げなければなりません。 そして、Binding Cacheエントリーには同じホームアドレスがなければならない対応がホームAddress目的地オプションに現れる、現在登録されている、注意、-、アドレス、パケットのソースアドレスと等しくいなければならなくなってください。 ホームAddressオプションとBinding Updateを含むパケットのためにこれらのテストをしてはいけません。
If the packet is dropped due the above tests, the correspondent node MUST send the Binding Error message as described in Section 9.3.3. The Status field in this message should be set to 1 (unknown binding for Home Address destination option).
パケットが上記がテストする下げられた支払われるべきものであるなら、通信員ノードはセクション9.3.3で説明されるようにBinding Errorメッセージを送らなければなりません。 このメッセージのStatus分野は1(ホームAddress目的地オプションのための未知の結合)に設定されるべきです。
The correspondent node MUST process the option in a manner consistent with exchanging the Home Address field from the Home Address option into the IPv6 header and replacing the original value of the Source Address field there. After all IPv6 options have been processed, it MUST be possible for upper layers to process the packet without the knowledge that it came originally from a care-of address or that a Home Address option was used.
通信員ノードはホームAddressオプションからホームAddress野原をIPv6ヘッダーと交換して、Source Address分野の元の値をそこに取り替えると一致した方法でオプションを処理しなければなりません。 すべてのIPv6オプションを処理してある後に上側の層が元々aから来たという知識なしでパケットを処理するのが、可能であるに違いない、注意、-、アドレスかそのaホームAddressオプションが使用されました。
The use of IPsec Authentication Header (AH) for the Home Address option is not required, except that if the IPv6 header of a packet is covered by AH, then the authentication MUST also cover the Home Address option; this coverage is achieved automatically by the definition of the Option Type code for the Home Address option, since
IPsec Authentication Header(AH)のホームAddressオプションの使用は必要ではありません、また、パケットのIPv6ヘッダーがAHでカバーされているなら認証がホームAddressオプションをカバーしなければならないのを除いて。 この適用範囲は以来、ホームAddressオプションのためにOption Typeコードの定義で自動的に達成されます。
Johnson, et al. Standard Track [Page 76] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[76ページ]のRFC3775移動性サポート
it indicates that the data within the option cannot change en route to the packet's final destination, and thus the option is included in the AH computation. By requiring that any authentication of the IPv6 header also cover the Home Address option, the security of the Source Address field in the IPv6 header is not compromised by the presence of a Home Address option.
それは、オプションの中のデータが途中でパケットの最終的な目的地に変わらせることができないのを示します、そして、その結果、オプションはAH計算に含まれています。 また、IPv6ヘッダーのどんな認証もホームAddressオプションをカバーするのを必要とすることによって、IPv6ヘッダーのSource Address分野のセキュリティはホームAddressオプションの存在によって感染されません。
When attempting to verify AH authentication data in a packet that contains a Home Address option, the receiving node MUST calculate the AH authentication data as if the following were true: The Home Address option contains the care-of address, and the source IPv6 address field of the IPv6 header contains the home address. This conforms with the calculation specified in Section 11.3.2.
ホームAddressオプションを含むパケットでAH認証データについて確かめるのを試みるとき、まるで以下が本当であるかのように受信ノードはAH認証データについて計算しなければなりません: ホームAddressオプションが含んでいる、注意、-、アドレス、IPv6ヘッダーのソースIPv6アドレス・フィールドはホームアドレスを含んでいます。 これはセクション11.3.2で指定された計算に従います。
9.3.2. Sending Packets to a Mobile Node
9.3.2. モバイルノードにパケットを送ります。
Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD use a type 2 routing header to route the packet to this mobile node (the destination node) by way of its care-of address. However, the sending node MUST not do this in the following cases:
どんなパケットも送る前に、送付ノードSHOULDはパケットが送られる送付先アドレスのためのエントリーがないかどうかBinding Cacheを調べます。 を通して送付ノードにこのアドレスのためのBinding Cacheエントリーがあるなら、送付ノードSHOULDがこのモバイルノード(目的地ノード)にパケットを発送するのにタイプ2ルーティングヘッダーを使用する、それ、注意、-、アドレス しかしながら、送付ノードは以下の場合でこれをしてはいけません:
o When sending an IPv6 Neighbor Discovery [12] packet.
o IPv6 Neighborディスカバリー[12]パケットを送るとき。
o Where otherwise noted in Section 6.1.
o 別の方法でセクション6.1に述べられるところ。
When calculating authentication data in a packet that contains a type 2 routing header, the correspondent node MUST calculate the AH authentication data as if the following were true: The routing header contains the care-of address, the destination IPv6 address field of the IPv6 header contains the home address, and the Segments Left field is zero. The IPsec Security Policy Database lookup MUST based on the mobile node's home address.
タイプ2ルーティングヘッダーを含むパケットで認証データについて計算するとき、まるで以下が本当であるかのように通信員ノードはAH認証データについて計算しなければなりません: ルーティングヘッダーが含んでいる、注意、-、アドレス、IPv6ヘッダーの目的地IPv6アドレス・フィールドはホームアドレスを含んでいて、Segments Left分野はゼロです。 IPsec Security Policy Databaseルックアップはモバイルノードのホームアドレスに基づいてそうしなければなりません。
For instance, assuming there are no additional routing headers in this packet beyond those needed by Mobile IPv6, the correspondent node could set the fields in the packet's IPv6 header and routing header as follows:
例えば、どんな追加ルーティングヘッダーもこのパケットにモバイルIPv6によって必要とされたものを超えていないと仮定する場合、通信員ノードは以下のパケットのIPv6ヘッダーとルーティングヘッダーに分野をはめ込むかもしれません:
o The Destination Address in the packet's IPv6 header is set to the
mobile node's home address (the original destination address to
which the packet was being sent).
o パケットのIPv6ヘッダーのDestination Addressはモバイルノードのホームアドレス(パケットが送られたオリジナルの送付先アドレス)に用意ができています。
Johnson, et al. Standard Track [Page 77] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[77ページ]のRFC3775移動性サポート
o The routing header is initialized to contain a single route
segment, containing the mobile node's care-of address copied from
the Binding Cache entry. The Segments Left field is, however,
temporarily set to zero.
o ルーティングヘッダーはただ一つのルートセグメントを含むように初期化されます、モバイルノードのものを含んでいて注意、-、アドレスがBinding Cacheエントリーからコピーされました。 しかしながら、Segments Left分野は一時ゼロに設定されます。
The IP layer will insert the routing header before performing any necessary IPsec processing. Once all IPsec processing has been performed, the node swaps the IPv6 destination field with the Home Address field in the routing header, sets the Segments Left field to one, and sends the packet. This ensures the AH calculation is done on the packet in the form it will have on the receiver after advancing the routing header.
どんな必要なIPsec処理も実行する前に、IP層はルーティングヘッダーを挿入するでしょう。 すべてのIPsec処理がいったん実行されると、ノードは、ホームAddress分野がルーティングヘッダーにある状態でIPv6あて先フィールドを交換して、Segments Left分野を1つに設定して、パケットを送ります。 これは、ルーティングヘッダーを進めた後にそれが受信機の上に持っているフォームでパケットでAH計算をするのを確実にします。
Following the definition of a type 2 routing header in Section 6.4, this packet will be routed to the mobile node's care-of address, where it will be delivered to the mobile node (the mobile node has associated the care-of address with its network interface).
セクション6.4とのタイプ2ルーティングヘッダーの定義に続いて、このパケットに掘られる、モバイルノードのもの、注意、-、アドレス、それがモバイルノードに提供される、(モバイルノードが交際した、注意、-、ネットワーク・インターフェースがあるアドレス)
Note that following the above conceptual model in an implementation creates some additional requirements for path MTU discovery since the layer that decides the packet size (e.g., TCP and applications using UDP) needs to be aware of the size of the headers added by the IP layer on the sending node.
実装で上の概念モデルに従うとパケットサイズ(例えば、TCPとUDPを使用するアプリケーション)について決める層が、IP層で送付ノードを加えられたヘッダーのサイズを意識している必要があるので経路MTU探索のためのいくつかの追加要件が作成されることに注意してください。
If, instead, the sending node has no Binding Cache entry for the destination address to which the packet is being sent, the sending node simply sends the packet normally, with no routing header. If the destination node is not a mobile node (or is a mobile node that is currently at home), the packet will be delivered directly to this node and processed normally by it. If, however, the destination node is a mobile node that is currently away from home, the packet will be intercepted by the mobile node's home agent and tunneled to the mobile node's current primary care-of address.
送付ノードにパケットが送られる送付先アドレスのためのBinding Cacheエントリーが全く代わりにないなら、送付ノードは単に通常パケットを送ります、ルーティングヘッダーなしで。 目的地ノードが可動のノード(または、現在、家にある可動のノードである)でないなら、パケットは、直接このノードに届けられて、通常、それによって処理されるでしょう。 しかしながら、目的地ノードが現在遠くで家から来ている可動のノードであるなら、パケットに可動のノードの家のエージェントによって妨害されて、トンネルを堀られる、可動のノードの電流、初期医療、-、アドレス
9.3.3. Sending Binding Error Messages
9.3.3. 送付の拘束力があるエラーメッセージ
Section 9.2 and Section 9.3.1 describe error conditions that lead to a need to send a Binding Error message.
セクション9.2とセクション9.3.1はBinding Errorメッセージを送る必要性につながるエラー条件について説明します。
A Binding Error message is sent directly to the address that appeared in the IPv6 Source Address field of the offending packet. If the Source Address field does not contain a unicast address, the Binding Error message MUST NOT be sent.
直接怒っているパケットのIPv6 Source Address分野に現れたアドレスにBinding Errorメッセージを送ります。 Source Address分野がユニキャストアドレスを含んでいないなら、Binding Errorメッセージを送ってはいけません。
The Home Address field in the Binding Error message MUST be copied from the Home Address field in the Home Address destination option of the offending packet, or set to the unspecified address if no such option appeared in the packet.
何かそのようなオプションがパケットに現れなかったなら、Binding ErrorメッセージのホームAddress分野を怒っているパケットのホームAddress目的地オプションにおけるホームAddress分野からコピーされなければならないか、または不特定のアドレスに設定しなければなりません。
Johnson, et al. Standard Track [Page 78] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[78ページ]のRFC3775移動性サポート
Note that the IPv6 Source Address and Home Address field values discussed above are the values from the wire, i.e., before any modifications possibly performed as specified in Section 9.3.1.
上で議論したIPv6 Source AddressとホームAddress分野値がワイヤからの値であることに注意してください、すなわち、どんな変更もことによるとセクション9.3.1で指定されるように働く前に。
Binding Error messages SHOULD be subject to rate limiting in the same manner as is done for ICMPv6 messages [14].
ErrorメッセージSHOULDを縛って、ICMPv6メッセージ[14]のために行われる同じ方法がレート制限を受けることがあってください。
9.3.4. Receiving ICMP Error Messages
9.3.4. ICMPエラーメッセージを受け取ります。
When the correspondent node has a Binding Cache entry for a mobile node, all traffic destined to the mobile node goes directly to the current care-of address of the mobile node using a routing header. Any ICMP error message caused by packets on their way to the care-of address will be returned in the normal manner to the correspondent node.
通信員ノードに可動のノードのためのBinding Cacheエントリーがあるとき、可動のノードに運命づけられたすべての交通が直接電流に行く、注意、-、ルーティングヘッダーを使用する可動のノードのアドレス。 どんなICMPエラーメッセージも途中でパケットで引き起こした、注意、-、正常な方法で通信員ノードにアドレスを返すでしょう。
On the other hand, if the correspondent node has no Binding Cache entry for the mobile node, the packet will be routed through the mobile node's home link. Any ICMP error message caused by the packet on its way to the mobile node while in the tunnel, will be transmitted to the mobile node's home agent. By the definition of IPv6 encapsulation [15], the home agent MUST relay certain ICMP error messages back to the original sender of the packet, which in this case is the correspondent node.
他方では、通信員ノードに可動のノードのためのBinding Cacheエントリーが全くないと、パケットは可動のノードの家のリンクを通して発送されるでしょう。 トンネルにある間に可動のノードへの途中でパケットによって引き起こされたどんなICMPエラーメッセージ、可動のノードの家のエージェントに伝えられるでしょう。 IPv6カプセル化[15]の定義で、家のエージェントはあるICMPエラーメッセージをパケットの元の送り主にリレーして戻さなければなりません。(この場合、パケットは通信員ノードです)。
Thus, in all cases, any meaningful ICMP error messages caused by packets from a correspondent node to a mobile node will be returned to the correspondent node. If the correspondent node receives persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. Note that if the mobile node continues to send packets with the Home Address destination option to this correspondent node, they will be dropped due to the lack of a binding. For this reason it is important that only persistent ICMP messages lead to the deletion of the Binding Cache entry.
したがって、すべての場合では、パケットによって通信員ノードから可動のノードまで引き起こされたどんな重要なICMPエラーメッセージも通信員ノードに返すでしょう。 パケットを送った後に通信員ノードがしつこいICMP Destination Unreachableメッセージを受け取るなら、通信員ノードSHOULDはこのBinding Cacheエントリーを削除します。 可動のノードが、ホームAddress目的地オプションと共にこの通信員ノードにパケットを送り続けていると、彼らが結合の不足のため落とされることに注意してください。 この理由で、しつこいICMPメッセージだけがBinding Cacheエントリーの削除につながるのは、重要です。
9.4. Return Routability Procedure
9.4. リターンRoutability手順
This subsection specifies actions taken by a correspondent node during the return routability procedure.
この小区分はリターンroutability手順の間に通信員ノードによって取られた行動を指定します。
Johnson, et al. Standard Track [Page 79] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[79ページ]のRFC3775移動性サポート
9.4.1. Receiving Home Test Init Messages
9.4.1. ホームテストイニットメッセージを受け取ります。
Upon receiving a Home Test Init message, the correspondent node verifies the following:
ホームTest Initメッセージを受け取ると、通信員ノードは以下について確かめます:
o The packet MUST NOT include a Home Address destination option.
o パケットはホームAddress目的地オプションを含んではいけません。
Any packet carrying a Home Test Init message which fails to satisfy all of these tests MUST be silently ignored.
静かにこれらのテストのすべてを満たさないホームTest Initメッセージを伝えるどんなパケットも無視しなければなりません。
Otherwise, in preparation for sending the corresponding Home Test Message, the correspondent node checks that it has the necessary material to engage in a return routability procedure, as specified in Section 5.2. The correspondent node MUST have a secret Kcn and a nonce. If it does not have this material yet, it MUST produce it before continuing with the return routability procedure.
さもなければ、対応するホームTest Messageを送ることに備えて通信員ノードは、リターンroutability手順に従事するためにそれには必要な材料があるのをチェックします、セクション5.2で指定されるように。 通信員ノードには、秘密のKcnと一回だけがなければなりません。 この材料がまだないなら、リターンroutability手順を続行する前に、それはそれを生産しなければなりません。
Section 9.4.3 specifies further processing.
セクション9.4 .3 さらなる処理を指定します。
9.4.2. Receiving Care-of Test Init Messages
9.4.2. 受信、注意、-、イニットメッセージをテストしてください。
Upon receiving a Care-of Test Init message, the correspondent node verifies the following:
aを受ける、Care、-、Test Initメッセージ、通信員ノードは以下について確かめます:
o The packet MUST NOT include a Home Address destination option.
o パケットはホームAddress目的地オプションを含んではいけません。
Any packet carrying a Care-of Test Init message which fails to satisfy all of these tests MUST be silently ignored.
aを運ぶどんなパケット、もCare、-、静かにこれらのテストのすべてを満たさないTest Initメッセージを無視しなければなりません。
Otherwise, in preparation for sending the corresponding Care-of Test Message, the correspondent node checks that it has the necessary material to engage in a return routability procedure in the manner described in Section 9.4.1.
対応を送ることに備えてそうでない、Care、-、Test Message、通信員ノードはセクション9.4で.1に説明された方法でリターンroutability手順に従事するためにそれには必要な材料があるのをチェックします。
Section 9.4.4 specifies further processing.
セクション9.4 .4 さらなる処理を指定します。
9.4.3. Sending Home Test Messages
9.4.3. 送付ホームテストメッセージ
The correspondent node creates a home keygen token and uses the current nonce index as the Home Nonce Index. It then creates a Home Test message (Section 6.1.5) and sends it to the mobile node at the latter's home address.
通信員ノードは、家のkeygen象徴を作成して、ホームNonce Indexとして現在の一回だけのインデックスを使用します。 それは、次に、ホームTestメッセージ(セクション6.1.5)を作成して、後者のホームアドレスにおける可動のノードにそれを送ります。
Johnson, et al. Standard Track [Page 80] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[80ページ]のRFC3775移動性サポート
9.4.4. Sending Care-of Test Messages
9.4.4. 発信、注意、-、メッセージをテストしてください。
The correspondent node creates a care-of keygen token and uses the current nonce index as the Care-of Nonce Index. It then creates a Care-of Test message (Section 6.1.6) and sends it to the mobile node at the latter's care-of address.
通信員ノードがaを作成する、注意、-、象徴をkeygenして、現在の一回だけのインデックスを使用する、Care、-、Nonce Index。 次に、それがaを作成する、Care、-、Testが可動のノードにそれを通信して(セクション6.1.6)、送る、後者のもの、注意、-、アドレス
9.5. Processing Bindings
9.5. 処理結合
This section explains how the correspondent node processes messages related to bindings. These messages are:
このセクションは通信員ノードがどう結合に関連するメッセージを処理するかを説明します。 これらのメッセージは以下の通りです。
o Binding Update
o 拘束力があるアップデート
o Binding Refresh Request
o 付いて、要求をリフレッシュしてください。
o Binding Acknowledgement
o 拘束力がある承認
o Binding Error
o 拘束力がある誤り
9.5.1. Receiving Binding Updates
9.5.1. 拘束力があるアップデートを受けます。
Before accepting a Binding Update, the receiving node MUST validate the Binding Update according to the following tests:
Binding Updateを受け入れる前に、以下のテストに従って、受信ノードはBinding Updateを有効にしなければなりません:
o The packet MUST contain a unicast routable home address, either in
the Home Address option or in the Source Address, if the Home
Address option is not present.
o パケットはホームAddressオプションかSource Addressにユニキャスト発送可能ホームアドレスを含まなければなりません、ホームAddressオプションが存在していないなら。
o The Sequence Number field in the Binding Update is greater than
the Sequence Number received in the previous valid Binding Update
for this home address, if any.
o Binding UpdateのSequence Number分野はSequence Numberがこのホームアドレスのために前の有効なBinding Updateで受信したよりもしあれば大きいです。
If the receiving node has no Binding Cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this mobile node.
受信ノードに示されたホームアドレスのためのBinding Cacheエントリーが全くないなら、それは容認されたBinding Updateでこの可動のノードからどんなSequence Number値も受け入れなければなりません。
This Sequence Number comparison MUST be performed modulo 2**16, i.e., the number is a free running counter represented modulo 65536. A Sequence Number in a received Binding Update is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32768 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32783 through 65535, would be considered less than or equal.
このSequence Number比較が実行された法2**16であるに違いない、すなわち、数は自由な走行カウンタが法65536を表したということです。 値が最後の容認された数と前の32768の値の範囲にあるなら、容認されたBinding UpdateのSequence Numberは最後の容認されたより数であると考えられます、包括的です。 例えば0〜15、および32783〜65535の一連番号がある当時のメッセージは最後の容認された一連番号が15であったなら以下か等しいと考えられるでしょう。
Johnson, et al. Standard Track [Page 81] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[81ページ]のRFC3775移動性サポート
When the Home Registration (H) bit is not set, the following are also required:
また、ホームRegistration(H)ビットが設定されないとき、以下が必要です:
o A Nonce Indices mobility option MUST be present, and the Home and
Care-of Nonce Index values in this option MUST be recent enough to
be recognized by the correspondent node. (Care-of Nonce Index
values are not inspected for requests to delete a binding.)
o そして、Nonce Indices移動性オプションがプレゼントと、ホームであるに違いない、Care、-、このオプションにおけるNonce Index値は対応であっているノードによって認識されるほど最近でなければなりません。 (注意、-、Nonce Index値が結合を削除するという要求がないかどうか点検されない、)
o The correspondent node MUST re-generate the home keygen token and
the care-of keygen token from the information contained in the
packet. It then generates the binding management key Kbm and uses
it to verify the authenticator field in the Binding Update as
specified in Section 6.1.7.
o そして、通信員ノードが家のkeygen象徴を作り直さなければならない、注意、-、パケットに含まれた情報からのkeygen象徴。 それは、次に、拘束力がある管理の主要なKbmを発生させて、セクション6.1.7における指定されるとしてのBinding Updateの固有識別文字分野について確かめるのにそれを使用します。
o The Binding Authorization Data mobility option MUST be present,
and its contents MUST satisfy rules presented in Section 5.2.6.
Note that a care-of address different from the Source Address MAY
have been specified by including an Alternate Care-of Address
mobility option in the Binding Update. When such a message is
received and the return routability procedure is used as an
authorization method, the correspondent node MUST verify the
authenticator by using the address within the Alternate Care-of
Address in the calculations.
o Binding Authorization Data移動性オプションは存在していなければなりません、そして、コンテンツはセクション5.2.6で提示された規則を満たさなければなりません。 それに注意してください、注意、-、アドレス、包含して、5月が指定されたSource Addressと異なる、Alternate Care、-、Binding UpdateのAddress移動性オプション。 いつそのようなメッセージが受信されていて、リターンroutability手順が認可方法として用いられて、通信員ノードがアドレスを使用することによって固有識別文字について確かめなければならないか、Alternate Care、-、計算におけるAddress。
o The Binding Authorization Data mobility option MUST be the last
option and MUST NOT have trailing padding.
o Binding Authorization Data移動性オプションは、最後のオプションでなければならなく、引きずっている詰め物を持ってはいけません。
If the Home Registration (H) bit is set, the Nonce Indices mobility option MUST NOT be present.
ホームRegistration(H)ビットが設定されるなら、Nonce Indices移動性オプションは存在しているはずがありません。
If the mobile node sends a sequence number which is not greater than the sequence number from the last valid Binding Update for this home address, then the receiving node MUST send back a Binding Acknowledgement with status code 135, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement.
可動のノードがこのホームアドレスのために最後の有効なBinding Updateから一連番号ほど大きくない一連番号を送るなら、受信ノードはBinding AcknowledgementのSequence Number分野でステータスコード135、および最後に受け入れられた一連番号でBinding Acknowledgementを返送しなければなりません。
If a binding already exists for the given home address and the home registration flag has a different value than the Home Registration (H) bit in the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 139 (registration type change disallowed). The home registration flag stored in the Binding Cache entry MUST NOT be changed.
結合が与えられたホームアドレスのために既に存在していて、本国登録旗に異価がBinding UpdateのホームRegistration(H)ビットよりあるなら、受信ノードはステータスコード139(禁じられた登録タイプ変化)でBinding Acknowledgementを返送しなければなりません。 Binding Cacheエントリーに収納された本国登録旗を変えてはいけません。
If the receiving node no longer recognizes the Home Nonce Index value, Care-of Nonce Index value, or both values from the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 136, 137, or 138, respectively.
受信ノードがもうホームNonce Index価値を認識しないならCare、-、Nonce Index値、またはBinding Updateからの値の両方、そして、受信ノードはステータスコード136、137、または138でそれぞれBinding Acknowledgementを返送しなければなりません。
Johnson, et al. Standard Track [Page 82] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[82ページ]のRFC3775移動性サポート
Packets carrying Binding Updates that fail to satisfy all of these tests for any reason other than insufficiency of the Sequence Number, registration type change, or expired nonce index values, MUST be silently discarded.
静かにSequence Numberの不十分以外のどんな理由のためのこれらのテストのすべても満たさないBinding Updatesを運ぶパケット(登録タイプ変化、または満期の一回だけのインデックス値)を、捨てなければなりません。
If the Binding Update is valid according to the tests above, then the Binding Update is processed further as follows:
上のテストに従ってBinding Updateが有効であるなら、Binding Updateは以下の通りさらに処理されます:
o The Sequence Number value received from a mobile node in a Binding
Update is stored by the receiving node in its Binding Cache entry
for the given home address.
o Binding Updateの可動のノードからのSequence Number対価領収は与えられたホームアドレスのためのBinding Cacheエントリーに受信ノードによって格納されます。
o If the Lifetime specified in the Binding Update is nonzero and the
specified care-of address is not equal to the home address for the
binding, then this is a request to cache a binding for the home
address. If the Home Registration (H) bit is set in the Binding
Update, the Binding Update is processed according to the procedure
specified in Section 10.3.1; otherwise, it is processed according
to the procedure specified in Section 9.5.2.
o Binding Updateで指定されたLifetimeが非零と指定であった、注意、-、アドレスが結合のためのホームアドレスと等しくない、そして、これはホームアドレスのための結合をキャッシュするという要求です。 ホームRegistration(H)ビットがBinding Updateに設定されるなら、セクション10.3.1で指定された手順によると、Binding Updateは処理されます。 さもなければ、セクション9.5.2で指定された手順によると、それは処理されます。
o If the Lifetime specified in the Binding Update is zero or the
specified care-of address matches the home address for the
binding, then this is a request to delete the cached binding for
the home address. In this case, the Binding Update MUST include a
valid home nonce index, and the care-of nonce index MUST be
ignored by the correspondent node. The generation of the binding
management key depends then exclusively on the home keygen token
(Section 5.2.5). If the Home Registration (H) bit is set in the
Binding Update, the Binding Update is processed according to the
procedure specified in Section 10.3.2; otherwise, it is processed
according to the procedure specified in Section 9.5.3.
o Binding Updateで指定されたLifetimeがゼロか指定であった、注意、-、アドレスは結合のためのホームアドレスに合って、そして、これはホームアドレスのためのキャッシュされた結合を削除するという要求です。 そして、この場合Binding Updateが有効な家の一回だけインデックスを含まなければならない、注意、-、通信員ノードで一回だけのインデックスを無視しなければなりません。 拘束力がある管理キーの世代はその時、排他的に家のkeygen象徴(セクション5.2.5)に依存します。 ホームRegistration(H)ビットがBinding Updateに設定されるなら、セクション10.3.2で指定された手順によると、Binding Updateは処理されます。 さもなければ、セクション9.5.3で指定された手順によると、それは処理されます。
The specified care-of address MUST be determined as follows:
指定、注意、-、アドレスは以下の通り決定していなければなりません:
o If the Alternate Care-of Address option is present, the care-of
address is the address in that option.
o Alternate Care、-、Addressオプションが現在、注意、-、アドレス、中のアドレスはそのオプションですか?
o Otherwise, the care-of address is the Source Address field in the
packet's IPv6 header.
o そうでなければ、注意、-、アドレスはパケットのIPv6ヘッダーのSource Address分野です。
The home address for the binding MUST be determined as follows:
結合のためのホームアドレスは以下の通り決定していなければなりません:
o If the Home Address destination option is present, the home
address is the address in that option.
o ホームAddress目的地オプションが存在しているなら、ホームアドレスはそのオプションでアドレスです。
o Otherwise, the home address is the Source Address field in the
packet's IPv6 header.
o さもなければ、ホームアドレスはパケットのIPv6ヘッダーのSource Address分野です。
Johnson, et al. Standard Track [Page 83] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[83ページ]のRFC3775移動性サポート
9.5.2. Requests to Cache a Binding
9.5.2. 結合をキャッシュするという要求
This section describes the processing of a valid Binding Update that requests a node to cache a binding, for which the Home Registration (H) bit is not set in the Binding Update.
このセクションはホームRegistration(H)ビットがBinding Updateに設定されない結合をキャッシュするようノードに要求する有効なBinding Updateの処理について説明します。
In this case, the receiving node SHOULD create a new entry in its Binding Cache for this home address, or update its existing Binding Cache entry for this home address, if such an entry already exists. The lifetime for the Binding Cache entry is initialized from the Lifetime field specified in the Binding Update, although this lifetime MAY be reduced by the node caching the binding; the lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update. Any Binding Cache entry MUST be deleted after the expiration of its lifetime.
この場合、受信ノードSHOULDはこのホームアドレスのためにBinding Cacheで新しいエントリーを作成するか、またはこのホームアドレスのために既存のBinding Cacheエントリーをアップデートします、そのようなエントリーが既に存在しているなら。 Binding Cacheエントリーへの寿命はBinding Updateで指定されたLifetime分野から初期化されます、この寿命が結合をキャッシュするノードによって短縮されるかもしれませんが。 Binding Cacheエントリーへの寿命はLifetime値がBinding Updateで指定したよりすばらしいはずがありません。 生涯の満了の後にどんなBinding Cacheエントリーも削除しなければなりません。
Note that if the mobile node did not request a Binding Acknowledgement, then it is not aware of the selected shorter lifetime. The mobile node may thus use route optimization and send packets with the Home Address destination option. As discussed in Section 9.3.1, such packets will be dropped if there is no binding. This situation is recoverable, but can cause temporary packet loss.
可動のノードがBinding Acknowledgementを要求しなかったなら選択されたより短い生涯を意識していないことに注意してください。 可動のノードは、その結果、経路最適化を使用して、ホームAddress目的地オプションと共にパケットを送るかもしれません。 セクション9.3.1で議論するように、縛ってはいけないと、そのようなパケットは落とされるでしょう。 この状況は、回復可能ですが、一時的なパケット損失を引き起こす場合があります。
The correspondent node MAY refuse to accept a new Binding Cache entry if it does not have sufficient resources. A new entry MAY also be refused if the correspondent node believes its resources are utilized more efficiently in some other purpose, such as serving another mobile node with higher amount of traffic. In both cases the correspondent node SHOULD return a Binding Acknowledgement with status value 130.
それに十分なリソースがないなら、通信員ノードは、新しいBinding Cacheエントリーを受け入れるのを拒否するかもしれません。 また、通信員ノードが、リソースがある他の目的で、より効率的に利用されると信じているなら、新しいエントリーは拒否されるかもしれません、別の可動のノードにより高い量の交通を供給するのなどように。 どちらの場合も、通信員ノードSHOULDは状態値130があるBinding Acknowledgementを返します。
9.5.3 Requests to Delete a Binding
9.5.3 結合を削除するという要求
This section describes the processing of a valid Binding Update that requests a node to delete a binding when the Home Registration (H) bit is not set in the Binding Update.
このセクションはホームRegistration(H)ビットがBinding Updateに設定されないとき、結合を削除するようノードに要求する有効なBinding Updateの処理について説明します。
Any existing binding for the given home address MUST be deleted. A Binding Cache entry for the home address MUST NOT be created in response to receiving the Binding Update.
与えられたホームアドレスで付くどんな存在も削除しなければなりません。 Binding Updateを受けることに対応してホームアドレスのためのBinding Cacheエントリーを作成してはいけません。
If the Binding Cache entry was created by use of return routability nonces, the correspondent node MUST ensure that the same nonces are not used again with the particular home and care-of address. If both nonces are still valid, the correspondent node has to remember the particular combination of nonce indexes, addresses, and sequence number as illegal until at least one of the nonces has become too old.
そして、Binding Cacheエントリーがリターンroutability一回だけの使用で作成されたなら、通信員ノードが、同じ一回だけが再び特定のホームと共に使用されないのを確実にしなければならない、注意、-、アドレス。 両方の一回だけがまだ有効であるなら、少なくとも一回だけの1つが古くなり過ぎたまで、通信員ノードは一回だけの同じくらいインデックス、同じくらいアドレス、および不法な同じくらい一連番号の特定の組み合わせを覚えていなければなりません。
Johnson, et al. Standard Track [Page 84] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[84ページ]のRFC3775移動性サポート
9.5.4. Sending Binding Acknowledgements
9.5.4. 送付の拘束力がある承認
A Binding Acknowledgement may be sent to indicate receipt of a Binding Update as follows:
以下のBinding Updateの領収書を示すためにBinding Acknowledgementを送るかもしれません:
o If the Binding Update was discarded as described in Section 9.2 or
Section 9.5.1, a Binding Acknowledgement MUST NOT be sent.
Otherwise the treatment depends on the following rules.
o セクション9.2かセクション9.5.1で説明されるようにBinding Updateを捨てたなら、Binding Acknowledgementを送ってはいけません。 さもなければ、処理は以下の規則によります。
o If the Acknowledge (A) bit set is set in the Binding Update, a
Binding Acknowledgement MUST be sent. Otherwise, the treatment
depends on the below rule.
o (A)ビットが設定したAcknowledgeがBinding Updateで用意ができているなら、Binding Acknowledgementを送らなければなりません。 さもなければ、処理は以下の規則によります。
o If the node rejects the Binding Update due to an expired nonce
index, sequence number being out of window (Section 9.5.1), or
insufficiency of resources (Section 9.5.2), a Binding
Acknowledgement MUST be sent. If the node accepts the Binding
Update, the Binding Acknowledgement SHOULD NOT be sent.
o ノードが満期の一回だけのインデックス、窓の外にある一連番号(セクション9.5.1)、またはリソースの不十分(セクション9.5.2)のためBinding Updateを拒絶するなら、Binding Acknowledgementを送らなければなりません。 ノードはBinding Update、Binding Acknowledgement SHOULDを受け入れます。送られません。
If the node accepts the Binding Update and creates or updates an entry for this binding, the Status field in the Binding Acknowledgement MUST be set to a value less than 128. Otherwise, the Status field MUST be set to a value greater than or equal to 128. Values for the Status field are described in Section 6.1.8 and in the IANA registry of assigned numbers [19].
ノードがこの結合のためにエントリーをBinding Updateを受け入れて、作成するか、またはアップデートするなら、Binding AcknowledgementのStatus分野を値128に設定しなければなりません。 さもなければ、値より多くの128にStatus分野を設定しなければなりません。 値はセクション6.1.8と規定番号[19]のIANA登録にStatus分野に説明されます。
If the Status field in the Binding Acknowledgement contains the value 136 (expired home nonce index), 137 (expired care-of nonce index), or 138 (expired nonces) then the message MUST NOT include the Binding Authorization Data mobility option. Otherwise, the Binding Authorization Data mobility option MUST be included, and MUST meet the specific authentication requirements for Binding Acknowledgements as defined in Section 5.2.
Binding AcknowledgementのStatus分野が値136(一回だけのインデックスを家まで吐き出します)、137を含んでいる、(満期、注意、-、一回だけのインデックス、)、138 (一回だけを吐き出します) そして、メッセージはBinding Authorization Data移動性オプションを含んではいけません。 さもなければ、Binding Authorization Data移動性オプションは、含まなければならなくて、セクション5.2で定義されるようにBinding Acknowledgementsのための特定の認証必要条件を満たさなければなりません。
If the Source Address field of the IPv6 header that carried the Binding Update does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent and the Binding Update packet MUST be silently discarded. Otherwise, the acknowledgement MUST be sent to the Source Address. Unlike the treatment of regular packets, this addressing procedure does not use information from the Binding Cache. However, a routing header is needed in some cases. If the Source Address is the home address of the mobile node, i.e., the Binding Update did not contain a Home Address destination option, then the Binding Acknowledgement MUST be sent to that address and the routing header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST be sent using a type 2 routing header which contains the mobile node's home address.
Binding Updateを運んだIPv6ヘッダーのSource Address分野がユニキャストアドレスを含んでいないなら、Binding Acknowledgementを送ってはいけません、そして、静かにBinding Updateパケットを捨てなければなりません。 さもなければ、承認をSource Addressに送らなければなりません。 レギュラーのパケットの処理と異なって、このアドレシング手順はBinding Cacheからの情報を使用しません。 しかしながら、いくつかの場合、ルーティングヘッダーが必要です。 Source Addressがモバイルノードに関するホームアドレスであるなら、すなわち、Binding UpdateはホームAddress目的地オプションを含みませんでした、そして、次に、そのアドレスにBinding Acknowledgementを送らなければなりません、そして、ルーティングヘッダーを使用してはいけません。 さもなければ、Binding Acknowledgementにモバイルノードのホームアドレスを含むタイプ2ルーティングヘッダーを使用させなければなりません。
Johnson, et al. Standard Track [Page 85] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[85ページ]のRFC3775移動性サポート
9.5.5. Sending Binding Refresh Requests
9.5.5. 結合を送って、要求をリフレッシュしてください。
If a Binding Cache entry being deleted is still in active use when sending packets to a mobile node, then the next packet sent to the mobile node will be routed normally to the mobile node's home link. Communication with the mobile node continues, but the tunneling from the home network creates additional overhead and latency in delivering packets to the mobile node.
モバイルノードにパケットを送るとき、削除されるBinding Cacheエントリーがまだ能動的使用であると、通常、モバイルノードに送られた次のパケットはモバイルノードのホームのリンクに発送されるでしょう。 モバイルノードとのコミュニケーションは続きますが、ホームネットワークからのトンネリングはモバイルノードにパケットを提供する際に追加オーバーヘッドと潜在を作成します。
If the sender knows that the Binding Cache entry is still in active use, it MAY send a Binding Refresh Request message to the mobile node in an attempt to avoid this overhead and latency due to deleting and recreating the Binding Cache entry. This message is always sent to the home address of the mobile node.
送付者が、Binding Cacheエントリーがまだ能動的使用であるのを知っているなら、それはBinding Cacheエントリーを削除して、休養させるためこのオーバーヘッドと潜在を避ける試みでBinding Refresh Requestメッセージをモバイルノードに送るかもしれません。 いつもモバイルノードに関するホームアドレスにこのメッセージを送ります。
The correspondent node MAY retransmit Binding Refresh Request messages as long as the rate limitation is applied. The correspondent node MUST stop retransmitting when it receives a Binding Update.
レート制限が適用されている限り、通信員ノードはBinding Refresh Requestメッセージを再送するかもしれません。 通信員ノードは、Binding Updateを受けるとき、再送するのを止めなければなりません。
9.6. Cache Replacement Policy
9.6. キャッシュ交換方針
Conceptually, a node maintains a separate timer for each entry in its Binding Cache. When creating or updating a Binding Cache entry in response to a received and accepted Binding Update, the node sets the timer for this entry to the specified Lifetime period. Any entry in a node's Binding Cache MUST be deleted after the expiration of the Lifetime specified in the Binding Update from which the entry was created or last updated.
概念的に、ノードはBinding Cacheの各エントリーのための別々のタイマを維持します。 受け取られていていて受け入れられたBinding Updateに対応してBinding Cacheエントリーを作成するか、またはアップデートするとき、ノードは指定されたLifetimeの期間にこのエントリーのためのタイマを設定します。 Lifetimeの満了がエントリーが作成されたか、またはアップデートされたBinding Updateで指定した後にノードのBinding Cacheのどんなエントリーも削除しなければなりません。
Each node's Binding Cache will, by necessity, have a finite size. A node MAY use any reasonable local policy for managing the space within its Binding Cache.
各ノードのBinding Cacheには、有限サイズが必要に迫られてあるでしょう。 ノードは、Binding Cacheの中でスペースを管理するのにどんな合理的なローカルの方針も使用するかもしれません。
A node MAY choose to drop any entry already in its Binding Cache in order to make space for a new entry. For example, a "least-recently used" (LRU) strategy for cache entry replacement among entries should work well, unless the size of the Binding Cache is substantially insufficient. When entries are deleted, the correspondent node MUST follow the rules in Section 5.2.8 in order to guard the return routability procedure against replay attacks.
ノードは、新しいエントリーにスペースを作るために既にBinding Cacheでどんなエントリーも下げるのを選ぶかもしれません。 例えば、エントリーの中のキャッシュエントリー交換のための「-最も最近でない、中古」の(LRU)戦略はうまくいくべきです、Binding Cacheのサイズが実質的に不十分でない場合。 エントリーが削除されるとき、通信員ノードは、反射攻撃に対してリターンroutability手順を警備するためにセクション5.2.8で約束を守らなければなりません。
If the node sends a packet to a destination for which it has dropped the entry from its Binding Cache, the packet will be routed through the mobile node's home link. The mobile node can detect this and establish a new binding if necessary.
ノードがそれがBinding Cacheからエントリーを下げた目的地にパケットを送ると、パケットはモバイルノードのホームのリンクを通して発送されるでしょう。 必要なら、モバイルノードは、これを検出して、新しい結合を確立できます。
Johnson, et al. Standard Track [Page 86] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[86ページ]のRFC3775移動性サポート
However, if the mobile node believes that the binding still exists, it may use route optimization and send packets with the Home Address destination option. This can create temporary packet loss, as discussed earlier, in the context of binding lifetime reductions performed by the correspondent node (Section 9.5.2).
しかしながら、モバイルノードが、結合がまだ存在していると信じているなら、それは、ホームAddress目的地オプションと共に経路最適化を使用して、パケットを送るかもしれません。 これは一時的なパケット損失を引き起こすことができます、以前に検討したことであるが、通信員ノード(セクション9.5.2)によって実行された拘束力がある生涯減少の文脈で。
10. Home Agent Operation
10. ホームエージェント操作
10.1. Conceptual Data Structures
10.1. 概念的なデータ構造
Each home agent MUST maintain a Binding Cache and Home Agents List.
それぞれのホームのエージェントはBinding CacheとホームエージェントListを維持しなければなりません。
The rules for maintaining a Binding Cache are the same for home agents and correspondent nodes and have already been described in Section 9.1.
Binding Cacheを維持するための規則は、ホームのエージェントと通信員ノードに同じであり、セクション9.1で既に説明されます。
The Home Agents List is maintained by each home agent, recording information about each router on the same link that is acting as a home agent. This list is used by the dynamic home agent address discovery mechanism. A router is known to be acting as a home agent, if it sends a Router Advertisement in which the Home Agent (H) bit is set. When the lifetime for a list entry (defined below) expires, that entry is removed from the Home Agents List. The Home Agents List is similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [12]. The Home Agents List MAY be implemented in any manner consistent with the external behavior described in this document.
ホームエージェントListはそれぞれのホームのエージェントによって維持されます、ホームのエージェントとして務めているのと同じリンクに各ルータの情報を記録して。 このリストはダイナミックなホームエージェントアドレス発見メカニズムによって使用されます。 ルータがホームのエージェントとして務めているのが知られています、ホームエージェント(H)ビットが設定されるRouter Advertisementを送るなら。 リストエントリー(以下では、定義される)への寿命が期限が切れるとき、ホームエージェントListからそのエントリーを取り除きます。 ホームエージェントListはNeighborディスカバリー[12]のために各ホストによって維持されたDefault Router Listの概念的なデータ構造と同様です。 ホームエージェントListは本書では説明される外部の振舞いと一致したどんな方法でも実装されるかもしれません。
Each home agent maintains a separate Home Agents List for each link on which it is serving as a home agent. A new entry is created or an existing entry is updated in response to receipt of a valid Router Advertisement in which the Home Agent (H) bit is set. Each Home Agents List entry conceptually contains the following fields:
それぞれのホームのエージェントは、それぞれのためのそれがホームのエージェントとして勤めている別々のホームエージェントListがリンクすると主張します。 新しいエントリーを作成するか、またはホームエージェント(H)ビットが設定される有効なRouter Advertisementの領収書に対応して既存のエントリーをアップデートします。 それぞれのホームエージェントListエントリーは概念的に以下の分野を含んでいます:
o The link-local IP address of a home agent on the link. This
address is learned through the Source Address of the Router
Advertisements [12] received from the router.
o リンクの上のホームのエージェントのリンクローカルアイピーアドレス。 このアドレスはルータから受け取られたRouter Advertisements[12]のSource Addressを通して学習されます。
o One or more global IP addresses for this home agent. Global
addresses are learned through Prefix Information options with the
Router Address (R) bit set and received in Router Advertisements
from this link-local address. Global addresses for the router in
a Home Agents List entry MUST be deleted once the prefix
associated with that address is no longer valid [12].
o このホームのエージェントのための1つ以上のグローバルIPアドレス。 グローバルなアドレスをRouter Address(R)ビットによるオプションが設定するPrefix情報を通して学習して、Router Advertisementsにこのリンクローカルアドレスから受け取ります。 そのアドレスに関連している接頭語がいったんもうどんな有効な[12]にもならないと、ホームエージェントListエントリーにおけるルータのためのグローバルなアドレスを削除しなければなりません。
Johnson, et al. Standard Track [Page 87] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[87ページ]のRFC3775移動性サポート
o The remaining lifetime of this Home Agents List entry. If a Home
Agent Information Option is present in a Router Advertisement
received from a home agent, the lifetime of the Home Agents List
entry representing that home agent is initialized from the Home
Agent Lifetime field in the option (if present); otherwise, the
lifetime is initialized from the Router Lifetime field in the
received Router Advertisement. If Home Agents List entry lifetime
reaches zero, the entry MUST be deleted from the Home Agents List.
o このホームエージェントListエントリーの残っている生涯。 ホームエージェント情報Optionがホームのエージェントから受け取られたRouter Advertisementに存在しているなら、そのホームのエージェントの代理をするホームエージェントListエントリーの寿命はオプションにおけるホームエージェントLifetime分野から初期化されます(存在しているなら)。 さもなければ、寿命は容認されたRouter AdvertisementのRouter Lifetime分野から初期化されます。 ホームエージェントListエントリー寿命がゼロに達するなら、ホームエージェントListからエントリーを削除しなければなりません。
o The preference for this home agent; higher values indicate a more
preferable home agent. The preference value is taken from the
Home Agent Preference field in the received Router Advertisement,
if the Router Advertisement contains a Home Agent Information
Option and is otherwise set to the default value of 0. A home
agent uses this preference in ordering the Home Agents List when
it sends an ICMP Home Agent Address Discovery message.
o このホームのエージェントのための好み。 より高い値は、より望ましいホームのエージェントを示します。 容認されたRouter AdvertisementでホームエージェントPreference分野から好みの値を取ります、Router Advertisementがホームエージェント情報Optionを含んでいて、別の方法で0のデフォルト値に用意ができているなら。 ホームのエージェントはICMPホームエージェントAddressディスカバリーメッセージをそれが発信するホームエージェントListに注文する際にこの好みを使用します。
10.2. Processing Mobility Headers
10.2. 処理移動性ヘッダー
All IPv6 home agents MUST observe the rules described in Section 9.2 when processing Mobility Headers.
すべてのIPv6ホームのエージェントがMobility Headersを処理するときセクション9.2で説明された規則を守らなければなりません。
10.3. Processing Bindings
10.3. 処理結合
10.3.1. Primary Care-of Address Registration
10.3.1. 初期医療、-、登録を扱ってください。
When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 9.5.1. Furthermore, it MUST authenticate the Binding Update as described in Section 5.1. An authorization step specific for the home agent is also needed to ensure that only the right node can control a particular home address. This is provided through the home address unequivocally identifying the security association that must be used.
ノードがBinding Updateを受けるとき、それは、それを有効にして、セクション9.5.1で説明されたステップに従って、Binding Updateのタイプを決定しなければなりません。 その上、それはセクション5.1で説明されるようにBinding Updateを認証しなければなりません。 また、ホームのエージェントにとって、特定の承認ステップが、正しいノードだけが特定のホームアドレスを制御できるのを保証するのに必要です。 明確に、使用しなければならないセキュリティ協会を特定するホームアドレスを通してこれを提供します。
This section describes the processing of a valid and authorized Binding Update when it requests the registration of the mobile node's primary care-of address.
このセクションが登録を要求するときのa有効で認可されたBinding Updateの処理について説明する、モバイルノードのもの、初期医療、-、アドレス
To begin processing the Binding Update, the home agent MUST perform the following sequence of tests:
Binding Updateを処理し始めるために、ホームのエージェントはテストの以下の系列を実行しなければなりません:
o If the node implements only correspondent node functionality, or
has not been configured to act as a home agent, then the node MUST
reject the Binding Update. The node MUST also return a Binding
Acknowledgement to the mobile node, in which the Status field is
set to 131 (home registration not supported).
o ノードが通信員ノードの機能性だけを実装するか、またはホームのエージェントとして務めるために構成されていないなら、ノードはBinding Updateを拒絶しなければなりません。 また、ノードはモバイルノードにBinding Acknowledgementを返さなければなりません。Status分野はノードに131(登録が支えなかったホーム)に設定されます。
Johnson, et al. Standard Track [Page 88] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[88ページ]のRFC3775移動性サポート
o Else, if the home address for the binding (the Home Address field
in the packet's Home Address option) is not an on-link IPv6
address with respect to the home agent's current Prefix List, then
the home agent MUST reject the Binding Update and SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status
field is set to 132 (not home subnet).
o ほかに、ホームのエージェントは結合(パケットのホームAddressオプションにおけるホームAddress分野)のためのホームアドレスがリンクに関するIPv6アドレスでないならホームのエージェントの現在のPrefix Listに関してBinding Updateを拒絶しなければなりません、そして、SHOULDはモバイルノードにBinding Acknowledgementを返します。Status分野はノードに132(ホームサブネットでない)に設定されます。
o Else, if the home agent chooses to reject the Binding Update for
any other reason (e.g., insufficient resources to serve another
mobile node as a home agent), then the home agent SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status
field is set to an appropriate value to indicate the reason for
the rejection.
o ほかに、ホームのエージェントが、いかなる他の理由(例えば、ホームのエージェントとして別のモバイルノードに勤める不十分なリソース)でもBinding Updateを拒絶するのを選ぶなら、ホームのエージェントSHOULDはモバイルノードにBinding Acknowledgementを返します。Status分野はノードに適切な値に拒絶の理由を示すように設定されます。
o A Home Address destination option MUST be present in the message.
It MUST be validated as described in Section 9.3.1 with the
following additional rule. The Binding Cache entry existence test
MUST NOT be done for IPsec packets when the Home Address option
contains an address for which the receiving node could act as a
home agent.
o ホームAddress目的地オプションはメッセージに存在していなければなりません。 以下の付則でセクション9.3.1で説明されるようにそれを有効にしなければなりません。 ホームAddressオプションが受信ノードがホームのエージェントとして務めることができたアドレスを含むとき、IPsecパケットのためにBinding Cacheエントリー存在テストをしてはいけません。
If home agent accepts the Binding Update, it MUST then create a new entry in its Binding Cache for this mobile node or update its existing Binding Cache entry, if such an entry already exists. The Home Address field as received in the Home Address option provides the home address of the mobile node.
ホームのエージェントがBinding Updateを受け入れるなら、次に、このモバイルノードのためにBinding Cacheで新しいエントリーを作成しなければならないか、または既存のBinding Cacheエントリーをアップデートしなければなりません、そのようなエントリーが既に存在しているなら。 ホームAddressオプションで受け取られるホームAddress野原はモバイルノードに関するホームアドレスを提供します。
The home agent MUST mark this Binding Cache entry as a home registration to indicate that the node is serving as a home agent for this binding. Binding Cache entries marked as a home registration MUST be excluded from the normal cache replacement policy used for the Binding Cache (Section 9.6) and MUST NOT be removed from the Binding Cache until the expiration of the Lifetime period.
ホームのエージェントは、示すノードがこの結合のためのホームのエージェントとして勤めている本国登録としてこのBinding Cacheがエントリーであるとマークしなければなりません。 通常のキャッシュ交換方針から本国登録を除かなければならないので示される拘束力があるCacheエントリーを、Binding Cache(セクション9.6)に使用して、Binding CacheからLifetimeの期間の満了まで取り除いてはいけません。
Unless this home agent already has a binding for the given home address, the home agent MUST perform Duplicate Address Detection [13] on the mobile node's home link before returning the Binding Acknowledgement. This ensures that no other node on the home link was using the mobile node's home address when the Binding Update arrived. If this Duplicate Address Detection fails for the given home address or an associated link local address, then the home agent MUST reject the complete Binding Update and MUST return a Binding Acknowledgement to the mobile node, in which the Status field is set to 134 (Duplicate Address Detection failed). When the home agent sends a successful Binding Acknowledgement to the mobile node, the home agent assures to the mobile node that its address(es) will be kept unique by the home agent for as long as the lifetime was granted for the binding.
このホームのエージェントに与えられたホームアドレスのための結合が既にない場合、Binding Acknowledgementを返す前に、ホームのエージェントはモバイルノードのホームのリンクにDuplicate Address Detection[13]を実行しなければなりません。 これは、Binding Updateが到着したとき、ホームのリンクの上の他のどんなノードもモバイルノードのホームアドレスを使用していなかったのを確実にします。 このDuplicate Address Detectionが与えられたホームアドレスか関連リンクローカルアドレスのために失敗するなら、ホームのエージェントは、完全なBinding Updateを拒絶しなければならなくて、モバイルノードにBinding Acknowledgementを返さなければなりません(写しAddress Detectionは失敗しました)。Status分野はノードに134に設定されます。 ホームのエージェントがうまくいっているBinding Acknowledgementをモバイルノードに送るとき、ホームのエージェントは、アドレス(es)が結合のために生涯を与えた限り、ホームのエージェントによってユニークに保管されることをモバイルノードに保証します。
Johnson, et al. Standard Track [Page 89] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[89ページ]のRFC3775移動性サポート
The specific addresses, which are to be tested before accepting the Binding Update and later to be defended by performing Duplicate Address Detection, depend on the setting of the Link-Local Address Compatibility (L) bit, as follows:
Binding Updateを受け入れる前と後でDuplicate Address Detectionを実行することによって防御されるためにテストされることである特定のアドレスをLink地方のAddress Compatibility(L)ビットの設定に依存します、以下の通りです:
o L=0: Defend only the given address. Do not derive a link-local
address.
o L=0: 与えられたアドレスだけを防御してください。 リンクローカルアドレスを引き出さないでください。
o L=1: Defend both the given non link-local unicast (home) address
and the derived link-local. The link-local address is derived by
replacing the subnet prefix in the mobile node's home address with
the link-local prefix.
o L=1: 当然のことの非リンクのローカルユニキャスト(ホーム)アドレスと引き出しているリンクローカルの両方を防御してください。 リンクローカルアドレスは、モバイルノードのホームアドレスのサブネット接頭語をリンクローカルの接頭語に置き換えることによって、引き出されます。
The lifetime of the Binding Cache entry depends on a number of factors:
Binding Cacheエントリーの寿命を多くの要因に依存します:
o The lifetime for the Binding Cache entry MUST NOT be greater than
the Lifetime value specified in the Binding Update.
o Binding Cacheエントリーへの寿命はLifetime値がBinding Updateで指定したよりすばらしいはずがありません。
o The lifetime for the Binding Cache entry MUST NOT be greater than
the remaining valid lifetime for the subnet prefix in the mobile
node's home address specified with the Binding Update. The
remaining valid lifetime for this prefix is determined by the home
agent based on its own Prefix List entry [12].
o Binding Cacheエントリーへの寿命はモバイルノードのホームアドレスのサブネット接頭語のための残っている有効な寿命がBinding Updateと共に指定したよりすばらしいはずがありません。 この接頭語のための残っている有効な寿命はそれ自身のPrefix Listエントリー[12]に基づくホームのエージェントによって決定されます。
The remaining preferred lifetime SHOULD NOT have any impact on the
lifetime for the binding cache entry.
残っている都合のよい生涯SHOULD NOTには、拘束力があるキャッシュエントリーへの生涯、どんな影響力もあります。
The home agent MUST remove a binding when the valid lifetime of
the prefix associated with it expires.
それに関連している接頭語の有効な寿命が期限が切れると、ホームのエージェントは結合を取り除かなければなりません。
o The home agent MAY further decrease the specified lifetime for the
binding, for example based on a local policy. The resulting
lifetime is stored by the home agent in the Binding Cache entry,
and this Binding Cache entry MUST be deleted by the home agent
after the expiration of this lifetime.
o ホームのエージェントは例えば、結合ローカルの方針に基づいて指定された生涯をさらに減少させるかもしれません。 結果として起こる寿命はBinding Cacheエントリーにホームのエージェントによって保存されます、そして、ホームのエージェントはこの生涯の満了の後にこのBinding Cacheエントリーを削除しなければなりません。
Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node constructed as follows:
Binding UpdateのAcknowledge(A)ビットの設定にかかわらず、ホームのエージェントは以下の通り構成されたモバイルノードにBinding Acknowledgementを返さなければなりません:
o The Status field MUST be set to a value indicating success. The
value 1 (accepted but prefix discovery necessary) MUST be used if
the subnet prefix of the specified home address is deprecated, or
becomes deprecated during the lifetime of the binding, or becomes
invalid at the end of the lifetime. The value 0 MUST be used
o 成功を示す値にStatus分野を設定しなければなりません。 値1(受け入れますが、必要な状態で発見を前に置きます)は、指定されたホームアドレスのサブネット接頭語が推奨しないなら使用しなければならないか、結合の生涯推奨しなくなるか、または生涯の終わりに無効になります。 値0を使用しなければなりません。
Johnson, et al. Standard Track [Page 90] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[90ページ]のRFC3775移動性サポート
otherwise. For the purposes of comparing the binding and prefix
lifetimes, the prefix lifetimes are first converted into units of
four seconds by ignoring the two least significant bits.
そうでなければ。 結合と接頭語生涯を比較する目的のために生涯を前に置いてください、2つの最下位ビットを無視することによって4秒の単位に変換された1番目はそうです。
o The Key Management Mobility Capability (K) bit is set if the
following conditions are all fulfilled, and cleared otherwise:
o 以下の条件がすべて実現していて、別の方法でクリアされるなら、Key Management Mobility Capability(K)ビットは設定されます:
* The Key Management Mobility Capability (K) bit was set in the
Binding Update.
* Key Management Mobility Capability(K)ビットはBinding Updateに設定されました。
* The IPsec security associations between the mobile node and the
home agent have been established dynamically.
* モバイルノードとホームのエージェントとのIPsecセキュリティ仲間はダイナミックに設立されました。
* The home agent has the capability to update its endpoint in the
used key management protocol to the new care-of address every
time it moves.
* ホームのエージェントには中古のかぎ管理プロトコルの終点を新しさにアップデートする能力がある、注意、-、毎回、それが移動であると扱ってください。
Depending on the final value of the bit in the Binding
Acknowledgement, the home agent SHOULD perform the following
actions:
Binding Acknowledgementのビットの検査値によって、ホームのエージェントSHOULDは以下の動作を実行します:
K = 0
K=0
Discard key management connections, if any, to the old care-of
address. If the mobile node did not have a binding before
sending this Binding Update, discard the connections to the
home address.
もしあればかぎ管理接続を老人に捨ててください、注意、-、アドレス。 このBinding Updateを送る前に、モバイルノードに結合がなかったなら、ホームアドレスに接続を捨ててください。
K = 1
K=1
Move the peer endpoint of the key management protocol
connection, if any, to the new care-of address. For an IKE
phase 1 connection, this means that any IKE packets sent to the
peer are sent to this address, and packets from this address
with the original ISAKMP cookies are accepted.
もしあればかぎ管理のプロトコル接続の同輩終点を新しさに動かしてください、注意、-、アドレス。 どんなIKEパケットも同輩に送ったこの手段をこのアドレスに送ります、そして、IKEに関しては、1つの接続の位相を合わせてください、そして、オリジナルのISAKMPクッキーがあるこのアドレスからのパケットを受け入れます。
Note that RFC 2408 [8] Section 2.5.3 gives specific rules that
ISAKMP cookies must satisfy: they must depend on specific
parties and can only be generated by the entity itself. Then
it recommends a particular way to do this, namely a hash of IP
addresses. With the K bit set to 1, the recommended
implementation technique does not work directly. To satisfy
the two rules, the specific parties must be treated as the
original IP addresses, not the ones in use at the specific
moment.
RFC2408[8]部2.5の.3がISAKMPクッキーが満足させられなければならないという特定の規則を与えることに注意してください: それらは、特定のパーティーに頼らなければならなくて、実体自体で生成することができるだけです。 そして、それはこれをする特定の方法、すなわち、IPアドレスのハッシュを推薦します。 1に設定されたKビットで、お勧めの実装のテクニックは直接利きません。 2つの規則を満たすために、特定の瞬間に使用中のものではなく、オリジナルのIPアドレスとして特定のパーティーを扱わなければなりません。
o The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.
o Binding Updateで与えられているSequence NumberからSequence Number分野をコピーしなければなりません。
Johnson, et al. Standard Track [Page 91] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[91ページ]のRFC3775移動性サポート
o The Lifetime field MUST be set to the remaining lifetime for the
binding as set by the home agent in its home registration Binding
Cache entry for the mobile node, as described above.
o ホームのエージェントによって設定されるようにLifetime分野は結合のためにモバイルノードのための本国登録Binding Cacheエントリーに残っている生涯に位置しなければなりません、上で説明されるように。
o If the home agent stores the Binding Cache entry in nonvolatile
storage, then the Binding Refresh Advice mobility option MUST be
omitted. Otherwise, the home agent MAY include this option to
suggest that the mobile node refreshes its binding before the
actual lifetime of the binding ends.
o ホームのエージェントが不揮発性記憶装置におけるBinding Cacheエントリーを保存するなら、Binding Refresh Advice移動性オプションを省略しなければなりません。 さもなければ、ホームのエージェントは、モバイルノードが、拘束力がある終わりの実際の生涯の前に付くのをリフレッシュするのを示すためにこのオプションを入れるかもしれません。
If the Binding Refresh Advice mobility option is present, the
Refresh Interval field in the option MUST be set to a value less
than the Lifetime value being returned in the Binding
Acknowledgement. This indicates that the mobile node SHOULD
attempt to refresh its home registration at the indicated shorter
interval. The home agent MUST still retain the registration for
the Lifetime period, even if the mobile node does not refresh its
registration within the Refresh period.
Binding Refresh Advice移動性オプションが存在しているなら、Binding Acknowledgementで返されるLifetime値より少ない値にオプションにおけるRefresh Interval分野を設定しなければなりません。 これは、モバイルノードSHOULDが、示されたより短い間隔で、本国登録をリフレッシュするのを試みるのを示します。 ホームのエージェントはまだLifetimeの期間のための登録を保有しなければなりません、モバイルノードがRefreshの期間中に登録をリフレッシュしないでも。
The rules for selecting the Destination IP address (and possibly routing header construction) for the Binding Acknowledgement to the mobile node are the same as in Section 9.5.4.
Binding AcknowledgementのためのDestination IPアドレス(そして、ことによるとルーティングヘッダー工事)をモバイルノードに選択するための規則はセクション9.5.4と同じです。
In addition, the home agent MUST follow the procedure defined in Section 10.4.1 to intercept packets on the mobile node's home link addressed to the mobile node, while the home agent is serving as the home agent for this mobile node. The home agent MUST also be prepared to accept reverse tunneled packets from the new care-of address of the mobile node, as described in Section 10.4.5. Finally, the home agent MUST also propagate new home network prefixes, as described in Section 10.6.
さらに、ホームのエージェントはモバイルノードに扱われたモバイルノードのホームのリンクの上にパケットを妨害するためにセクション10.4.1で定義された手順に従わなければなりません、ホームのエージェントがこのモバイルノードのためのホームのエージェントとして勤めている間。 また、ホームのエージェントが新しさから逆のトンネルを堀られたパケットを受け入れる用意ができていなければならない、注意、-、セクション10.4.5で説明されるようなモバイルノードのアドレス。 また、最終的に、ホームのエージェントはセクション10.6で説明されるように新しいホームネットワーク接頭語を伝播しなければなりません。
10.3.2. Primary Care-of Address De-Registration
10.3.2. 初期医療、-、反-登録を扱ってください。
A binding may need to be de-registered when the mobile node returns home or when the mobile node knows that it will not have any care-of addresses in the visited network.
A結合が、モバイルノードが家に帰るか、またはモバイルノードが、それにはいずれもないのを知っているとき、反-登録されている必要があるかもしれない、注意、-、訪問されたネットワークでは、扱います。
A Binding Update is validated and authorized in the manner described in the previous section; note that when the mobile node de-registers when it is at home, it may not include the Home Address destination option, in which case the mobile node's home address is the source IP address of the de-registration Binding Update. This section describes the processing of a valid Binding Update that requests the receiving node to no longer serve as its home agent, de-registering its primary care-of address.
Binding Updateは前項で説明された方法で、有効にされて、認可されます。 それがホームにあるとき、モバイルノードが反-登録するとき、ホームAddress目的地オプションを含まないかもしれなくて、その場合、モバイルノードのホームアドレスが反-登録Binding UpdateのソースIPアドレスであることに注意してください。 このセクションはもうホームのエージェントとして勤めないよう受信ノードに要求する有効なBinding Updateの処理について説明します、反-登録している、それ、初期医療、-、アドレス
Johnson, et al. Standard Track [Page 92] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[92ページ]のRFC3775移動性サポート
To begin processing the Binding Update, the home agent MUST perform the following test:
Binding Updateを処理し始めるために、ホームのエージェントは以下のテストを実行しなければなりません:
o If the receiving node has no entry marked as a home registration
in its Binding Cache for this mobile node, then this node MUST
reject the Binding Update and SHOULD return a Binding
Acknowledgement to the mobile node, in which the Status field is
set to 133 (not home agent for this mobile node).
o 受信ノードが、エントリーが全くこのモバイルノードのために本国登録としてBinding Cacheに示されないのを持っているなら、このノードはBinding Updateを拒絶しなければなりません、そして、SHOULDはモバイルノードにBinding Acknowledgementを返します。Status分野はノードに133(このモバイルノードのためのホームのエージェントでない)に設定されます。
If the home agent does not reject the Binding Update as described above, then it MUST delete any existing entry in its Binding Cache for this mobile node. Then, the home agent MUST return a Binding Acknowledgement to the mobile node, constructed as follows:
ホームのエージェントが上で説明されるようにBinding Updateを拒絶しないなら、それはこのモバイルノードのためにBinding Cacheのどんな既存のエントリーも削除しなければなりません。 次に、ホームのエージェントは以下の通り構成されたモバイルノードにBinding Acknowledgementを返さなければなりません:
o The Status field MUST be set to a value 0, indicating success.
o 成功を示して、値0にStatus分野を設定しなければなりません。
o The Key Management Mobility Capability (K) bit is set or cleared
and actions based on its value are performed as described in the
previous section. The mobile node's home address is used as its
new care-of address for the purposes of moving the key management
connection to a new endpoint.
o Key Management Mobility Capability(K)ビットは、設定されるか、またはきれいにされます、そして、値に基づく動作は前項で説明されるように実行されます。 それが新しいのでモバイルノードのホームアドレスが使用されている、注意、-、移行する目的には、かぎ管理接続に新しい終点に演説してください。
o The Sequence Number field MUST be copied from the Sequence Number
given in the Binding Update.
o Binding Updateで与えられているSequence NumberからSequence Number分野をコピーしなければなりません。
o The Lifetime field MUST be set to zero.
o Lifetime分野をゼロに設定しなければなりません。
o The Binding Refresh Advice mobility option MUST be omitted.
o Binding Refresh Advice移動性オプションを省略しなければなりません。
In addition, the home agent MUST stop intercepting packets on the mobile node's home link that are addressed to the mobile node (Section 10.4.1).
さらに、ホームのエージェントは、モバイルノードのホームのリンクの上のモバイルノード(セクション10.4.1)に扱われるパケットを妨害するのを止めなければなりません。
The rules for selecting the Destination IP address (and, if required, routing header construction) for the Binding Acknowledgement to the mobile node are the same as in the previous section. When the Status field in the Binding Acknowledgement is greater than or equal to 128 and the Source Address of the Binding Update is on the home link, the home agent MUST send it to the mobile node's link layer address (retrieved either from the Binding Update or through Neighbor Solicitation).
Binding AcknowledgementのためにDestination IPアドレスをモバイルノードに選択する(必要なら、ヘッダー工事を発送して)ための規則は前項と同じです。 Binding AcknowledgementのStatus分野が128以上であり、ホームのリンクの上にBinding UpdateのSource Addressがあるとき、ホームのエージェントはモバイルノードのリンクレイヤアドレス(Binding UpdateかNeighbor Solicitationを通して検索される)にそれを送らなければなりません。
Johnson, et al. Standard Track [Page 93] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[93ページ]のRFC3775移動性サポート
10.4. Packet Processing
10.4. パケット処理
10.4.1. Intercepting Packets for a Mobile Node
10.4.1. モバイルノードのためにパケットを妨害します。
While a node is serving as the home agent for mobile node it MUST attempt to intercept packets on the mobile node's home link that are addressed to the mobile node.
ノードがモバイルノードのためのホームのエージェントとして勤めている間、それは、モバイルノードのホームのリンクの上のモバイルノードに扱われるパケットを妨害するのを試みなければなりません。
In order to do this, when a node begins serving as the home agent it MUST multicast onto the home link a Neighbor Advertisement message [12] on behalf of the mobile node. For the home address specified in the Binding Update, the home agent sends a Neighbor Advertisement message [12] to the all-nodes multicast address on the home link to advertise the home agent's own link-layer address for this IP address on behalf of the mobile node. If the Link-Layer Address Compatibility (L) flag has been specified in the Binding Update, the home agent MUST do the same for the link-local address of the mobile node.
これをするために、ノードがホームのエージェントとしてそれに勤め始めると、ホームへのマルチキャストはモバイルノードを代表してNeighbor Advertisementメッセージ[12]をリンクしなければなりませんか? Binding Updateで指定されたホームアドレスに関しては、ホームのエージェントはモバイルノードを代表してこのIPアドレスのためのホームのエージェントの自己のリンクレイヤアドレスの広告を出すオールノードマルチキャストアドレスへのホームのリンクに関するNeighbor Advertisementメッセージ[12]を送ります。 Link-層のAddress Compatibility(L)旗がBinding Updateで指定されたなら、ホームのエージェントはモバイルノードのリンクローカルアドレスのために同じようにしなければなりません。
All fields in each Neighbor Advertisement message SHOULD be set in the same way they would be set by the mobile node if it was sending this Neighbor Advertisement [12] while at home, with the following exceptions:
すべてが発信しているならそれらがモバイルノードによって設定される同じようにおけるセットがこのNeighbor Advertisementであったなら[12] ホームにある間、それぞれのNeighbor AdvertisementメッセージでSHOULDをさばきます、以下の例外で:
o The Target Address in the Neighbor Advertisement MUST be set to
the specific IP address for the mobile node.
o Neighbor AdvertisementのTarget Addressはモバイルノードのための特定のIPアドレスに用意ができなければなりません。
o The Advertisement MUST include a Target Link-layer Address option
specifying the home agent's link-layer address.
o Advertisementはホームのエージェントのリンクレイヤアドレスを指定するTarget Link-層のAddressオプションを含まなければなりません。
o The Router (R) bit in the Advertisement MUST be set to zero.
o AdvertisementのRouter(R)ビットをゼロに設定しなければなりません。
o The Solicited Flag (S) in the Advertisement MUST NOT be set, since
it was not solicited by any Neighbor Solicitation.
o それがどんなNeighbor Solicitationによっても請求されなかったので、AdvertisementのSolicited Flag(S)はセットであるはずがありません。
o The Override Flag (O) in the Advertisement MUST be set, indicating
that the Advertisement SHOULD override any existing Neighbor Cache
entry at any node receiving it.
o AdvertisementのOverride Flag(O)は用意ができなければなりません、Advertisement SHOULDがそれを受けながらどんなノードのどんな既存のNeighbor Cacheエントリーもくつがえすのを示して。
o The Source Address in the IPv6 header MUST be set to the home
agent's IP address on the interface used to send the
advertisement.
o IPv6ヘッダーのSource Addressは広告を送るのに使用されるインタフェースに関するホームのエージェントのIPアドレスに用意ができなければなりません。
Any node on the home link that receives one of the Neighbor Advertisement messages (described above) will update its Neighbor Cache to associate the mobile node's address with the home agent's link layer address, causing it to transmit any future packets normally destined to the mobile node to the mobile node's home agent.
Neighbor Advertisementメッセージ(上で、説明される)の1つを受け取るホームのリンクの上のどんなノードもホームのエージェントのリンクレイヤアドレスにモバイルノードのアドレスを関連づけるためにNeighbor Cacheをアップデートするでしょう、通常、モバイルノードに運命づけられたどんな将来のパケットもモバイルノードのホームのエージェントに伝えることを引き起こして。
Johnson, et al. Standard Track [Page 94] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[94ページ]のRFC3775移動性サポート
Since multicasting on the local link (such as Ethernet) is typically not guaranteed to be reliable, the home agent MAY retransmit this Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see [12]) times to increase its reliability. It is still possible that some nodes on the home link will not receive any of the Neighbor Advertisements, but these nodes will eventually be able to detect the link-layer address change for the mobile node's address through use of Neighbor Unreachability Detection [12].
地方のリンク(イーサネットなどの)の上のマルチキャスティングが信頼できるように通常保証されないので、ホームのエージェントはこのNeighbor Advertisementメッセージをマックス_NEIGHBOR_ADVERTISEMENTまで再送するかもしれません。([12])回を見て、信頼性を増強してください。 ホームのリンクの上のいくつかのノードがNeighbor Advertisementsのいずれも受けないのが、まだ可能ですが、これらのノードは結局、モバイルノードのアドレスのためにNeighbor Unreachability Detection[12]の使用でリンクレイヤアドレス変化を検出できるでしょう。
While a node is serving as a home agent for some mobile node, the home agent uses IPv6 Neighbor Discovery [12] to intercept unicast packets on the home link addressed to the mobile node. In order to intercept packets in this way, the home agent MUST act as a proxy for this mobile node and reply to any received Neighbor Solicitations for it. When a home agent receives a Neighbor Solicitation, it MUST check if the Target Address specified in the message matches the address of any mobile node for which it has a Binding Cache entry marked as a home registration.
ノードが何らかのモバイルノードのためのホームのエージェントとして勤めている間、ホームのエージェントは、モバイルノードに扱われたホームのリンクの上にユニキャストパケットを妨害するのにIPv6 Neighborディスカバリー[12]を使用します。 このようにパケットを妨害して、ホームのエージェントは、このモバイルノードのためにプロキシとして務めて、それのためにどんな容認されたNeighbor Solicitationsにも答えなければなりません。 ホームのエージェントがNeighbor Solicitationを受け取るとき、それは、Target Addressがメッセージマッチで何かそれが、Binding Cacheエントリーが本国登録として示されるのを持っているモバイルノードのアドレスを指定したかどうかチェックしなければなりません。
If such an entry exists in the home agent's Binding Cache, the home agent MUST reply to the Neighbor Solicitation with a Neighbor Advertisement giving the home agent's own link-layer address as the link-layer address for the specified Target Address. In addition, the Router (R) bit in the Advertisement MUST be set to zero. Acting as a proxy in this way allows other nodes on the mobile node's home link to resolve the mobile node's address and for the home agent to defend these addresses on the home link for Duplicate Address Detection [12].
そのようなエントリーがホームのエージェントのBinding Cacheに存在しているなら、Neighbor Advertisementが指定されたTarget Addressのためのリンクレイヤアドレスとしてホームのエージェントの自己のリンクレイヤアドレスを与えていて、ホームのエージェントはNeighbor Solicitationに答えなければなりません。 さらに、AdvertisementのRouter(R)ビットをゼロに設定しなければなりません。 モバイルノードのアドレスを決議して、ホームのエージェントがDuplicate Address Detection[12]のためにホームのリンクに関するこれらのアドレスを防御するように、プロキシとしてこのように務めるのはモバイルノードのホームのリンクの上の他のノードを許容します。
10.4.2. Processing Intercepted Packets
10.4.2. 処理はパケットを妨害しました。
For any packet sent to a mobile node from the mobile node's home agent (in which the home agent is the original sender of the packet), the home agent is operating as a correspondent node of the mobile node for this packet and the procedures described in Section 9.3.2 apply. The home agent then uses a routing header to route the packet to the mobile node by way of the primary care-of address in the home agent's Binding Cache.
モバイルノードのホームのエージェントからモバイルノードに送られたどんなパケット(ホームのエージェントはそこのパケットの元の送り主である)に関してはも、このパケットのためのモバイルノードの通信員ノードとセクション9.3.2で説明された手順が適用されるとき、ホームのエージェントは働いています。 を通して次に、ホームのエージェントがモバイルノードにパケットを発送するのにルーティングヘッダーを使用する、初期医療、-、ホームのエージェントのBinding Cacheのアドレス。
While the mobile node is away from home, the home agent intercepts any packets on the home link addressed to the mobile node's home address, as described in Section 10.4.1. In order to forward each intercepted packet to the mobile node, the home agent MUST tunnel the packet to the mobile node using IPv6 encapsulation [15]. When a home agent encapsulates an intercepted packet for forwarding to the mobile node, the home agent sets the Source Address in the new tunnel IP header to the home agent's own IP address and sets the Destination Address in the tunnel IP header to the mobile node's primary care-of
モバイルノードは家にいないのですが、ホームのエージェントはモバイルノードのホームアドレスに扱われたホームのリンクの上のどんなパケットも妨害します、セクション10.4.1で説明されるように。 それぞれの妨害されたパケットをモバイルノードに送るために、IPv6カプセル化[15]を使用して、ホームのエージェントはモバイルノードにパケットにトンネルを堀らなければなりません。 ホームのエージェントが推進のために妨害されたパケットをモバイルノードにカプセルに入れると、ホームのエージェントがホームのエージェントの自己のIPアドレスへの新しいトンネルIPヘッダーにSource Addressをはめ込んで、モバイルノードのものへのトンネルIPヘッダーにDestination Addressをはめ込む、初期医療、-
Johnson, et al. Standard Track [Page 95] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[95ページ]のRFC3775移動性サポート
address. When received by the mobile node, normal processing of the tunnel header [15] will result in decapsulation and processing of the original packet by the mobile node.
アドレス。 モバイルノードで受け取ると、トンネルヘッダー[15]の正常処理はモバイルノードでオリジナルのパケットの被膜剥離術と処理をもたらすでしょう。
However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. Instead, these packets MUST be discarded and the home agent SHOULD return an ICMP Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address). Packets addressed to the mobile node's site-local address SHOULD NOT be tunneled to the mobile node by default.
しかしながら、モバイルノードのリンクローカルアドレスに扱われたパケットにモバイルノードにトンネルを堀ってはいけません。 代わりに、これらのパケットを捨てなければなりません、そして、ホームのエージェントSHOULDはICMP Destination Unreachableを返します、Code3、パケットのSource Addressへのメッセージ(このSource Addressがマルチキャストアドレスでないなら)。 パケットは、ノードのサイトローカルアドレスがSHOULD NOTであるとモバイルに扱いました。デフォルトでモバイルノードにトンネルを堀られます。
Interception and tunneling of the following multicast addressed packets on the home network are only done if the home agent supports multicast group membership control messages from the mobile node as described in the next section. Tunneling of multicast packets to a mobile node follows similar limitations to those defined above for unicast packets addressed to the mobile node's link-local and site- local addresses. Multicast packets addressed to a multicast address with link-local scope [3], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node. These packets SHOULD be silently discarded (after delivering to other local multicast recipients). Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3], to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. Multicast packets addressed with a global scope, to which the mobile node has successfully subscribed, MUST be tunneled to the mobile node.
ホームのエージェントが、次のセクションで説明されるようにマルチキャストグループ会員資格がモバイルノードからのコントロールメッセージであるとサポートする場合にだけ、ホームネットワークのパケットであると扱われた以下のマルチキャストの妨害とトンネリングをします。 モバイルノードへのマルチキャストパケットのトンネリングはモバイルノードのものにリンク地方で扱われたユニキャストパケットのために上で定義されたものへの同様の制限とサイトのローカルのアドレスに従います。 モバイルノードが申し込まれるリンク地方の範囲[3]でマルチキャストアドレスに扱われたマルチキャストパケットにモバイルノードにトンネルを堀ってはいけません。 捨てられて、これらのパケットSHOULDは静かにこと(他の地元のマルチキャスト受取人に配送した後に)です。 範囲がリンク地方であるより大きい状態でマルチキャストアドレスに扱われましたが、マルチキャストパケットはグローバルであるより小さく扱われました。(例えば、サイト地方の、そして、組織地方の[3](SHOULD NOT、モバイルノードは申し込まれる)を. マルチキャストパケットがモバイルノードが首尾よく申し込んだグローバルな範囲で扱ったモバイルノードにトンネルを堀られて、モバイルノードにトンネルを堀らなければなりません。
Before tunneling a packet to the mobile node, the home agent MUST perform any IPsec processing as indicated by the security policy data base.
モバイルノードにパケットにトンネルを堀る前に、ホームのエージェントは安全保障政策データベースによって示されるようにどんなIPsec処理も実行しなければなりません。
10.4.3. Multicast Membership Control
10.4.3. マルチキャスト会員資格コントロール
This section is a prerequisite for the multicast data packet forwarding, described in the previous section. If this support is not provided, multicast group membership control messages are silently ignored.
このセクションは前項で説明されたマルチキャストデータ・パケット推進のための前提条件です。 このサポートが提供されないなら、マルチキャストグループ会員資格コントロールメッセージは静かに無視されます。
In order to forward multicast data packets from the home network to all the proper mobile nodes, the home agent SHOULD be capable of receiving tunneled multicast group membership control information from the mobile node in order to determine which groups the mobile node has subscribed to. These multicast group membership messages are Listener Report messages specified in MLD [17] or in other protocols such as [37].
ホームネットワークから適切なすべてのモバイルノードまでマルチキャストデータ・パケットを進めてください、ホームのエージェントSHOULD。モバイルノードがどのグループに加入したかを決定するためにモバイルノードからトンネルを堀られたマルチキャストグループ会員資格制御情報を受け取ることができてください。 これらのマルチキャストグループ会員資格メッセージはMLD[17]か[37]などの他のプロトコルで指定されたListener Reportメッセージです。
Johnson, et al. Standard Track [Page 96] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[96ページ]のRFC3775移動性サポート
The messages are issued by the mobile node, but sent through the reverse tunnel to the home agent. These messages are issued whenever the mobile node decides to enable reception of packets for a multicast group or in response to an MLD Query from the home agent. The mobile node will also issue multicast group control messages to disable reception of multicast packets when it is no longer interested in receiving multicasts for a particular group.
メッセージをモバイルノードで発行しますが、逆のトンネルを通してホームのエージェントに送ります。 モバイルノードが、マルチキャストグループかホームのエージェントからのMLD Queryに対応してパケットのレセプションを可能にすると決めるときはいつも、これらのメッセージを発行します。 また、モバイルノードは特定のグループのためにもうマルチキャストを受けたがっていないときマルチキャストパケットのレセプションを無効にするマルチキャスト集団経営メッセージを発行するでしょう。
To obtain the mobile node's current multicast group membership the home agent must periodically transmit MLD Query messages through the tunnel to the mobile node. These MLD periodic transmissions will ensure the home agent has an accurate record of the groups in which the mobile node is interested despite packet losses of the mobile node's MLD group membership messages.
モバイルノードの現在のマルチキャストグループ会員資格を得るために、ホームのエージェントはトンネルを通して定期的にMLD Queryメッセージをモバイルノードに送らなければなりません。 これらのMLDの周期的なトランスミッションは、ホームのエージェントにはモバイルノードのMLDグループ会員資格メッセージのパケット損失にもかかわらず、モバイルノードが興味を持っているグループの正確な記録があるのを確実にするでしょう。
All MLD packets are sent directly between the mobile node and the home agent. Since all of these packets are destined to a link-scope multicast address and have a hop limit of 1, there is no direct forwarding of such packets between the home network and the mobile node. The MLD packets between the mobile node and the home agent are encapsulated within the same tunnel header used for other packet flows between the mobile node and home agent.
モバイルノードとホームのエージェントの直接間にすべてのMLDパケットを送ります。 これらのパケットのすべてがリンク範囲マルチキャストアドレスに運命づけられていて、1のホップ限界を持っているので、ホームネットワークとモバイルノードの間には、そのようなパケットをどんなダイレクト推進もありません。 モバイルノードとホームのエージェントの間のMLDパケットはモバイルノードとホームのエージェントの間の他のパケット流れに使用される同じトンネルヘッダーの中にカプセルに入れられます。
Note that at this time, even though a link-local source is used on MLD packets, no functionality depends on these addresses being unique, nor do they elicit direct responses. All MLD messages are sent to multicast destinations. To avoid ambiguity on the home agent, due to mobile nodes which may choose identical link-local source addresses for their MLD function, it is necessary for the home agent to identify which mobile node was actually the issuer of a particular MLD message. This may be accomplished by noting which tunnel such an MLD arrived by, which IPsec SA was used, or by other distinguishing means.
リンク地元筋がMLDパケットの上で使用されますが、このとき機能性を全くこれらのユニークなアドレスに依存しないで、また直接的な反応を引き出さないことに注意してください。 すべてのMLDメッセージをマルチキャストの目的地に送ります。 それらのMLD機能のためのアドレスを同じリンク地元筋に選ぶかもしれないモバイルノードのためホームのエージェントの上であいまいさを避けるために、ホームのエージェントが、どのモバイルノードが実際に特定のMLDメッセージの発行人であったかを特定するのが必要です。 そのようなMLDが到着したどのトンネル、どのIPsec SAが使用されたか、または他で手段を区別していたかに注意することによって、これは達成されるかもしれません。
This specification puts no requirement on how the functions in this section and the multicast forwarding in Section 10.4.2 are to be achieved. At the time of this writing it was thought that a full IPv6 multicast router function would be necessary on the home agent, but it may be possible to achieve the same effects through a "proxy MLD" application coupled with kernel multicast forwarding. This may be the subject of future specifications.
この仕様はどう達成されるかにこのセクションでの機能とセクション10.4.2におけるマルチキャスト推進がことである要件を全く置きません。 この書くこと時点で、完全なIPv6マルチキャストルータ機能がホームのエージェントで必要であると思われましたが、「プロキシMLD」というカーネルマルチキャスト推進に結びつけられたアプリケーションで同じ効果を達成するのは可能であるかもしれません。 これは将来の仕様の対象であるかもしれません。
Johnson, et al. Standard Track [Page 97] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[97ページ]のRFC3775移動性サポート
10.4.4. Stateful Address Autoconfiguration
10.4.4. Statefulアドレス自動構成
This section describes how home agents support the use of stateful address autoconfiguration mechanisms such as DHCPv6 [29] from the mobile nodes. If this support is not provided, then the M and O bits must remain cleared on the Mobile Prefix Advertisement Messages. Any mobile node which sends DHCPv6 messages to the home agent without this support will not receive a response.
このセクションはホームのエージェントがどうモバイルノードからのDHCPv6[29]などのstatefulアドレス自動構成メカニズムの使用をサポートするかを説明します。 このサポートが提供されないなら、MとOビットはモバイルPrefix Advertisement Messagesでクリアされたままで残らなければなりません。 このサポートなしでホームのエージェントへのメッセージをDHCPv6に送るどんなモバイルノードも応答を受けないでしょう。
If DHCPv6 is used, packets are sent with link-local source addresses either to a link-scope multicast address or a link-local address. Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets cannot be forwarded onto the home network, it is necessary for the home agent to either implement a DHCPv6 relay agent or a DHCPv6 server function itself. The arriving tunnel or IPsec SA of DHCPv6 link-scope messages from the mobile node must be noted so that DHCPv6 responses may be sent back to the appropriate mobile node. DHCPv6 messages sent to the mobile node with a link-local destination must be tunneled within the same tunnel header used for other packet flows.
DHCPv6が使用されているなら、リンク地元筋アドレスと共にリンク範囲マルチキャストアドレスかリンクローカルアドレスにパケットを送ります。 サービスが逆にするかもしれないDHCPv6の場所を見つけることを望んでいるモバイルノードが標準のDHCPv6パケットにホームのエージェントにトンネルを堀ります。 これらのリンク範囲パケットをホームネットワークに送ることができないので、ホームのエージェントがDHCPv6中継エージェントかDHCPv6サーバ機能自体を実装するのが必要です。 適切なモバイルノードをDHCPv6応答に送り返すことができるようにモバイルノードからのDHCPv6リンク範囲メッセージの到着しているトンネルかIPsec SAに注意しなければなりません。 他のパケット流れに使用される同じトンネルヘッダーの中にリンク地方の目的地があるモバイルノードに送られたDHCPv6メッセージにトンネルを堀らなければなりません。
10.4.5. Handling Reverse Tunneled Packets
10.4.5. 取り扱い逆はパケットにトンネルを堀りました。
Unless a binding has been established between the mobile node and a correspondent node, traffic from the mobile node to the correspondent node goes through a reverse tunnel. Home agents MUST support reverse tunneling as follows:
結合がモバイルノードと通信員ノードの間で確立されていない場合、モバイルノードから通信員ノードまでのトラフィックは逆のトンネルを通ります。 ホームのエージェントは以下の逆のトンネリングをサポートしなければなりません:
o The tunneled traffic arrives to the home agent's address using
IPv6 encapsulation [15].
o トンネルを堀られたトラフィックは、IPv6カプセル化[15]を使用することでホームのエージェントのアドレスに到着します。
o Depending on the security policies used by the home agent, reverse
tunneled packets MAY be discarded unless accompanied by a valid
ESP header. The support for authenticated reverse tunneling
allows the home agent to protect the home network and
correspondent nodes from malicious nodes masquerading as a mobile
node.
o ホームのエージェントによって使用された安全保障政策によって、有効な超能力ヘッダーによって同伴されない場合、逆のトンネルを堀られたパケットは捨てられるかもしれません。 認証された逆のトンネリングのサポートで、ホームのエージェントはモバイルノードのふりをする悪意があるノードからホームネットワークと通信員ノードを保護できます。
o Otherwise, when a home agent decapsulates a tunneled packet from
the mobile node, the home agent MUST verify that the Source
Address in the tunnel IP header is the mobile node's primary
care-of address. Otherwise, any node in the Internet could send
traffic through the home agent and escape ingress filtering
limitations. This simple check forces the attacker to know the
current location of the real mobile node and be able to defeat
ingress filtering. This check is not necessary if the reverse-
tunneled packet is protected by ESP in tunnel mode.
o モバイルノードからのトンネルを堀られたパケット、ホームのエージェントのホームのエージェントdecapsulatesが、トンネルIPヘッダーのSource Addressがそうであることを別の方法で確かめなければならない、モバイルノードのもの、初期医療、-、アドレス さもなければ、インターネットのどんなノードも、ホームのエージェントを通してトラフィックを送って、制限をフィルターにかけるイングレスから逃げるかもしれません。 この簡単なチェックは、攻撃者が全くモバイルのノードの現在の位置を知って、イングレスフィルタリングを破ることができるのを強制します。 逆トンネルを堀られたパケットがトンネルモードにおける超能力によって保護されるなら、このチェックは必要ではありません。
Johnson, et al. Standard Track [Page 98] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[98ページ]のRFC3775移動性サポート
10.4.6. Protecting Return Routability Packets
10.4.6. リターンRoutabilityパケットを保護します。
The return routability procedure, described in Section 5.2.5, assumes that the confidentiality of the Home Test Init and Home Test messages is protected as they are tunneled between the home agent and the mobile node. Therefore, the home agent MUST support tunnel mode IPsec ESP for the protection of packets belonging to the return routability procedure. Support for a non-null encryption transform and authentication algorithm MUST be available. It is not necessary to distinguish between different kinds of packets during the return routability procedure.
セクション5.2.5で説明されたリターンroutability手順は、それらがホームのエージェントとモバイルノードの間でトンネルを堀られるときホームTest InitとホームTestメッセージの秘密性が保護されると仮定します。 したがって、ホームのエージェントは、リターンroutability手順に属すパケットの保護のためにトンネルモードIPsecが超能力であるとサポートしなければなりません。 非ヌル暗号化変換と認証アルゴリズムのサポートは利用可能であるに違いありません。 リターンroutability手順の間、異種のパケットを見分けるのは必要ではありません。
Security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed [21].
セキュリティ協会がこの保護を提供するのが必要です。 いつ、注意、-、モバイルノードのためのアドレスは受け入れられたBinding Updateの結果、変化して、特別な処理がこれらのセキュリティ協会が使用させられた次のパケットに必要であるか。 ホームのエージェントが新しさを設定しなければならない、注意、-、これらのパケットの送付先アドレスとして、まるでセキュリティ協会における外側のヘッダー送付先アドレスが[21]を変えたかのように、扱います。
The above protection SHOULD be used with all mobile nodes. The use is controlled by configuration of the IPsec security policy database both at the mobile node and at the home agent.
保護SHOULDを超えて、すべてのモバイルノードと共に使用されてください。 使用はモバイルノードにおいてホームのエージェントでIPsec安全保障政策データベースの構成によって制御されます。
As described earlier, the Binding Update and Binding Acknowledgement messages require protection between the home agent and the mobile node. The Mobility Header protocol carries both these messages as well as the return routability messages. From the point of view of the security policy database these messages are indistinguishable. When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent. This can be achieved, for instance, by defining the security policy database entries specifically for the tunnel interface. That is, the policy entries are not generally applied on all traffic on the physical interface(s) of the nodes, but rather only on traffic that enters the tunnel. This makes use of per-interface security policy database entries [4] specific to the tunnel interface (the node's attachment to the tunnel [11]).
より早く説明されるように、Binding UpdateとBinding Acknowledgementメッセージはホームのエージェントとモバイルノードの間の保護を必要とします。 Mobility Headerプロトコルはこれらのメッセージとリターンroutabilityメッセージの両方を運びます。 安全保障政策データベースの観点から、これらのメッセージは区別がつきません。 IPsecがリターンroutabilityシグナリングかペイロードパケットを保護するのに使用されるとき、モバイルノードとホームのエージェントとのトンネルのインタフェースであるとカプセル化されたIPv6に入りながら、リターンroutabilityパケットにこの保護を適用するだけでよいです。 例えば、特にトンネルのインタフェースのための安全保障政策データベースエントリーを定義することによって、これを達成できます。 一般に、すなわち、方針エントリーはノードの物理インターフェースにもかかわらず、むしろトンネルに入るトラフィックだけに関するすべてのトラフィックで適用されません。 これはトンネルのインタフェースに特定の1インタフェースあたりの安全保障政策データベースエントリー[4]を利用します。(トンネル[11])へのノードの付属。
10.5. Dynamic Home Agent Address Discovery
10.5. ダイナミックなホームエージェントアドレス発見
This section describes how a home agent can help mobile nodes to discover the addresses of the home agents. The home agent keeps track of the other home agents on the same link and responds to queries sent by the mobile node.
ホームのエージェントが、モバイルノードがホームのエージェントのアドレスを発見するのをどう助けることができるかをこのセクションは説明します。 ホームのエージェントは、同じリンクの上に他のホームのエージェントの動向をおさえて、モバイルノードによって送られた質問に応じます。
Johnson, et al. Standard Track [Page 99] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[99ページ]のRFC3775移動性サポート
10.5.1. Receiving Router Advertisement Messages
10.5.1. ルータ通知メッセージを受け取ります。
For each link on which a router provides service as a home agent, the router maintains a Home Agents List recording information about all other home agents on that link. This list is used in the dynamic home agent address discovery mechanism, described in Section 10.5. The information for the list is learned through receipt of the periodic unsolicited multicast Router Advertisements, in a manner similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [12]. In the construction of the Home Agents List, the Router Advertisements are from each (other) home agent on the link and the Home Agent (H) bit is set in them.
ルータがホームのエージェントとしてサービスを提供する各リンクに関しては、ルータは、他のすべてのホームのエージェントの情報をそれに記録するホームエージェントListがリンクすると主張します。 このリストはセクション10.5で説明されたダイナミックなホームエージェントアドレス発見メカニズムで使用されます。 リストのための情報は周期的な求められていないマルチキャストRouter Advertisementsの領収書で学習されます、Neighborディスカバリー[12]のために各ホストによって維持されたDefault Router Listの概念的なデータ構造と同様の方法で。 ホームエージェントListの構造では、Router Advertisementsはリンクの上のそれぞれの(他)のホームのエージェントから来ています、そして、ホームエージェント(H)ビットは彼らに設定されます。
On receipt of a valid Router Advertisement, as defined in the processing algorithm specified for Neighbor Discovery [12], the home agent performs the following steps in addition to any steps already required of it by Neighbor Discovery:
有効なRouter Advertisementを受け取り次第、Neighborディスカバリー[12]に指定された処理アルゴリズムで定義されるように、ホームのエージェントはそれについてNeighborディスカバリーによって既に必要とされたステップに加えた以下のステップを実行します:
o If the Home Agent (H) bit in the Router Advertisement is not set,
delete the sending node's entry in the current Home Agents List
(if one exists). Skip all the following steps.
o Router Advertisementのホームエージェント(H)ビットが設定されないなら、現在のホームエージェントListで送付ノードのエントリーを削除してください(1つが存在しているなら)。 以下のすべてのステップをサボってください。
o Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement [12].
o さもなければ、Router AdvertisementのIPヘッダーからSource Addressを抽出してください。 これはこのAdvertisement[12]を送るホームのエージェントのこのリンクに関するリンクローカルアイピーアドレスです。
o Determine the preference for this home agent. If the Router
Advertisement contains a Home Agent Information Option, then the
preference is taken from the Home Agent Preference field in the
option; otherwise, the default preference of 0 MUST be used.
o このホームのエージェントのための好みを決定してください。 Router Advertisementがホームエージェント情報Optionを含んでいるなら、オプションにおけるホームエージェントPreference分野から好みを取ります。 さもなければ、0のデフォルト好みを使用しなければなりません。
o Determine the lifetime for this home agent. If the Router
Advertisement contains a Home Agent Information Option, then the
lifetime is taken from the Home Agent Lifetime field in the
option; otherwise, the lifetime specified by the Router Lifetime
field in the Router Advertisement SHOULD be used.
o このホームのエージェントのために生涯を決定してください。 Router Advertisementがホームエージェント情報Optionを含んでいるなら、寿命はオプションにおけるホームエージェントLifetime分野からかかります。 さもなければ、寿命はRouter Lifetime分野のそばで指定しました。Router Advertisement SHOULDでは、使用されます。
o If the link-local address of the home agent sending this
Advertisement is already present in this home agent's Home Agents
List and the received home agent lifetime value is zero,
immediately delete this entry in the Home Agents List.
o このAdvertisementを送るホームのエージェントのリンクローカルアドレスがこのホームのエージェントのホームエージェントListに既に存在していて、容認されたホームエージェント生涯価値がゼロであるなら、至急、ホームエージェントListにおけるこのエントリーを削除してください。
o Otherwise, if the link-local address of the home agent sending
this Advertisement is already present in the receiving home
agent's Home Agents List, reset its lifetime and preference to the
values determined above.
o さもなければ、このAdvertisementを送るホームのエージェントのリンクローカルアドレスが受信ホームのエージェントのホームエージェントListに既に存在しているなら、上で決定している値にその生涯と好みをリセットしてください。
Johnson, et al. Standard Track [Page 100] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[100ページ]のRFC3775移動性サポート
o If the link-local address of the home agent sending this
Advertisement is not already present in the Home Agents List
maintained by the receiving home agent, and the lifetime for the
sending home agent is non-zero, create a new entry in the list,
and initialize its lifetime and preference to the values
determined above.
o このAdvertisementを送るホームのエージェントのリンクローカルアドレスがListが受信ホームのエージェントで維持したホームのエージェントに既に存在していなくて、送付ホームのエージェントのための寿命が非ゼロであるなら、リストにおける新しいエントリーを作成してください、そして、その生涯と好みを上で決定している値に初期化してください。
o If the Home Agents List entry for the link-local address of the
home agent sending this Advertisement was not deleted as described
above, determine any global address(es) of the home agent based on
each Prefix Information option received in this Advertisement in
which the Router Address (R) bit is set (Section 7.2). Add all
such global addresses to the list of global addresses in this Home
Agents List entry.
o このAdvertisementを送るホームのエージェントのリンクローカルアドレスのためのホームエージェントListエントリーが上で説明されるように削除されなかったなら、Router Address(R)ビットが設定されるこのAdvertisement(セクション7.2)に受け取られたそれぞれのPrefix情報オプションに基づくホームのエージェントのあらゆるグローバルアドレス(es)を決定してください。 このホームエージェントListエントリーでそのようなすべてのグローバルなアドレスをグローバルなアドレスのリストに追加してください。
A home agent SHOULD maintain an entry in its Home Agents List for each valid home agent address until that entry's lifetime expires, after which time the entry MUST be deleted.
そのエントリーの寿命がどの時の後にエントリーを吐き出すかまでSHOULDがそれぞれの有効なホームエージェントアドレスのためにホームエージェントListでエントリーであると主張するホームのエージェントを削除しなければなりません。
As described in Section 11.4.1, a mobile node attempts dynamic home agent address discovery by sending an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its home IP subnet prefix. A home agent receiving a Home Agent Address Discovery Request message that serves this subnet SHOULD return an ICMP Home Agent Address Discovery Reply message to the mobile node with the Source Address of the Reply packet set to one of the global unicast addresses of the home agent. The Home Agent Addresses field in the Reply message is constructed as follows:
セクション11.4.1で説明されるように、モバイルノードはホームIPサブネット接頭語のためのモバイルIPv6ホームエージェントanycastアドレス[16]にICMPホームエージェントAddressディスカバリーRequestメッセージを送ることによって、ダイナミックなホームエージェントアドレス発見を試みます。 ReplyパケットのSource Addressと共にICMPホームエージェントAddressディスカバリーReplyメッセージにこのサブネットSHOULDリターンに役立つホームエージェントAddressディスカバリーRequestメッセージをモバイルノードに受け取るホームのエージェントはホームのエージェントのグローバルなユニキャストアドレスの1つにセットしました。 ReplyメッセージのホームエージェントAddresses分野は以下の通り構成されます:
o The Home Agent Addresses field SHOULD contain all global IP
addresses for each home agent currently listed in this home
agent's own Home Agents List (Section 10.1).
o ホームのエージェントAddresses分野SHOULDは現在このホームのエージェントの自身のホームエージェントList(セクション10.1)に記載されているそれぞれのホームのエージェントのためのすべてのグローバルIPアドレスを含んでいます。
o The IP addresses in the Home Agent Addresses field SHOULD be
listed in order of decreasing preference values, based either on
the respective advertised preference from a Home Agent Information
option or on the default preference of 0 if no preference is
advertised (or on the configured home agent preference for this
home agent itself).
o 好みの値を減少させることの順にホームのエージェントAddresses分野SHOULDのIPアドレスが記載されていて、ホームエージェント情報オプションからのそれぞれの広告を出している好みにどちらか基づいているか、デフォルトでは、好みでないなら0の好みの広告を出します(またはこのホームのエージェント自身のための構成されたホームエージェント好みに関して)。
o Among home agents with equal preference, their IP addresses in the
Home Agent Addresses field SHOULD be listed in an order randomized
with respect to other home agents with equal preference every time
a Home Agent Address Discovery Reply message is returned by this
home agent.
o 等しい好みをもっているホームのエージェントの中では、彼らのIPは記載されたコネがホームエージェントAddressディスカバリーReplyメッセージがこのホームのエージェントによって返されるときはいつも、等しい好みで他のホームのエージェントに関してランダマイズされたオーダーであったならホームでエージェントAddresses分野SHOULDを扱います。
o If more than one global IP address is associated with a home
agent, these addresses SHOULD be listed in a randomized order.
o 1つ以上のグローバルIPアドレスがホームのエージェントに関連しているなら、これらはaがランダマイズした記載されたコネがオーダーであったならSHOULDを扱います。
Johnson, et al. Standard Track [Page 101] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[101ページ]のRFC3775移動性サポート
o The home agent SHOULD reduce the number of home agent IP addresses
so that the packet fits within the minimum IPv6 MTU [11]. The
home agent addresses selected for inclusion in the packet SHOULD
be those from the complete list with the highest preference. This
limitation avoids the danger of the Reply message packet being
fragmented (or rejected by an intermediate router with an ICMP
Packet Too Big message [14]).
o ホームのエージェントSHOULDがホームエージェントIPアドレスの数を減少させるので、パケットは最小のIPv6 MTU[11]の中で合います。 ホームエージェントアドレスは包含のためにパケットでSHOULDを選択しました。最も高い好みがある全リストからのそれらになってください。 この制限は断片化されるReplyメッセージパケットの危険を避けます。(ICMP Packet Too Bigメッセージ[14])がある中間的ルータで、拒絶されています。
10.6. Sending Prefix Information to the Mobile Node
10.6. 接頭語情報をモバイルノードに送ります。
10.6.1. List of Home Network Prefixes
10.6.1. ホームネットワーク接頭語のリスト
Mobile IPv6 arranges to propagate relevant prefix information to the mobile node when it is away from home, so that it may be used in mobile node home address configuration and in network renumbering. In this mechanism, mobile nodes away from home receive Mobile Prefix Advertisements messages. These messages include Prefix Information Options for the prefixes configured on the home subnet interface(s) of the home agent.
モバイルIPv6は、それが家にいないときに、関連接頭語情報をモバイルノードに伝播するように手配します、モバイルノードホームアドレス構成とネットワークの番号を付け替えるのにそれを使用できるように。 このメカニズムで、ホームから遠くのモバイルノードはモバイルPrefix Advertisementsメッセージを受け取ります。 これらのメッセージはホームのエージェントのホームのサブネットインタフェースで構成された接頭語のためのPrefix情報Optionsを含んでいます。
If there are multiple home agents, differences in the advertisements sent by different home agents can lead to an inability to use a particular home address when changing to another home agent. In order to ensure that the mobile nodes get the same information from different home agents, it is preferred that all of the home agents on the same link be configured in the same manner.
複数のホームのエージェントがいれば、異なったホームのエージェントによって送られた広告の違いは別のホームのエージェントに変化するとき特定のホームアドレスを使用できないことにつながることができます。 モバイルノードが異なったホームのエージェントから同じ情報を得るのを確実にするために、同じリンクの上のホームのエージェントのすべてが同じ方法で構成されるのが好ましいです。
To support this, the home agent monitors prefixes advertised by itself and other home agents on the home link. In RFC 2461 [12] it is acceptable for two routers to advertise different sets of prefixes on the same link. For home agents, the differences should be detected for a given home address because the mobile node communicates only with one home agent at a time and the mobile node needs to know the full set of prefixes assigned to the home link. All other comparisons of Router Advertisements are as specified in Section 6.2.7 of RFC 2461.
これをサポートするために、ホームのエージェントはホームのリンクの上にそれ自体で広告に掲載された接頭語と他のホームのエージェントをモニターします。 RFC2461[12]では、2つのルータにおいて、同じリンクの上に異なったセットの接頭語の広告を出すのは許容できます。 ホームのエージェントのために、モバイルノードが一度に1人のホームのエージェントだけとコミュニケートするので、違いは与えられたホームアドレスのために検出されるべきであり、モバイルノードは、ホームのリンクに割り当てられた接頭語のフルセットを知る必要があります。 Router Advertisementsの他のすべての比較が.7セクション6.2RFC2461で指定されるようにあります。
10.6.2. Scheduling Prefix Deliveries
10.6.2. スケジューリング接頭語配送
A home agent serving a mobile node will schedule the delivery of the new prefix information to that mobile node when any of the following conditions occur:
以下の条件のどれかが現れると、モバイルノードに勤めているホームのエージェントは新しい接頭語情報の配送のそのモバイルノードに計画をするでしょう:
MUST:
必須:
o The state of the flags changes for the prefix of the mobile node's
registered home address.
o 旗の状態はモバイルノードの登録されたホームアドレスの接頭語のために変化します。
Johnson, et al. Standard Track [Page 102] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[102ページ]のRFC3775移動性サポート
o The valid or preferred lifetime is reconfigured or changes for any
reason other than advancing real time.
o 有効であるか都合のよい寿命は、リアルタイムを唱えるのを除いたどんな理由でも再構成されるか、または変化します。
o The mobile node requests the information with a Mobile Prefix
Solicitation (see Section 11.4.2).
o モバイルノードはモバイルPrefix Solicitationと共に情報を要求します(セクション11.4.2を見てください)。
SHOULD:
:であるべきです
o A new prefix is added to the home subnet interface(s) of the home
agent.
o 新しい接頭語はホームのエージェントのホームのサブネットインタフェースに加えられます。
MAY:
5月:
o The valid or preferred lifetime or the state of the flags changes
for a prefix which is not used in any Binding Cache entry for this
mobile node.
o 有効であるか都合のよい生涯か旗の州が、接頭語のためにどれがこのモバイルノードに何かBinding Cacheエントリーで使用されないかを変えます。
The home agent uses the following algorithm to determine when to send prefix information to the mobile node.
ホームのエージェントは、いつ接頭語情報をモバイルノードに送るかを決定するのに以下のアルゴリズムを使用します。
o If a mobile node sends a solicitation, answer right away.
o モバイルノードが懇願を送るなら、すぐ、答えてください。
o If no Mobile Prefix Advertisement has been sent to the mobile node
in the last MaxMobPfxAdvInterval seconds (see Section 13), then
ensure that a transmission is scheduled. The actual transmission
time is randomized as described below.
o 最後のMaxMobPfxAdvInterval秒にどんなモバイルPrefix Advertisementもモバイルノードに送らないなら(セクション13を見てください)、トランスミッションが予定されているのを確実にしてください。 実際のトランスミッション時間は以下で説明されるようにランダマイズされます。
o If a prefix matching the mobile node's home registration is added
on the home subnet interface or if its information changes in any
way that does not deprecate the mobile node's address, ensure that
a transmission is scheduled. The actual transmission time is
randomized as described below.
o モバイルノードの本国登録に合っている接頭語がホームのサブネットインタフェースで加えられるか、または情報がモバイルノードのアドレスを非難しないどんな方法でも変化するなら、トランスミッションが予定されているのを確実にしてください。 実際のトランスミッション時間は以下で説明されるようにランダマイズされます。
o If a home registration expires, cancel any scheduled
advertisements to the mobile node.
o 本国登録が期限が切れるなら、あらゆる予定されている広告をモバイルノードとして中止してください。
The list of prefixes is sent in its entirety in all cases.
すべての場合で接頭語のリストを全体として送ります。
If the home agent has already scheduled the transmission of a Mobile Prefix Advertisement to the mobile node, then the home agent will replace the advertisement with a new one to be sent at the scheduled time.
ホームのエージェントが既にモバイルPrefix Advertisementのトランスミッションのモバイルノードに計画をしたなら、ホームのエージェントは広告を予定されている時に送られる新しいものに取り替えるでしょう。
Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY which offsets from the current time for the scheduled transmission. First calculate the maximum delay for the scheduled Advertisement:
さもなければ、ホームのエージェントは予定されているトランスミッションのための現在の時間から相殺されるRAND_ADV_DELAYに、新鮮な値を計算します。 まず最初に、予定されているAdvertisementのために最大の遅れについて計算してください:
Johnson, et al. Standard Track [Page 103] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[103ページ]のRFC3775移動性サポート
MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
MaxScheduleDelay=分(MaxMobPfxAdvInterval、Preferred Lifetime)
where MaxMobPfxAdvInterval is as defined in Section 12. Then compute the final delay for the advertisement:
MaxMobPfxAdvIntervalがセクション12で定義されるようにあるところで。 次に、広告のために最終的な遅れを計算してください:
RAND_ADV_DELAY = MinMobPfxAdvInterval +
(rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
底ならし革_ADV_遅れはMinMobPfxAdvInterval+と等しいです。(底ならし革()%腹筋(MaxScheduleDelay--MinMobPfxAdvInterval))
Here rand() returns a random integer value in the range of 0 to the maximum possible integer value. This computation is expected to alleviate bursts of advertisements when prefix information changes. In addition, a home agent MAY further reduce the rate of packet transmission by further delaying individual advertisements, when necessary to avoid overwhelming local network resources. The home agent SHOULD periodically continue to retransmit an unsolicited Advertisement to the mobile node, until it is acknowledged by the receipt of a Mobile Prefix Solicitation from the mobile node.
ここで、底ならし革()は0の範囲で最大の可能な整数値に無作為の整数値を返します。 接頭語情報が変化するとき、この計算が広告の炸裂を軽減すると予想されます。 さらに、ホームのエージェントはさらに個々の広告を遅らせることによって、パケット伝送のレートをさらに低下させるかもしれません、圧倒的な企業内情報通信網リソースを避けるのに必要であるときに。 ホームのエージェントSHOULDは、定期的にモバイルノードに求められていないAdvertisementを再送し続けています、それがモバイルノードからモバイルPrefix Solicitationの領収書で承認されるまで。
The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12) before the first retransmission and double the retransmission wait time for every succeeding retransmission until a maximum number of PREFIX_ADV_RETRIES attempts (see Section 12) has been tried. If the mobile node's bindings expire before the matching Binding Update has been received, then the home agent MUST NOT attempt any more retransmissions, even if not all PREFIX_ADV_RETRIES have been retransmitted. In the meantime, if the mobile node sends another Binding Update without returning home, then the home agent SHOULD begin transmitting the unsolicited Advertisement again.
ホームのエージェントは最初の「再-トランスミッション」の前と続くあらゆる「再-トランスミッション」のための「再-トランスミッション」待ち時間の最大数のPREFIX_ADV_RETRIES試み(セクション12を見る)が試みられるまでの二重の間の待ちPREFIX_ADV_TIMEOUT(セクション12を見る)がそうしなければなりません。 合っているBinding Updateを受け取る前にモバイルノードの結合が期限が切れるなら、ホームのエージェントはそれ以上の「再-トランスミッション」を試みてはいけません、すべてのPREFIX_ADV_RETRIESが再送されるというわけではなくても。 差し当たり、モバイルノードが家に帰らないで別のBinding Updateを送るなら、ホームのエージェントSHOULDは再び求められていないAdvertisementを伝え始めます。
If some condition, as described above, occurs on the home link and causes another Prefix Advertisement to be sent to the mobile node, before the mobile node acknowledges a previous transmission, the home agent SHOULD combine any Prefix Information options in the unacknowledged Mobile Prefix Advertisement into a new Advertisement. The home agent then discards the old Advertisement.
上で説明される何らかの状態がホームのリンクと原因に現れるなら、モバイルノードの前のモバイルノードに送られるべき別のPrefix Advertisementは前のトランスミッションを承諾して、ホームのエージェントSHOULDは不承認のモバイルPrefix AdvertisementのどんなPrefix情報オプションも新しいAdvertisementに結合します。 そして、ホームのエージェントは古いAdvertisementを捨てます。
10.6.3. Sending Advertisements
10.6.3. 送付広告
When sending a Mobile Prefix Advertisement to the mobile node, the home agent MUST construct the packet as follows:
モバイルPrefix Advertisementをモバイルノードに送るとき、ホームのエージェントは以下のパケットを組み立てなければなりません:
o The Source Address in the packet's IPv6 header MUST be set to the
home agent's IP address to which the mobile node addressed its
current home registration or its default global home agent address
if no binding exists.
o パケットのIPv6ヘッダーのSource Addressは縛らないことが存在しているならモバイルノードが現在の本国登録かそのデフォルトがグローバルなホームエージェントアドレスであると扱ったホームのエージェントのIPアドレスに用意ができなければなりません。
Johnson, et al. Standard Track [Page 104] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[104ページ]のRFC3775移動性サポート
o If the advertisement was solicited, it MUST be destined to the
source address of the solicitation. If it was triggered by prefix
changes or renumbering, the advertisement's destination will be
the mobile node's home address in the binding which triggered the
rule.
o 広告が請求されたなら、懇願のソースアドレスにそれを運命づけなければなりません。 接頭語変化によって引き起こされたか、または番号を付け替えていたなら、広告の目的地は規則の引き金となった結合でモバイルノードのホームアドレスになるでしょう。
o A type 2 routing header MUST be included with the mobile node's
home address.
o モバイルノードのホームアドレスでタイプ2ルーティングヘッダーを含まなければなりません。
o IPsec headers MUST be supported and SHOULD be used.
o ヘッダーを支えなければならないIPsecとSHOULD、使用されてください。
o The home agent MUST send the packet as it would any other unicast
IPv6 packet that it originates.
o ホームのエージェントはそれは溯源するいかなる他のユニキャストIPv6パケットも送るようにパケットを送らなければなりません。
o Set the Managed Address Configuration (M) flag if the
corresponding flag has been set in any of the Router
Advertisements from which the prefix information has been learned
(including the ones sent by this home agent).
o 対応する旗が接頭語情報が学習されたRouter Advertisementsのどれかに設定されたなら(このホームのエージェントによって送られたものを含んでいて)、Managed Address Configuration(M)旗を設定してください。
o Set the Other Stateful Configuration (O) flag if the corresponding
flag has been set in any of the Router Advertisements from which
the prefix information has been learned (including the ones sent
by this home agent).
o 対応する旗が接頭語情報が学習されたRouter Advertisementsのどれかに設定されたなら(このホームのエージェントによって送られたものを含んでいて)、Other Stateful Configuration(O)旗を設定してください。
10.6.4. Lifetimes for Changed Prefixes
10.6.4. 変えられた接頭語のための生涯
As described in Section 10.3.1, the lifetime returned by the home agent in a Binding Acknowledgement MUST not be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address. This limit on the binding lifetime serves to prohibit use of a mobile node's home address after it becomes invalid.
セクション10.3.1で説明されるように、Binding Acknowledgementでホームのエージェントによって返された寿命は残っている有効な生涯よりモバイルノードのホームアドレスのサブネット接頭語が長いはずがありません。 拘束力がある生涯におけるこの限界は、無効になった後にモバイルノードのホームアドレスの使用を禁止するのに役立ちます。
11. Mobile Node Operation
11. モバイルノード手術
11.1. Conceptual Data Structures
11.1. 概念的なデータ構造
Each mobile node MUST maintain a Binding Update List.
それぞれのモバイルノードはBinding Update Listを維持しなければなりません。
The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. The Binding Update List includes all bindings sent by the mobile node either to its home agent or correspondent nodes. It also contains Binding Updates which are waiting for the completion of the return routability procedure before they can be sent. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. The Binding Update List MAY be implemented in
Binding Update Listは結合の寿命がまだ期限が切れていないこのモバイルノードによって送られた各Binding Updateのための情報を記録します。 Binding Update Listはそのホームのエージェントか通信員ノードにモバイルノードによって送られたすべての結合を含めます。 また、それは彼らを送ることができる前にリターンroutability手順の完成を待っているBinding Updatesを含んでいます。 しかしながら、同じ送付先アドレスに送られた複数のBinding Updatesに関して、Binding Update Listはその目的地に送られた最新のBinding Update(すなわち、最も大きいSequence Number値がある)だけを含んでいます。 Binding Update Listは中で実装されるかもしれません。
Johnson, et al. Standard Track [Page 105] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[105ページ]のRFC3775移動性サポート
any manner consistent with the external behavior described in this document.
本書では説明される外部の振舞いと一致したどんな方法。
Each Binding Update List entry conceptually contains the following fields:
それぞれのBinding Update Listエントリーは概念的に以下の分野を含んでいます:
o The IP address of the node to which a Binding Update was sent.
o Binding Updateが送られたノードのIPアドレス。
o The home address for which that Binding Update was sent.
o そのBinding Updateが送られたホームアドレス。
o The care-of address sent in that Binding Update. This value is
necessary for the mobile node to determine if it has sent a
Binding Update while giving its new care-of address to this
destination after changing its care-of address.
o 注意、-、アドレスはそのBinding Updateを送りました。 モバイルノードが、与えている間、Binding Updateを送るならそれが新しいことを決定するのにこの値が必要である、注意、-、変化した後のこの目的地へのアドレス、それ、注意、-、アドレス
o The initial value of the Lifetime field sent in that Binding
Update.
o Lifetime分野の初期の値はそのBinding Updateを送りました。
o The remaining lifetime of that binding. This lifetime is
initialized from the Lifetime value sent in the Binding Update and
is decremented until it reaches zero, at which time this entry
MUST be deleted from the Binding Update List.
o その結合の残っている生涯。 この寿命は、どの時にBinding Update Listからこのエントリーを削除しなければならないかときゼロに達するまでBinding Updateで送られたLifetime値から初期化されて、減少します。
o The maximum value of the Sequence Number field sent in previous
Binding Updates to this destination. The Sequence Number field is
16 bits long and all comparisons between Sequence Number values
MUST be performed modulo 2**16 (see Section 9.5.1).
o Sequence Number分野の最大値は前のBinding Updatesをこの目的地に送りました。 Sequence Number分野は長さ16ビットです、そして、Sequence Number値でのすべての比較が実行された法2**16であるに違いありません(セクション9.5.1を見てください)。
o The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting restriction
for sending Binding Updates.
o Binding Updateが最後であった時はこの目的地に発信しました、送付Binding Updatesのために制限を制限するレートを実装するのが必要であるので。
o The state of any retransmissions needed for this Binding Update.
This state includes the time remaining until the next
retransmission attempt for the Binding Update and the current
state of the exponential back-off mechanism for retransmissions.
o このBinding Updateに必要であるどんな「再-トランスミッション」の状態。 この州は、Binding Updateのための次の「再-トランスミッション」試みと「再-トランスミッション」における指数の下に後部メカニズムの現状まで残りながら、時間を含めます。
o A flag specifying whether or not future Binding Updates should be
sent to this destination. The mobile node sets this flag in the
Binding Update List entry when it receives an ICMP Parameter
Problem, Code 1, error message in response to a return routability
message or Binding Update sent to that destination, as described
in Section 11.3.5.
o 将来のBinding Updatesがこの目的地に送られるべきであるかどうか指定する旗。 ICMP Parameter Problemを受けるとき、モバイルノードはBinding Update Listエントリーにこの旗をはめ込みます、Code1、その目的地に送られたリターンroutabilityメッセージかBinding Updateに対応したエラーメッセージ、セクション11.3.5で説明されるように。
The Binding Update List is used to determine whether a particular packet is sent directly to the correspondent node or tunneled via the home agent (see Section 11.3.1).
Binding Update Listは、特定のパケットに直接通信員ノードに送るか、またはホームのエージェントを通してトンネルを堀るかを(セクション11.3.1を見てください)決定するのに使用されます。
Johnson, et al. Standard Track [Page 106] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[106ページ]のRFC3775移動性サポート
The Binding Update list also conceptually contains the following data related to running the return routability procedure. This data is relevant only for Binding Updates sent to correspondent nodes.
また、Binding Updateリストは概念的にリターンroutability手順を実行すると関連する以下のデータを含んでいます。 通信員ノードに送られたBinding Updatesだけにおいて、このデータは関連しています。
o The time at which a Home Test Init or Care-of Test Init message
was last sent to this destination, as needed to implement the rate
limiting restriction for the return routability procedure.
o または、時間、どのaホームTest Init、Care、-、最後にTest Initメッセージをこの目的地に送りました、リターンroutability手順のための制限を制限するレートを実装するのが必要であるので。
o The state of any retransmissions needed for this return
routability procedure. This state includes the time remaining
until the next retransmission attempt and the current state of the
exponential back-off mechanism for retransmissions.
o このリターンroutability手順に必要であるどんな「再-トランスミッション」の状態。 この州は、「再-トランスミッション」における指数の下に後部メカニズムの次の「再-トランスミッション」試みと現状まで残りながら、時間を含めます。
o Cookie values used in the Home Test Init and Care-of Test Init
messages.
o そして、クッキー値がホームにTest Initを使用した、Care、-、Test Initメッセージ。
o Home and care-of keygen tokens received from the correspondent
node.
o そして、家、注意、-、keygenトークンは通信員ノードから受信されました。
o Home and care-of nonce indices received from the correspondent
node.
o そして、家、注意、-、一回だけのインデックスリストは通信員ノードから受信されました。
o The time at which each of the tokens and nonces were received from
the correspondent node, as needed to implement reuse while moving.
o 移行している間の再利用を実装するのが必要であるのでそれぞれのトークンと一回だけが通信員ノードから受け取られた時。
11.2. Processing Mobility Headers
11.2. 処理移動性ヘッダー
All IPv6 mobile nodes MUST observe the rules described in Section 9.2 when processing Mobility Headers.
すべてのIPv6のモバイルノードがMobility Headersを処理するときセクション9.2で説明された規則を守らなければなりません。
11.3. Packet Processing
11.3. パケット処理
11.3.1. Sending Packets While Away from Home
11.3.1. ホームから離れている間、パケットを送ります。
While a mobile node is away from home, it continues to use its home address, as well as also using one or more care-of addresses. When sending a packet while away from home, a mobile node MAY choose among these in selecting the address that it will use as the source of the packet, as follows:
モバイルノードが家にいないのですが、ホームアドレスを使用して、また、1つを使用するか、以上を使用し続けている、注意、-、アドレス。 ホームから離れている間パケットを送るとき、モバイルノードはこれらの中でそれがパケットの源として使用するアドレスを選択する際に選ぶかもしれません、以下の通りです:
o Protocols layered over IP will generally treat the mobile node's
home address as its IP address for most packets. For packets sent
that are part of transport-level connections established while the
mobile node was at home, the mobile node MUST use its home
address. Likewise, for packets sent that are part of transport-
level connections that the mobile node may still be using after
moving to a new location, the mobile node SHOULD use its home
address in this way. If a binding exists, the mobile node SHOULD
o 一般に、IPの上で層にされたプロトコルはほとんどのパケットのためのIPアドレスとしてモバイルノードのホームアドレスを扱うでしょう。 送られたモバイルノードがホームにありましたが、確立された輸送レベル接続の一部であるパケットのために、モバイルノードはホームアドレスを使用しなければなりません。 同様に、送られたモバイルノードが新しい位置に移行した後にまだ使用しているかもしれない輸送の平らな接続の一部であるパケットのために、モバイルノードSHOULDはこのようにホームアドレスを使用します。 aであるなら、結合は存在していて、モバイルノードはSHOULDです。
Johnson, et al. Standard Track [Page 107] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[107ページ]のRFC3775移動性サポート
send the packets directly to the correspondent node. Otherwise,
if a binding does not exist, the mobile node MUST use reverse
tunneling.
直接通信員ノードにパケットを送ってください。 さもなければ、結合が存在していないなら、モバイルノードは逆のトンネリングを使用しなければなりません。
o The mobile node MAY choose to directly use one of its care-of
addresses as the source of the packet, not requiring the use of a
Home Address option in the packet. This is particularly useful
for short-term communication that may easily be retried if it
fails. Using the mobile node's care-of address as the source for
such queries will generally have a lower overhead than using the
mobile node's home address, since no extra options need be used in
either the query or its reply. Such packets can be routed
normally, directly between their source and destination without
relying on Mobile IPv6. If application running on the mobile node
has no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile
node should not use its care-of address as the source of the
packet in this way.
o 直接1つを使用する、モバイルノードが、選ぶかもしれないそれ、注意、-、パケットでホームAddressオプションの使用を必要とするのではなく、パケットの源として、扱います。 これは特に失敗するなら容易に再試行されるかもしれない短期的なコミュニケーションの役に立ちます。 モバイルノードのものを使用する、注意、-、そのような質問のためのソースとしてのアドレスには、一般に、モバイルノードのホームアドレスを使用するより低いオーバーヘッドがあるでしょう、どんな付加的なオプションも質問かその回答のどちらかに使用される必要はないので。 モバイルIPv6を当てにしないで、通常、それらのソースと目的地の直接間にそのようなパケットを発送できます。 しかしながら、この一般型のコミュニケーションの中で発作をコミュニケーションに送る場合、モバイルノードが送るべきであるという特定の知識がないのがモバイルノードでのアプリケーション実行で使用しない、それ、注意、-、このようにパケットの源としてのアドレス。
The choice of the most efficient communications method is
application specific, and outside the scope of this specification.
The APIs necessary for controlling the choice are also out of
scope.
アプリケーション特有であり、この仕様の範囲の外で最も効率的なコミュニケーションメソッドの選択。 範囲のも外に選択を制御するのに必要なAPIがあります。
o While not at its home link, the mobile node MUST NOT use the Home
Address destination option when communicating with link-local or
site-local peers, if the scope of the home address is larger than
the scope of the peer's address.
o リンク地方の、または、サイト地元の同輩とコミュニケートするとき、どんなホームのリンクにもない間、モバイルノードはホームAddress目的地オプションを使用してはいけません、ホームアドレスの範囲が同輩のアドレスの範囲より大きいなら。
Similarly, the mobile node MUST NOT use the Home Address
destination option for IPv6 Neighbor Discovery [12] packets.
同様に、モバイルノードはIPv6 Neighborディスカバリー[12]パケットにホームAddress目的地オプションを使用してはいけません。
Detailed operation of these cases is described later in this section and also discussed in [31].
これらのケースの詳細な操作について、後でこのセクションで説明されて、また、[31]で議論します。
For packets sent by a mobile node while it is at home, no special Mobile IPv6 processing is required. Likewise, if the mobile node uses any address other than one of its home addresses as the source of a packet sent while away from home, no special Mobile IPv6 processing is required. In either case, the packet is simply addressed and transmitted in the same way as any normal IPv6 packet.
それがホームにある間にモバイルノードで送られたパケットに関しては、どんな特別なモバイルIPv6処理も必要ではありません。 同様に、モバイルノードがいずれかも使用するなら、どんな特別なモバイルIPv6処理もホームから遠くで必要でない間、パケットの源としてのホームアドレスの1つ以外のアドレスが発信しました。 どちらの場合ではも、どんな正常なIPv6パケットとも同様に、パケットは、単に扱われて、伝えられます。
For packets sent by the mobile node sent while away from home using the mobile node's home address as the source, special Mobile IPv6 processing of the packet is required. This can be done in the following two ways:
モバイルによって送られたパケットに関しては、パケットの特別なモバイルIPv6処理がソースとしてモバイルノードのホームアドレスを使用するホームから遠くで必要である間、ノードは発信しました。 以下の2つの方法でこれができます:
Johnson, et al. Standard Track [Page 108] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[108ページ]のRFC3775移動性サポート
Route Optimization
経路最適化
This manner of delivering packets does not require going through the home network, and typically will enable faster and more reliable transmission.
パケットを提供するこの方法は、ホームネットワークに直面するのが必要でなく、より速くて、より信頼できるトランスミッションを通常可能にするでしょう。
The mobile node needs to ensure that a Binding Cache entry exists for its home address so that the correspondent node can process the packet (Section 9.3.1 specifies the rules for Home Address Destination Option Processing at a correspondent node). The mobile node SHOULD examine its Binding Update List for an entry which fulfills the following conditions:
モバイルノードは、通信員ノードがパケットを処理できて(セクション9.3.1は通信員ノードでホームAddress Destination Option Processingに規則を指定します)、Binding Cacheエントリーがホームアドレスのために存在するのを保証する必要があります。 モバイルノードSHOULDは以下の条件を達成するエントリーがないかどうかBinding Update Listを調べます:
* The Source Address field of the packet being sent is equal to the
home address in the entry.
* 送られるパケットのSource Address分野はエントリーにおけるホームアドレスと等しいです。
* The Destination Address field of the packet being sent is equal to
the address of the correspondent node in the entry.
* 送られるパケットのDestination Address分野はエントリーにおける通信員ノードのアドレスと等しいです。
* One of the current care-of addresses of the mobile node appears as
the care-of address in the entry.
* 電流の1つ、注意、-、モバイルノードのアドレスが現れる、注意、-、エントリーにおけるアドレス。
* The entry indicates that a binding has been successfully created.
* エントリーは、首尾よく結合を作成してあるのを示します。
* The remaining lifetime of the binding is greater than zero.
* 結合の残っている寿命はゼロ以上です。
When these conditions are met, the mobile node knows that the correspondent node has a suitable Binding Cache entry.
これらの条件が満たされるとき、モバイルノードは、通信員ノードには適当なBinding Cacheエントリーがあるのを知っています。
A mobile node SHOULD arrange to supply the home address in a Home Address option, and MUST set the IPv6 header's Source Address field to the care-of address which the mobile node has registered to be used with this correspondent node. The correspondent node will then use the address supplied in the Home Address option to serve the function traditionally done by the Source IP address in the IPv6 header. The mobile node's home address is then supplied to higher protocol layers and applications.
SHOULDがホームAddressオプションにおけるホームアドレスを提供するように手配して、IPv6ヘッダーのSource Address分野を設定しなければならないモバイルノード、注意、-、モバイルノードがこの通信員ノードと共に使用されるために登録したアドレス。 そして、通信員ノードはホームAddressオプションでIPv6ヘッダーのSource IPアドレスによって伝統的に行われた機能に供給されたアドレスを使用するでしょう。 そして、モバイルノードのホームアドレスをより高いプロトコル層とアプリケーションに提供します。
Specifically:
明確に:
* Construct the packet using the mobile node's home address as the
packet's Source Address, in the same way as if the mobile node
were at home. This includes the calculation of upper layer
checksums using the home address as the value of the source.
* パケットのSource Addressとしてモバイルノードのホームアドレスを使用して、パケットを組み立ててください、モバイルノードがホームにある同様に。 これは、ソースの値としてホームアドレスを使用することで上側の層のチェックサムの計算を含んでいます。
* Insert a Home Address option into the packet with the Home Address
field copied from the original value of the Source Address field
in the packet.
* ホームAddress分野がパケットのSource Address分野の元の値からコピーされている状態で、ホームAddressオプションをパケットに挿入してください。
Johnson, et al. Standard Track [Page 109] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[109ページ]のRFC3775移動性サポート
* Change the Source Address field in the packet's IPv6 header to one
of the mobile node's care-of addresses. This will typically be
the mobile node's current primary care-of address, but MUST be an
address assigned to the interface on the link being used.
* 1つへのパケットのIPv6ヘッダーのSource Address分野を変える、モバイルノードのもの、注意、-、アドレス これが通常ある、モバイルノードの電流、初期医療、-、アドレス、使用されるリンクの上のインタフェースに割り当てられたアドレスでなければなりません。
By using the care-of address as the Source Address in the IPv6 header, with the mobile node's home address instead in the Home Address option, the packet will be able to safely pass through any router implementing ingress filtering [26].
使用する、注意、-、IPv6ヘッダーのSource Addressとしての代わりにホームAddressオプションにおけるモバイルノードのホームアドレスがあるアドレス、パケットは安全に[26]をフィルターにかけるイングレスを実装するどんなルータも通り抜けることができるでしょう。
Reverse Tunneling
トンネリングを逆にしてください。
This is the mechanism which tunnels the packets via the home
agent. It is not as efficient as the above mechanism, but is
needed if there is no binding yet with the correspondent node.
これはホームのエージェントを通してパケットにトンネルを堀るメカニズムです。 それが、上のメカニズムほど効率的ではありませんが、まだ通信員ノードをもって縛ってはいけなければ、必要です。
This mechanism is used for packets that have the mobile node's
home address as the Source Address in the IPv6 header, or with
multicast control protocol packets as described in Section 11.3.4.
Specifically:
このメカニズムはSource AddressとしてIPv6ヘッダーにモバイルノードのホームアドレスを持っているパケット、またはセクション11.3.4で説明されるマルチキャスト制御プロトコルパケットと共に使用されます。 明確に:
* The packet is sent to the home agent using IPv6 encapsulation
[15].
* IPv6カプセル化[15]を使用することでホームのエージェントにパケットを送ります。
* The Source Address in the tunnel packet is the primary care-of
address as registered with the home agent.
* トンネルパケットのSource Addressがそうである、初期医療、-、ホームのエージェントとの登録されるとしてのアドレス。
* The Destination Address in the tunnel packet is the home
agent's address.
* トンネルパケットのDestination Addressはホームのエージェントのアドレスです。
Then, the home agent will pass the encapsulated packet to the
correspondent node.
そして、ホームのエージェントはカプセル化されたパケットを通信員ノードに通過するでしょう。
11.3.2. Interaction with Outbound IPsec Processing
11.3.2. 外国行きのIPsec処理との相互作用
This section sketches the interaction between outbound Mobile IPv6 processing and outbound IP Security (IPsec) processing for packets sent by a mobile node while away from home. Any specific implementation MAY use algorithms and data structures other than those suggested here, but its processing MUST be consistent with the effect of the operation described here and with the relevant IPsec specifications. In the steps described below, it is assumed that IPsec is being used in transport mode [4] and that the mobile node is using its home address as the source for the packet (from the point of view of higher protocol layers or applications, as described in Section 11.3.1):
このセクションはホームから離れていますが、モバイルノードによって送られたパケットのための外国行きのモバイルIPv6処理と外国行きのIP Security(IPsec)処理との相互作用についてスケッチします。 どんな特定の実装もアルゴリズムとここに示されたもの以外のデータ構造を使用するかもしれませんが、処理はここで説明される操作の効果と関連IPsec仕様と一致しているに違いありません。 以下で説明されたステップでは、IPsecが交通機関[4]で使用されていて、モバイルノードがパケットにソースとしてホームアドレスを使用している(より高いことの観点から、層かアプリケーションについて議定書の中で述べてください、セクション11.3.1で説明されるように)と思われます:
Johnson, et al. Standard Track [Page 110] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[110ページ]のRFC3775移動性サポート
o The packet is created by higher layer protocols and applications
(e.g., by TCP) as if the mobile node were at home and Mobile IPv6
were not being used.
o まるでモバイルノードがホームにあるかのように、より高い層のプロトコルとアプリケーション(例えば、TCPによる)でパケットは作成されました、そして、モバイルIPv6は使用されていませんでした。
o Determine the outgoing interface for the packet. (Note that the
selection between reverse tunneling and route optimization may
imply different interfaces, particularly if tunnels are considered
interfaces as well.)
o パケットのために外向的なインタフェースを決定してください。 (逆のトンネリングと経路最適化の間の選択が異なったインタフェースを含意するかもしれないことに注意してください、特にトンネルがまた、インタフェースであると考えられるなら。)
o As part of outbound packet processing in IP, the packet is
compared against the IPsec security policy database to determine
what processing is required for the packet [4].
o IPにおける外国行きのパケット処理の一部として、パケットは、どんな処理がパケット[4]に必要であるかを決定するためにIPsec安全保障政策データベースに対して比較されます。
o If IPsec processing is required, the packet is either mapped to an
existing Security Association (or SA bundle), or a new SA (or SA
bundle) is created for the packet, according to the procedures
defined for IPsec.
o IPsec処理が必要であるなら、パケットが既存のSecurity Associationに写像されるか(SAは荷物をまとめます)、または新しいSA(SAは荷物をまとめる)はパケットのために作成されます、IPsecのために定義された手順によると。
o Since the mobile node is away from home, the mobile is either
using reverse tunneling or route optimization to reach the
correspondent node.
o モバイルノードが家にいないので、モバイルは通信員ノードに達するのに逆のトンネリングか経路最適化を使用しています。
If reverse tunneling is used, the packet is constructed in the
normal manner and then tunneled through the home agent.
逆のトンネリングが使用されているなら、パケットは、正常な方法で組み立てられて、ホームのエージェントを通してトンネルを堀られます。
If route optimization is in use, the mobile node inserts a Home
Address destination option into the packet, replacing the Source
Address in the packet's IP header with the care-of address used
with this correspondent node, as described in Section 11.3.1. The
Destination Options header in which the Home Address destination
option is inserted MUST appear in the packet after the routing
header, if present, and before the IPsec (AH [5] or ESP [6])
header, so that the Home Address destination option is processed
by the destination node before the IPsec header is processed.
最適化が使用、パケットのIPヘッダーでSource Addressを取り替えて、ホームAddressの目的地がパケットにゆだねるモバイルノード差し込みにあるルートである、注意、-、アドレスはこの通信員ノードと共にセクション11.3で.1に説明されるように使用しました。 ホームAddress目的地オプションが挿入されるDestination Optionsヘッダーはパケットで存在していて、IPsecの前のルーティングヘッダーの後に見えなければなりません。(AH[5]か超能力[6])ヘッダー、ホームAddress目的地オプションが以前目的地ノードによって処理されるように、IPsecヘッダーは処理されます。
Finally, once the packet is fully assembled, the necessary IPsec
authentication (and encryption, if required) processing is
performed on the packet, initializing the Authentication Data in
the IPsec header.
最終的に、一度、パケットは完全に組み立てられます、必要なIPsec認証、(そして、暗号化、必要なら)、処理はパケットに実行されます、IPsecヘッダーでAuthentication Dataを初期化して。
RFC 2402 treatment of destination options is extended as follows.
The AH authentication data MUST be calculated as if the following
were true:
目的地オプションのRFC2402処理は以下の通り申し上げられます。 まるで以下が本当であるかのようにAH認証データについて計算しなければなりません:
* the IPv6 source address in the IPv6 header contains the mobile
node's home address,
* IPv6ヘッダーのIPv6ソースアドレスはモバイルノードのホームアドレスを含んでいます。
Johnson, et al. Standard Track [Page 111] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[111ページ]のRFC3775移動性サポート
* the Home Address field of the Home Address destination option
(Section 6.3) contains the new care-of address.
* ホームAddress目的地オプション(セクション6.3)のホームAddress分野が新しさを含んでいる、注意、-、アドレス。
o This allows, but does not require, the receiver of the packet
containing a Home Address destination option to exchange the two
fields of the incoming packet to reach the above situation,
simplifying processing for all subsequent packet headers.
However, such an exchange is not required, as long as the result
of the authentication calculation remains the same.
o 許容しますが、上の状況に達するように入って来るパケットの2つの野原を交換するホームAddress目的地オプションを含むパケットの受信機、簡素化がすべてのその後のパケットのヘッダーのために処理されて、これは必要ではありません。 しかしながら、認証計算の結果が同じままで残っている限り、そのような交換は必要ではありません。
When an automated key management protocol is used to create new security associations for a peer, it is important to ensure that the peer can send the key management protocol packets to the mobile node. This may not be possible if the peer is the home agent of the mobile node and the purpose of the security associations would be to send a Binding Update to the home agent. Packets addressed to the home address of the mobile node cannot be used before the Binding Update has been processed. For the default case of using IKE [9] as the automated key management protocol, such problems can be avoided by the following requirements when communicating with its home agent:
自動化されたかぎ管理プロトコルが同輩のために新しいセキュリティ協会を創設するのに使用されるとき、同輩がかぎ管理プロトコルパケットをモバイルノードに送ることができるのを保証するのは重要です。 これは同輩がモバイルノードのホームのエージェントであるなら可能でないかもしれません、そして、セキュリティ協会の目的はホームのエージェントにBinding Updateを送るだろうことです。 Binding Updateが処理される前にモバイルノードに関するホームアドレスに扱われたパケットは使用できません。 ホームのエージェントとコミュニケートするとき、[9] 自動化されたかぎ管理が議定書を作るのでIKEを使用する不履行格において、以下の要件はそのような問題を避けることができます:
o When the mobile node is away from home, it MUST use its care-of
address as the Source Address of all packets it sends as part of
the key management protocol (without use of Mobile IPv6 for these
packets, as suggested in Section 11.3.1).
o モバイルノードが家にいないときに、使用しなければならない、それ、注意、-、それがかぎ管理の一部として送るすべてのパケットのSource Addressが議定書を作るとき(モバイルIPv6のこれらのパケットの使用セクション11.3.1で示されるように)、扱います。
o In addition, for all security associations bound to the mobile
node's home address established by IKE, the mobile node MUST
include an ISAKMP Identification Payload [8] in the IKE phase 2
exchange, giving the mobile node's home address as the initiator
of the Security Association [7].
o さらに、IKEによって確立されたモバイルノードのホームアドレスに縛られたすべてのセキュリティ協会に関してモバイルノードは2が交換するIKEフェーズにISAKMP Identification有効搭載量[8]を含まなければなりません、Security Association[7]の創始者としてモバイルノードのホームアドレスを与えて。
The Key Management Mobility Capability (K) bit in Binding Updates and Acknowledgements can be used to avoid the need to rerun IKE upon movements.
動きのときにIKEを再実行する必要性を避けるのにBinding UpdatesとAcknowledgementsのKey Management Mobility Capability(K)ビットを使用できます。
11.3.3. Receiving Packets While Away from Home
11.3.3. ホームから離れている間、パケットを受けます。
While away from home, a mobile node will receive packets addressed to its home address, by one of two methods:
モバイルノードはホームから遠くで2つのメソッドの1つでホームアドレスに扱われたパケットを受けるでしょうが:
o Packets sent by a correspondent node, that does not have a Binding
Cache entry for the mobile node, will be sent to the home address,
captured by the home agent and tunneled to the mobile node.
o 通信員ノードによって送られたパケット、それにはモバイルノードのためのBinding Cacheエントリーがなくて、ホームアドレスに送られて、ホームのエージェントによってキャプチャされて、モバイルノードにトンネルを堀られるでしょう。
o Packets sent by a correspondent node that has a Binding Cache
entry for the mobile node that contains the mobile node's current
care-of address, will be sent by the correspondent node using a
o パケットがそれが含むモバイルノードのためのBinding Cacheエントリーを持っている通信員ノードで送った、モバイルノードの電流、注意、-、アドレス、通信員ノードで、aを使用することで、送るでしょう。
Johnson, et al. Standard Track [Page 112] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[112ページ]のRFC3775移動性サポート
type 2 routing header. The packet will be addressed to the mobile
node's care-of address, with the final hop in the routing header
directing the packet to the mobile node's home address; the
processing of this last hop of the routing header is entirely
internal to the mobile node, since the care-of address and home
address are both addresses within the mobile node.
2ルーティングヘッダーをタイプしてください。 パケットが扱われる、モバイルノードのもの、注意、-、アドレス、決勝で、モバイルノードのホームアドレスにパケットを向けながら、ルーティングヘッダーを跳んでください。 ルーティングヘッダーのこの最後のホップの処理はモバイルノードに完全に内部です、以来注意、-、アドレスとホームアドレスはモバイルノードの中の両方のアドレスです。
For packets received by the first method, the mobile node MUST check that the IPv6 source address of the tunneled packet is the IP address of its home agent. In this method, the mobile node may also send a Binding Update to the original sender of the packet as described in Section 11.7.2 and subject to the rate limiting defined in Section 11.8. The mobile node MUST also process the received packet in the manner defined for IPv6 encapsulation [15], which will result in the encapsulated (inner) packet being processed normally by upper-layer protocols within the mobile node as if it had been addressed (only) to the mobile node's home address.
最初のメソッドで受け取られたパケットがないかどうかモバイルノードは、トンネルを堀られたパケットのIPv6ソースアドレスがホームのエージェントのIPアドレスであることをチェックしなければなりません。 また、このメソッドで、モバイルノードはセクション11.7.2とセクション11.8で定義されたレート制限を条件として説明されるようにパケットの元の送り主にBinding Updateを送るかもしれません。 また、モバイルノードはIPv6カプセル化[15]のために定義された方法で容認されたパケットを処理しなければなりません。カプセル化はまるでそれが(単に)モバイルノードのホームアドレスに扱われたかのように通常、モバイルノードの中の上側の層のプロトコルによって処理されるカプセル化された(内側の)パケットをもたらすでしょう。
For packets received by the second method, the following rules will result in the packet being processed normally by upper-layer protocols within the mobile node as if it had been addressed to the mobile node's home address.
2番目のメソッドで受け取られたパケットに関しては、以下の規則はまるでそれがモバイルノードのホームアドレスに扱われたかのように通常、モバイルノードの中の上側の層のプロトコルによって処理されるパケットをもたらすでしょう。
A node receiving a packet addressed to itself (i.e., one of the node's addresses is in the IPv6 destination field) follows the next header chain of headers and processes them. When it encounters a type 2 routing header during this processing, it performs the following checks. If any of these checks fail, the node MUST silently discard the packet.
それ自体(すなわち、ノードのアドレスの1つがIPv6あて先フィールドにある)に扱われたパケットを受けるノードは、ヘッダーの次のヘッダーチェーンに続いて、彼らを処理します。 この処理の間、タイプ2ルーティングヘッダーに遭遇すると、それは以下のチェックを実行します。 これらのチェックのどれかが失敗するなら、ノードは静かにパケットを捨てなければなりません。
o The length field in the routing header is exactly 2.
o ルーティングヘッダーの長さの分野はまさに2です。
o The segments left field in the routing header is 1 on the wire.
(But implementations may process the routing header so that the
value may become 0 after the routing header has been processed,
but before the rest of the packet is processed.)
o ルーティングヘッダーのセグメントレフトはワイヤの上の1です。 (しかし、実装はルーティングヘッダーが処理された後にもかかわらず、パケットの残りが処理される前を除いて、値が0になることができるように、ルーティングヘッダーを処理するかもしれません。)
o The Home Address field in the routing header is one of the node's
home addresses, if the segments left field was 1. Thus, in
particular the address field is required to be a unicast routable
address.
o ルーティングヘッダーのホームAddress分野はノードのホームアドレスの1つです、セグメントレフトが1であったなら。 したがって、アドレス・フィールドが、ユニキャスト発送可能アドレスになるのに特に、必要です。
Once the above checks have been performed, the node swaps the IPv6 destination field with the Home Address field in the routing header, decrements segments left by one from the value it had on the wire, and resubmits the packet to IP for processing the next header.
Once the above checks have been performed, the node swaps the IPv6 destination field with the Home Address field in the routing header, decrements segments left by one from the value it had on the wire, and resubmits the packet to IP for processing the next header.
Johnson, et al. Standard Track [Page 113] RFC 3775 Mobility Support in IPv6 June 2004
Johnson, et al. Standard Track [Page 113] RFC 3775 Mobility Support in IPv6 June 2004
Conceptually, this follows the same model as in RFC 2460. However, in the case of type 2 routing header this can be simplified since it is known that the packet will not be forwarded to a different node.
Conceptually, this follows the same model as in RFC 2460. However, in the case of type 2 routing header this can be simplified since it is known that the packet will not be forwarded to a different node.
The definition of AH requires the sender to calculate the AH integrity check value of a routing header in the same way it appears in the receiver after it has processed the header. Since IPsec headers follow the routing header, any IPsec processing will operate on the packet with the home address in the IP destination field and segments left being zero. Thus, the AH calculations at the sender and receiver will have an identical view of the packet.
The definition of AH requires the sender to calculate the AH integrity check value of a routing header in the same way it appears in the receiver after it has processed the header. Since IPsec headers follow the routing header, any IPsec processing will operate on the packet with the home address in the IP destination field and segments left being zero. Thus, the AH calculations at the sender and receiver will have an identical view of the packet.
11.3.4. Routing Multicast Packets
11.3.4. Routing Multicast Packets
A mobile node that is connected to its home link functions in the same way as any other (stationary) node. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. Therefore, this section describes the behavior of a mobile node that is not on its home link.
A mobile node that is connected to its home link functions in the same way as any other (stationary) node. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. Therefore, this section describes the behavior of a mobile node that is not on its home link.
In order to receive packets sent to some multicast group, a mobile node must join that multicast group. One method, in which a mobile node MAY join the group, is via a (local) multicast router on the foreign link being visited. In this case, the mobile node MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD packets [17].
In order to receive packets sent to some multicast group, a mobile node must join that multicast group. One method, in which a mobile node MAY join the group, is via a (local) multicast router on the foreign link being visited. In this case, the mobile node MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD packets [17].
Alternatively, a mobile node MAY join multicast groups via a bi- directional tunnel to its home agent. The mobile node tunnels its multicast group membership control packets (such as those defined in [17] or in [37]) to its home agent, and the home agent forwards multicast packets down the tunnel to the mobile node. A mobile node MUST NOT tunnel multicast group membership control packets until (1) the mobile node has a binding in place at the home agent, and (2) the latter sends at least one multicast group membership control packet via the tunnel. Once this condition is true, the mobile node SHOULD assume it does not change as long as the binding does not expire.
Alternatively, a mobile node MAY join multicast groups via a bi- directional tunnel to its home agent. The mobile node tunnels its multicast group membership control packets (such as those defined in [17] or in [37]) to its home agent, and the home agent forwards multicast packets down the tunnel to the mobile node. A mobile node MUST NOT tunnel multicast group membership control packets until (1) the mobile node has a binding in place at the home agent, and (2) the latter sends at least one multicast group membership control packet via the tunnel. Once this condition is true, the mobile node SHOULD assume it does not change as long as the binding does not expire.
A mobile node that wishes to send packets to a multicast group also has two options:
A mobile node that wishes to send packets to a multicast group also has two options:
1. Send directly on the foreign link being visited.
1. Send directly on the foreign link being visited.
The application is aware of the care-of address and uses it as a
source address for multicast traffic, just like it would use a
stationary address. The mobile node MUST NOT use Home Address
destination option in such traffic.
The application is aware of the care-of address and uses it as a source address for multicast traffic, just like it would use a stationary address. The mobile node MUST NOT use Home Address destination option in such traffic.
Johnson, et al. Standard Track [Page 114] RFC 3775 Mobility Support in IPv6 June 2004
Johnson, et al. Standard Track [Page 114] RFC 3775 Mobility Support in IPv6 June 2004
2. Send via a tunnel to its home agent.
2. Send via a tunnel to its home agent.
Because multicast routing in general depends upon the Source
Address used in the IPv6 header of the multicast packet, a mobile
node that tunnels a multicast packet to its home agent MUST use
its home address as the IPv6 Source Address of the inner
multicast packet.
Because multicast routing in general depends upon the Source Address used in the IPv6 header of the multicast packet, a mobile node that tunnels a multicast packet to its home agent MUST use its home address as the IPv6 Source Address of the inner multicast packet.
Note that direct sending from the foreign link is only applicable while the mobile node is at that foreign link. This is because the associated multicast tree is specific to that source location and any change of location and source address will invalidate the source specific tree or branch and the application context of the other multicast group members.
Note that direct sending from the foreign link is only applicable while the mobile node is at that foreign link. This is because the associated multicast tree is specific to that source location and any change of location and source address will invalidate the source specific tree or branch and the application context of the other multicast group members.
This specification does not provide mechanisms to enable such local multicast session to survive hand-off and to seamlessly continue from a new care-of address on each new foreign link. Any such mechanism, developed as an extension to this specification, needs to take into account the impact of fast moving mobile nodes on the Internet multicast routing protocols and their ability to maintain the integrity of source specific multicast trees and branches.
This specification does not provide mechanisms to enable such local multicast session to survive hand-off and to seamlessly continue from a new care-of address on each new foreign link. Any such mechanism, developed as an extension to this specification, needs to take into account the impact of fast moving mobile nodes on the Internet multicast routing protocols and their ability to maintain the integrity of source specific multicast trees and branches.
While the use of bidirectional tunneling can ensure that multicast trees are independent of the mobile nodes movement, in some case such tunneling can have adverse affects. The latency of specific types of multicast applications (such as multicast based discovery protocols) will be affected when the round-trip time between the foreign subnet and the home agent is significant compared to that of the topology to be discovered. In addition, the delivery tree from the home agent in such circumstances relies on unicast encapsulation from the agent to the mobile node. Therefore, bandwidth usage is inefficient compared to the native multicast forwarding in the foreign multicast system.
While the use of bidirectional tunneling can ensure that multicast trees are independent of the mobile nodes movement, in some case such tunneling can have adverse affects. The latency of specific types of multicast applications (such as multicast based discovery protocols) will be affected when the round-trip time between the foreign subnet and the home agent is significant compared to that of the topology to be discovered. In addition, the delivery tree from the home agent in such circumstances relies on unicast encapsulation from the agent to the mobile node. Therefore, bandwidth usage is inefficient compared to the native multicast forwarding in the foreign multicast system.
11.3.5. Receiving ICMP Error Messages
11.3.5. Receiving ICMP Error Messages
Any node that does not recognize the Mobility header will return an ICMP Parameter Problem, Code 1, message to the sender of the packet. If the mobile node receives such an ICMP error message in response to a return routability procedure or Binding Update, it SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination. Such Binding Update List entries SHOULD be removed after a period of time in order to allow for retrying route optimization.
Any node that does not recognize the Mobility header will return an ICMP Parameter Problem, Code 1, message to the sender of the packet. If the mobile node receives such an ICMP error message in response to a return routability procedure or Binding Update, it SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination. Such Binding Update List entries SHOULD be removed after a period of time in order to allow for retrying route optimization.
New Binding Update List entries MUST NOT be created as a result of receiving ICMP error messages.
New Binding Update List entries MUST NOT be created as a result of receiving ICMP error messages.
Johnson, et al. Standard Track [Page 115] RFC 3775 Mobility Support in IPv6 June 2004
Johnson, et al. Standard Track [Page 115] RFC 3775 Mobility Support in IPv6 June 2004
Correspondent nodes that have participated in the return routability procedure MUST implement the ability to correctly process received packets containing a Home Address destination option. Therefore, correctly implemented correspondent nodes should always be able to recognize Home Address options. If a mobile node receives an ICMP Parameter Problem, Code 2, message from some node indicating that it does not support the Home Address option, the mobile node SHOULD log the error and then discard the ICMP message.
Correspondent nodes that have participated in the return routability procedure MUST implement the ability to correctly process received packets containing a Home Address destination option. Therefore, correctly implemented correspondent nodes should always be able to recognize Home Address options. If a mobile node receives an ICMP Parameter Problem, Code 2, message from some node indicating that it does not support the Home Address option, the mobile node SHOULD log the error and then discard the ICMP message.
11.3.6. Receiving Binding Error Messages
11.3.6. Receiving Binding Error Messages
When a mobile node receives a packet containing a Binding Error message, it should first check if the mobile node has a Binding Update List entry for the source of the Binding Error message. If the mobile node does not have such an entry, it MUST ignore the message. This is necessary to prevent a waste of resources on, e.g., return routability procedure due to spoofed Binding Error messages.
When a mobile node receives a packet containing a Binding Error message, it should first check if the mobile node has a Binding Update List entry for the source of the Binding Error message. If the mobile node does not have such an entry, it MUST ignore the message. This is necessary to prevent a waste of resources on, e.g., return routability procedure due to spoofed Binding Error messages.
Otherwise, if the message Status field was 1 (unknown binding for Home Address destination option), the mobile node should perform one of the following two actions:
Otherwise, if the message Status field was 1 (unknown binding for Home Address destination option), the mobile node should perform one of the following two actions:
o If the mobile node has recent upper layer progress information,
which indicates that communications with the correspondent node
are progressing, it MAY ignore the message. This can be done in
order to limit the damage that spoofed Binding Error messages can
cause to ongoing communications.
o If the mobile node has recent upper layer progress information, which indicates that communications with the correspondent node are progressing, it MAY ignore the message. This can be done in order to limit the damage that spoofed Binding Error messages can cause to ongoing communications.
o If the mobile node has no upper layer progress information, it
MUST remove the entry and route further communications through the
home agent. It MAY also optionally start a return routability
procedure (see Section 5.2).
o If the mobile node has no upper layer progress information, it MUST remove the entry and route further communications through the home agent. It MAY also optionally start a return routability procedure (see Section 5.2).
If the message Status field was 2 (unrecognized MH Type value), the mobile node should perform one of the following two actions:
If the message Status field was 2 (unrecognized MH Type value), the mobile node should perform one of the following two actions:
o If the mobile node is not expecting an acknowledgement or response
from the correspondent node, the mobile node SHOULD ignore this
message.
o If the mobile node is not expecting an acknowledgement or response from the correspondent node, the mobile node SHOULD ignore this message.
o Otherwise, the mobile node SHOULD cease the use of any extensions
to this specification. If no extensions had been used, the mobile
node should cease the attempt to use route optimization.
o Otherwise, the mobile node SHOULD cease the use of any extensions to this specification. If no extensions had been used, the mobile node should cease the attempt to use route optimization.
Johnson, et al. Standard Track [Page 116] RFC 3775 Mobility Support in IPv6 June 2004
Johnson, et al. Standard Track [Page 116] RFC 3775 Mobility Support in IPv6 June 2004
11.4. Home Agent and Prefix Management
11.4. Home Agent and Prefix Management
11.4.1. Dynamic Home Agent Address Discovery
11.4.1. Dynamic Home Agent Address Discovery
Sometimes when the mobile node needs to send a Binding Update to its home agent to register its new primary care-of address, as described in Section 11.7.1, the mobile node may not know the address of any router on its home link that can serve as a home agent for it. For example, some nodes on its home link may have been reconfigured while the mobile node has been away from home, such that the router that was operating as the mobile node's home agent has been replaced by a different router serving this role.
Sometimes when the mobile node needs to send a Binding Update to its home agent to register its new primary care-of address, as described in Section 11.7.1, the mobile node may not know the address of any router on its home link that can serve as a home agent for it. For example, some nodes on its home link may have been reconfigured while the mobile node has been away from home, such that the router that was operating as the mobile node's home agent has been replaced by a different router serving this role.
In this case, the mobile node MAY attempt to discover the address of a suitable home agent on its home link. To do so, the mobile node sends an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its home subnet prefix. As described in Section 10.5, the home agent on its home link that receives this Request message will return an ICMP Home Agent Address Discovery Reply message. This message gives the addresses for the home agents operating on the home link.
In this case, the mobile node MAY attempt to discover the address of a suitable home agent on its home link. To do so, the mobile node sends an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [16] for its home subnet prefix. As described in Section 10.5, the home agent on its home link that receives this Request message will return an ICMP Home Agent Address Discovery Reply message. This message gives the addresses for the home agents operating on the home link.
The mobile node, upon receiving this Home Agent Address Discovery Reply message, MAY then send its home registration Binding Update to any of the unicast IP addresses listed in the Home Agent Addresses field in the Reply. For example, the mobile node MAY attempt its home registration to each of these addresses, in turn, until its registration is accepted. The mobile node sends a Binding Update to an address and waits for the matching Binding Acknowledgement, moving on to the next address if there is no response. The mobile node MUST, however, wait at least InitialBindackTimeoutFirstReg seconds (see Section 13) before sending a Binding Update to the next home agent. In trying each of the returned home agent addresses, the mobile node SHOULD try each of them in the order they appear in the Home Agent Addresses field in the received Home Agent Address Discovery Reply message.
The mobile node, upon receiving this Home Agent Address Discovery Reply message, MAY then send its home registration Binding Update to any of the unicast IP addresses listed in the Home Agent Addresses field in the Reply. For example, the mobile node MAY attempt its home registration to each of these addresses, in turn, until its registration is accepted. The mobile node sends a Binding Update to an address and waits for the matching Binding Acknowledgement, moving on to the next address if there is no response. The mobile node MUST, however, wait at least InitialBindackTimeoutFirstReg seconds (see Section 13) before sending a Binding Update to the next home agent. In trying each of the returned home agent addresses, the mobile node SHOULD try each of them in the order they appear in the Home Agent Addresses field in the received Home Agent Address Discovery Reply message.
If the mobile node has a current registration with some home agent (the Lifetime for that registration has not yet expired), then the mobile node MUST attempt any new registration first with that home agent. If that registration attempt fails (e.g., timed out or rejected), the mobile node SHOULD then reattempt this registration with another home agent. If the mobile node knows of no other suitable home agent, then it MAY attempt the dynamic home agent address discovery mechanism described above.
If the mobile node has a current registration with some home agent (the Lifetime for that registration has not yet expired), then the mobile node MUST attempt any new registration first with that home agent. If that registration attempt fails (e.g., timed out or rejected), the mobile node SHOULD then reattempt this registration with another home agent. If the mobile node knows of no other suitable home agent, then it MAY attempt the dynamic home agent address discovery mechanism described above.
Johnson, et al. Standard Track [Page 117] RFC 3775 Mobility Support in IPv6 June 2004
Johnson, et al. Standard Track [Page 117] RFC 3775 Mobility Support in IPv6 June 2004
If, after a mobile node transmits a Home Agent Address Discovery Request message to the Home Agents Anycast address, it does not receive a corresponding Home Agent Address Discovery Reply message within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile node MAY retransmit the same Request message to the same anycast address. This retransmission MAY be repeated up to a maximum of DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be delayed by twice the time interval of the previous retransmission.
If, after a mobile node transmits a Home Agent Address Discovery Request message to the Home Agents Anycast address, it does not receive a corresponding Home Agent Address Discovery Reply message within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile node MAY retransmit the same Request message to the same anycast address. This retransmission MAY be repeated up to a maximum of DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be delayed by twice the time interval of the previous retransmission.
11.4.2. Sending Mobile Prefix Solicitations
11.4.2. Sending Mobile Prefix Solicitations
When a mobile node has a home address that is about to become invalid, it SHOULD send a Mobile Prefix Solicitation to its home agent in an attempt to acquire fresh routing prefix information. The new information also enables the mobile node to participate in renumbering operations affecting the home network, as described in Section 10.6.
When a mobile node has a home address that is about to become invalid, it SHOULD send a Mobile Prefix Solicitation to its home agent in an attempt to acquire fresh routing prefix information. The new information also enables the mobile node to participate in renumbering operations affecting the home network, as described in Section 10.6.
The mobile node MUST use the Home Address destination option to carry its home address. The mobile node MUST support and SHOULD use IPsec to protect the solicitation. The mobile node MUST set the Identifier field in the ICMP header to a random value.
The mobile node MUST use the Home Address destination option to carry its home address. The mobile node MUST support and SHOULD use IPsec to protect the solicitation. The mobile node MUST set the Identifier field in the ICMP header to a random value.
As described in Section 11.7.2, Binding Updates sent by the mobile node to other nodes MUST use a lifetime no greater than the remaining lifetime of its home registration of its primary care-of address. The mobile node SHOULD further limit the lifetimes that it sends on any Binding Updates to be within the remaining valid lifetime (see Section 10.6.2) for the prefix in its home address.
As described in Section 11.7.2, Binding Updates sent by the mobile node to other nodes MUST use a lifetime no greater than the remaining lifetime of its home registration of its primary care-of address. The mobile node SHOULD further limit the lifetimes that it sends on any Binding Updates to be within the remaining valid lifetime (see Section 10.6.2) for the prefix in its home address.
When the lifetime for a changed prefix decreases, and the change would cause cached bindings at correspondent nodes in the Binding Update List to be stored past the newly shortened lifetime, the mobile node MUST issue a Binding Update to all such correspondent nodes.
When the lifetime for a changed prefix decreases, and the change would cause cached bindings at correspondent nodes in the Binding Update List to be stored past the newly shortened lifetime, the mobile node MUST issue a Binding Update to all such correspondent nodes.
These limits on the binding lifetime serve to prohibit use of a mobile node's home address after it becomes invalid.
These limits on the binding lifetime serve to prohibit use of a mobile node's home address after it becomes invalid.
11.4.3. Receiving Mobile Prefix Advertisements
11.4.3. Receiving Mobile Prefix Advertisements
Section 10.6 describes the operation of a home agent to support boot time configuration and renumbering a mobile node's home subnet while the mobile node is away from home. The home agent sends Mobile Prefix Advertisements to the mobile node while away from home, giving "important" Prefix Information options that describe changes in the prefixes in use on the mobile node's home link.
Section 10.6 describes the operation of a home agent to support boot time configuration and renumbering a mobile node's home subnet while the mobile node is away from home. The home agent sends Mobile Prefix Advertisements to the mobile node while away from home, giving "important" Prefix Information options that describe changes in the prefixes in use on the mobile node's home link.
Johnson, et al. Standard Track [Page 118] RFC 3775 Mobility Support in IPv6 June 2004
Johnson, et al. Standard Track [Page 118] RFC 3775 Mobility Support in IPv6 June 2004
The Mobile Prefix Solicitation is similar to the Router Solicitation used in Neighbor Discovery [12], except it is routed from the mobile node on the visited network to the home agent on the home network by usual unicast routing rules.
The Mobile Prefix Solicitation is similar to the Router Solicitation used in Neighbor Discovery [12], except it is routed from the mobile node on the visited network to the home agent on the home network by usual unicast routing rules.
When a mobile node receives a Mobile Prefix Advertisement, it MUST validate it according to the following test:
When a mobile node receives a Mobile Prefix Advertisement, it MUST validate it according to the following test:
o The Source Address of the IP packet carrying the Mobile Prefix
Advertisement is the same as the home agent address to which the
mobile node last sent an accepted home registration Binding Update
to register its primary care-of address. Otherwise, if no such
registrations have been made, it SHOULD be the mobile node's
stored home agent address, if one exists. Otherwise, if the
mobile node has not yet discovered its home agent's address, it
MUST NOT accept Mobile Prefix Advertisements.
o The Source Address of the IP packet carrying the Mobile Prefix Advertisement is the same as the home agent address to which the mobile node last sent an accepted home registration Binding Update to register its primary care-of address. Otherwise, if no such registrations have been made, it SHOULD be the mobile node's stored home agent address, if one exists. Otherwise, if the mobile node has not yet discovered its home agent's address, it MUST NOT accept Mobile Prefix Advertisements.
o The packet MUST have a type 2 routing header and SHOULD be
protected by an IPsec header as described in Section 5.4 and
Section 6.8.
o The packet MUST have a type 2 routing header and SHOULD be protected by an IPsec header as described in Section 5.4 and Section 6.8.
o If the ICMP Identifier value matches the ICMP Identifier value of
the most recently sent Mobile Prefix Solicitation and no other
advertisement has yet been received for this value, then the
advertisement is considered to be solicited and will be processed
further.
o ICMP Identifier値が最も最近送られたモバイルPrefix SolicitationのICMP Identifier値に合って、この値のためにまだ他の広告を全く受け取っていないと、広告を請求されると考えて、さらに処理するでしょう。
Otherwise, the advertisement is unsolicited, and MUST be
discarded. In this case the mobile node SHOULD send a Mobile
Prefix Solicitation.
さもなければ、広告を求められていなく、捨てなければなりません。 この場合、モバイルノードSHOULDはモバイルPrefix Solicitationを送ります。
Any received Mobile Prefix Advertisement not meeting these tests MUST be silently discarded.
静かにこれらのテストに対応しないどんな容認されたモバイルPrefix Advertisementも捨てなければなりません。
For an accepted Mobile Prefix Advertisement, the mobile node MUST process Managed Address Configuration (M), Other Stateful Configuration (O), and the Prefix Information Options as if they arrived in a Router Advertisement [12] on the mobile node's home link. (This specification does not, however, describe how to acquire home addresses through stateful protocols.) Such processing may result in the mobile node configuring a new home address, although due to separation between preferred lifetime and valid lifetime, such changes should not affect most communications by the mobile node, in the same way as for nodes that are at home.
受け入れられたモバイルPrefix Advertisementに関しては、モバイルノードはManaged Address Configuration(M)を処理しなければなりません、Other Stateful Configuration(O)、まるで彼らがモバイルノードのホームの上でRouter Advertisement[12]に到着するかのようにPrefix情報Optionsはリンクします。 (しかしながら、この仕様はstatefulプロトコルを通してホームアドレスを取得する方法を説明しません。) そのような処理は新しいホームアドレスを構成するモバイルノードをもたらすかもしれません、そのような変化が都合のよい生涯と有効な生涯の間の分離のためモバイルノードでほとんどのコミュニケーションに影響するはずがありませんが、同様にホームにあるノードのように。
This specification assumes that any security associations and security policy entries that may be needed for new prefixes have been pre-configured in the mobile node. Note that while dynamic key
この仕様は、新しい接頭語に必要であるどんなセキュリティ協会と安全保障政策エントリーもモバイルノードであらかじめ設定されたと仮定します。 ダイナミックなキーである間、それに注意してください。
Johnson, et al. Standard Track [Page 119] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[119ページ]のRFC3775移動性サポート
management avoids the need to create new security associations, it is still necessary to add policy entries to protect the communications involving the home address(es). Mechanisms for automatic set-up of these entries are outside the scope of this specification.
経営者側は新しいセキュリティ協会を創設する必要性を避けて、ホームアドレス(es)にかかわるコミュニケーションを保護するために方針エントリーを加えるのがまだ必要です。 この仕様の範囲の外にこれらのエントリーの自動セットアップのためのメカニズムがあります。
11.5. Movement
11.5. 動き
11.5.1. Movement Detection
11.5.1. 動き検出
The primary goal of movement detection is to detect L3 handovers. This section does not attempt to specify a fast movement detection algorithm which will function optimally for all types of applications, link-layers and deployment scenarios; instead, it describes a generic method that uses the facilities of IPv6 Neighbor Discovery, including Router Discovery and Neighbor Unreachability Detection. At the time of this writing, this method is considered well enough understood to recommend for standardization, however it is expected that future versions of this specification or other specifications may contain updated versions of the movement detection algorithm that have better performance.
動き検出のプライマリ目標はL3身柄の引き渡しを検出することです。 このセクションは、すべてのタイプのアプリケーション、リンクレイヤ、および展開シナリオのために最適に機能する速い動き検出アルゴリズムを指定するのを試みません。 代わりに、IPv6 Neighborディスカバリーの施設を使用する一般的方法を説明します、RouterディスカバリーとNeighbor Unreachability Detectionを含んでいて。 十分よく理解されていた状態で、このメソッドが、標準化のためにしかしながら、この書くこと時点でこの仕様か他の仕様の将来のバージョンが、より良い性能を持っている動き検出アルゴリズムのアップデートされたバージョンを含むかもしれないと予想されることを勧めると考えられます。
Generic movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bi-directionally reachable, in which case the mobile node must discover a new default router (usually on a new link). However, this detection only occurs when the mobile node has packets to send, and in the absence of frequent Router Advertisements or indications from the link-layer, the mobile node might become unaware of an L3 handover that occurred. Therefore, the mobile node should supplement this method with other information whenever it is available to the mobile node (e.g., from lower protocol layers).
ジェネリック動き検出はデフォルトルータがいつもう2方向に届いていないかを検出するのにNeighbor Unreachability Detectionを使用します、その場合、モバイルノードが新しいデフォルトルータ(通常新しいリンクの)を発見しなければなりません。 しかしながら、モバイルノードが送るパケットを持っているときだけ、この検出は起こります、そして、リンクレイヤからの頻繁なRouter Advertisementsか指摘がないとき、モバイルノードは起こったL3引き渡しに気づかなくなるかもしれません。 したがって、それがモバイルノード(例えば、低級プロトコル層からの)に利用可能であるときはいつも、モバイルノードは他の情報でこのメソッドを補うはずです。
When the mobile node detects an L3 handover, it performs Duplicate Address Detection [13] on its link-local address, selects a new default router as a consequence of Router Discovery, and then performs Prefix Discovery with that new router to form new care-of address(es) as described in Section 11.5.2. It then registers its new primary care-of address with its home agent as described in Section 11.7.1. After updating its home registration, the mobile node then updates associated mobility bindings in correspondent nodes that it is performing route optimization with as specified in Section 11.7.2.
モバイルノードがL3引き渡しを検出すると、リンクローカルアドレスにDuplicate Address Detection[13]を実行して、Routerディスカバリーの結果として新しいデフォルトルータを選定して、新しく形成するためにその新しいルータでPrefixディスカバリーを実行する、注意、-、セクション11.5で.2に説明されるように(es)を扱ってください。 次に、登録する、それが新しい、初期医療、-、セクション11.7で.1に説明されるホームのエージェントとのアドレス そして、本国登録をアップデートした後に、モバイルノードはそれがセクション11.7.2で指定されるように経路最適化を実行している通信員ノードにおける関連移動性結合をアップデートします。
Due to the temporary packet flow disruption and signaling overhead involved in updating mobility bindings, the mobile node should avoid performing an L3 handover until it is strictly necessary. Specifically, when the mobile node receives a Router Advertisement from a new router that contains a different set of on-link prefixes,
移動性結合をアップデートするのに伴われる一時的なパケット流れ分裂とシグナリングオーバーヘッドのため、モバイルノードは、それが厳密に必要になるまでL3引き渡しを実行するのを避けるはずです。 モバイルノードが新しいルータからRouter Advertisementを受けるとき、明確に、それはリンクの上の異なったセットの接頭語を含んでいます。
Johnson, et al. Standard Track [Page 120] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[120ページ]のRFC3775移動性サポート
if the mobile node detects that the currently selected default router on the old link is still bi-directionally reachable, it should generally continue to use the old router on the old link rather than switch away from it to use a new default router.
モバイルノードがそれを検出するなら古いリンクの上の現在選択されたデフォルトルータがまだ2方向に届いている、それは一般に、新しいデフォルトルータを使用するのにそれから遠くでスイッチよりむしろ古いリンクの上に古いルータを使用し続けるべきです。
Mobile nodes can use the information in received Router Advertisements to detect L3 handovers. In doing so the mobile node needs to consider the following issues:
モバイルノードは、L3身柄の引き渡しを検出するのに容認されたRouter Advertisementsの情報を使用できます。 そうする際に、モバイルノードは、以下の問題を考える必要があります:
o There might be multiple routers on the same link, thus hearing a
new router does not necessarily constitute an L3 handover.
o 同じリンクの上に複数のルータがあるかもしれません、その結果、新しいルータが必ずL3引き渡しを構成するというわけではないと聞きます。
o When there are multiple routers on the same link they might
advertise different prefixes. Thus even hearing a new router with
a new prefix might not be a reliable indication of an L3 handover.
o 同じリンクの上に複数のルータがあるとき、それらは異なった接頭語の広告を出すかもしれません。 したがって、新しい接頭語で新しいルータを聞きさえするのは、L3引き渡しの信頼できるしるしでないかもしれません。
o The link-local addresses of routers are not globally unique, hence
after completing an L3 handover the mobile node might continue to
receive Router Advertisements with the same link-local source
address. This might be common if routers use the same link-local
address on multiple interfaces. This issue can be avoided when
routers use the Router Address (R) bit, since that provides a
global address of the router.
o ルータのリンクローカルのアドレスがグローバルにユニークでない、したがって、L3引き渡しを終了した後に、モバイルノードは同じリンク地元筋アドレスでRouter Advertisementsを受け取り続けるかもしれません。 ルータが複数のインタフェースで同じリンクローカルアドレスを使用するなら、これは一般的であるかもしれません。 ルータがRouter Address(R)ビットを使用すると、この問題を避けることができます、それがルータのグローバルアドレスを提供するので。
In addition, the mobile node should consider the following events as indications that an L3 handover may have occurred. Upon receiving such indications, the mobile node needs to perform Router Discovery to discover routers and prefixes on the new link, as described in Section 6.3.7 of RFC 2461 [12].
さらに、モバイルノードは、以下のイベントがL3引き渡しが起こったかもしれないという指摘であるとみなすはずです。 そのような指摘を受けると、モバイルノードは、新しいリンクの上にルータと接頭語を発見するためにRouterディスカバリーを実行する必要があります、.7セクション6.3RFC2461[12]で説明されるように。
o If Router Advertisements that the mobile node receives include an
Advertisement Interval option, the mobile node may use its
Advertisement Interval field as an indication of the frequency
with which it should expect to continue to receive future
Advertisements from that router. This field specifies the minimum
rate (the maximum amount of time between successive
Advertisements) that the mobile node should expect. If this
amount of time elapses without the mobile node receiving any
Advertisement from this router, the mobile node can be sure that
at least one Advertisement sent by the router has been lost. The
mobile node can then implement its own policy to determine how
many lost Advertisements from its current default router
constitute an L3 handover indication.
o モバイルノードが受けるRouter AdvertisementsがAdvertisement Intervalオプションを含んでいるなら、モバイルノードはそれがそのルータから将来のAdvertisementsを受け取り続けていると予想するべきである頻度のしるしとしてAdvertisement Interval分野を使用するかもしれません。 この分野はモバイルノードが予想するはずである最低料率(連続したAdvertisementsの間の最大の時間)を指定します。 モバイルノードがこのルータからどんなAdvertisementも受けないでこの時間が経過するなら、モバイルノードはルータによって送られた少なくとも1Advertisementがなくされたのを確信している場合があります。 そして、モバイルノードは、いくつが現在のデフォルトルータからAdvertisementsをなくしたかがL3引き渡し指示を構成することを決定するためにそれ自身の政策を実施できます。
o Neighbor Unreachability Detection determines that the default
router is no longer reachable.
o 隣人Unreachability Detectionは、デフォルトルータにもう届いていないことを決定します。
Johnson, et al. Standard Track [Page 121] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[121ページ]のRFC3775移動性サポート
o With some types of networks, notification that an L2 handover has
occurred might be obtained from lower layer protocols or device
driver software within the mobile node. While further details
around handling L2 indications as movement hints is an item for
further study, at the time of writing this specification the
following is considered reasonable:
o 何人かのタイプのネットワークと共に、モバイルノードの中で下位層プロトコルかデバイスドライバソフトウェアからL2引き渡しが起こったという通知を得るかもしれません。 この仕様に以下を書く時点で妥当であると考えられるさらなる研究への項目であり、動きがほのめかす取り扱いL2指摘の周りの詳細である間:
An L2 handover indication may or may not imply L2 movement and L2
movement may or may not imply L3 movement; the correlations might
be a function of the type of L2 but might also be a function of
actual deployment of the wireless topology.
L2引き渡し指示は、L2運動とL2運動がL3運動を含意するかもしれないのを含意するかもしれません。 相関関係は、L2のタイプの関数であるかもしれませんが、また、ワイヤレスのトポロジーの実際の展開の機能であるかもしれません。
Unless it is well-known that an L2 handover indication is likely
to imply L3 movement, instead of immediately multicasting a router
solicitation it may be better to attempt to verify whether the
default router is still bi-directionally reachable. This can be
accomplished by sending a unicast Neighbor Solicitation and
waiting for a Neighbor Advertisement with the solicited flag set.
Note that this is similar to Neighbor Unreachability detection but
it does not have the same state machine, such as the STALE state.
の代わりにする、L2引き渡し指示がL3運動を含意しそうであるのが、よく知られない場合すぐに、試みるほうがよいかもしれないマルチキャスティングaルータ懇願は、デフォルトルータにまだ2方向に届いているかどうか確かめます。 設定されて、Neighbor Solicitationと請求でNeighbor Advertisementを待っていると旗を揚げられるユニキャストを送ることによって、これを達成できます。 これがNeighbor Unreachability検出と同様ですが、STALE状態などの同じ州のマシンを持っていないことに注意してください。
If the default router does not respond to the Neighbor
Solicitation it makes sense to proceed to multicasting a Router
Solicitation.
デフォルトルータがNeighbor Solicitationに応じないなら、それはマルチキャスティングにRouter Solicitationを続かせる意味になります。
11.5.2. Forming New Care-of Addresses
11.5.2. 新しい状態で形成する、注意、-、アドレス
After detecting that it has moved a mobile node SHOULD generate a new primary care-of address using normal IPv6 mechanisms. This SHOULD also be done when the current primary care-of address becomes deprecated. A mobile node MAY form a new primary care-of address at any time, but a mobile node MUST NOT send a Binding Update about a new care-of address to its home agent more than MAX_UPDATE_RATE times within a second.
後にそれを検出して、新しい状態でSHOULDがaを生成するモバイルノードを動かした、初期医療、-、正常なIPv6メカニズム使用がこのSHOULDであると扱ってくださいといって、また、電流であるときには終わってください、初期医療、-、アドレスは推奨しなくなります。 モバイルノードが新しい状態でaを形成するかもしれない、初期医療、-、いつでもアドレス、モバイルノードだけがaに関して新しい状態でBinding Updateを送ってはいけない、注意、-、1秒以内にマックス_UPDATE_RATE回数以上をホームのエージェントに扱ってください。
In addition, a mobile node MAY form new non-primary care-of addresses even when it has not switched to a new default router. A mobile node can have only one primary care-of address at a time (which is registered with its home agent), but it MAY have an additional care- of address for any or all of the prefixes on its current link. Furthermore, since a wireless network interface may actually allow a mobile node to be reachable on more than one link at a time (i.e., within wireless transmitter range of routers on more than one separate link), a mobile node MAY have care-of addresses on more than one link at a time. The use of more than one care-of address at a time is described in Section 11.5.3.
新しいデフォルトルータに切り替わらないときさえ、さらに、モバイルノードは新しい非初期医療のアドレスを形成するかもしれません。 モバイルノードが1つしか持つことができない、初期医療、-、時間(ホームのエージェントに登録される)のアドレス、それだけには、現在のリンクにおける接頭語のいずれかすべてのためのアドレスの追加注意があるかもしれません。 その上、ワイヤレス以来、ネットワーク・インターフェースが、実際に一度に(すなわち、1個以上の別々のリンクの上のワイヤレスの送信機範囲のルータの中で)モバイルノードが持っているかもしれない1個以上のリンクの上にモバイルノードが届いているのを許容するかもしれない、注意、-、1以上に関するアドレスは一度に、リンクされます。 1つ以上の使用、注意、-、一度にアドレスはセクション11.5で.3に説明されます。
Johnson, et al. Standard Track [Page 122] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[122ページ]のRFC3775移動性サポート
As described in Section 4, in order to form a new care-of address, a mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6 [29]) Address Autoconfiguration. If a mobile node needs to use a source address (other than the unspecified address) in packets sent as a part of address autoconfiguration, it MUST use an IPv6 link- local address rather than its own IPv6 home address.
アドレス、モバイルノードは状態がない[13]かstatefulのどちらかを使用するかもしれません。新しい状態でaを形成するためにセクション4で説明される、注意、-、(例えば、DHCPv6[29])アドレスAutoconfiguration。 モバイルノードが、アドレス自動構成の一部として送られたパケットでソースアドレス(不特定のアドレスを除いた)を使用する必要があるなら、それはIPv6リンクを使用しなければなりません。それ自身のIPv6ホームアドレスよりむしろローカルアドレス。
RFC 2462 [13] specifies that in normal processing for Duplicate Address Detection, the node SHOULD delay sending the initial Neighbor Solicitation message by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY. Since delaying DAD can result in significant delays in configuring a new care-of address when the Mobile Node moves to a new link, the Mobile Node preferably SHOULD NOT delay DAD when configuring a new care-of address. The Mobile Node SHOULD delay according to the mechanisms specified in RFC 2462 unless the implementation has a behavior that desynchronizes the steps that happen before the DAD in the case that multiple nodes experience handover at the same time. Such desynchronizing behaviors might be due to random delays in the L2 protocols or device drivers, or due to the movement detection mechanism that is used.
RFC2462[13]は、Duplicate Address Detectionのための正常処理では、ノードSHOULDが、0とマックス_RTRの間の無作為の遅れによる初期のNeighbor Solicitationメッセージに_SOLICITATION_DELAYを送るのを遅らせると指定します。 以来DADを遅らせると新しい状態でaを構成する重要な遅れがもたらされることができる、注意、-、新しい状態でaを構成するとき、モバイルNodeが新しいリンクに移行して、望ましくは、モバイルNodeがSHOULD NOTであるアドレスがDADを遅らせる、注意、-、アドレス。 実装に複数のノードが同時に引き渡しのようになって、DADの前で起こるステップを反連動させる振舞いがない場合、メカニズムに従ったモバイルNode SHOULD遅れはRFC2462で指定しました。 振舞いをそのような反連動させるのであるのは、L2プロトコルかデバイスドライバか、使用された動き検出メカニズムのため無作為の遅れのためであるかもしれません。
11.5.3. Using Multiple Care-of Addresses
11.5.3. 倍数を使用する、注意、-、アドレス
As described in Section 11.5.2, a mobile node MAY use more than one care-of address at a time. Particularly in the case of many wireless networks, a mobile node effectively might be reachable through multiple links at the same time (e.g., with overlapping wireless cells), on which different on-link subnet prefixes may exist. The mobile node MUST ensure that its primary care-of address always has a prefix that is advertised by its current default router. After selecting a new primary care-of address, the mobile node MUST send a Binding Update containing that care-of address to its home agent. The Binding Update MUST have the Home Registration (H) and Acknowledge (A) bits set its home agent, as described on Section 11.7.1.
モバイルノードがセクション11.5.2で説明されるように1つ以上を使用するかもしれない、注意、-、一度にアドレス。 特に多くのワイヤレス・ネットワークの場合では、リンクの上のどの異なったサブネット接頭語が存在するかもしれないかに関して事実上、モバイルノードは同時に(例えば、ワイヤレスのセルを重ね合わせるのに)、複数のリンクを通して届いているかもしれません。 モバイルノードがそれを確実にしなければならない、それ、初期医療、-、アドレス、いつも現在のデフォルトルータによって広告に掲載される接頭語を持っています。 後に新しい状態でaを選択する、初期医療、-、アドレス、モバイルノードがそれを含むBinding Updateを送らなければならない、注意、-、ホームのエージェントへのアドレス。 Binding UpdateはホームRegistration(H)とAcknowledge(A)ビットにホームのエージェントを設定させなければなりません、セクション11.7.1で説明されるように。
To assist with smooth handovers, a mobile node SHOULD retain its previous primary care-of address as a (non-primary) care-of address, and SHOULD still accept packets at this address, even after registering its new primary care-of address with its home agent. This is reasonable, since the mobile node could only receive packets at its previous primary care-of address if it were indeed still connected to that link. If the previous primary care-of address was allocated using stateful Address Autoconfiguration [29], the mobile node may not wish to release the address immediately upon switching to a new primary care-of address.
滑らかな身柄の引き渡し、SHOULDが保有するモバイルノードを助けるために、それが前である、初期医療、-、a(非プライマリの)としてのアドレス、注意、-、アドレス、SHOULDがこのアドレスでまだパケットを受け入れていて、登録さえした後にさえそれが新しい、初期医療、-、ホームのエージェントとのアドレス。 これが妥当である、ノードがパケットを受けることができただけであるモバイル以来、それが前である、初期医療、-、本当に、アドレスはそれであるならまだそのリンクに接続されていました。 前である、初期医療、-、モバイルノードがstateful Address Autoconfiguration[29]を使用することでアドレスを割り当てて、すぐaに新しい状態で切り替わることに関するアドレスをリリースしたがっていないかもしれない、初期医療、-、アドレス。
Johnson, et al. Standard Track [Page 123] RFC 3775 Mobility Support in IPv6 June 2004
ジョンソン、他 IPv6 June 2004での標準の道[123ページ]のRFC3775移動性サポート
Whenever a mobile node determines that it is no longer reachable through a given link, it SHOULD invalidate all care-of addresses associated with address prefixes that it discovered from routers on the unreachable link which are not in the current set of address prefixes advertised by the (possibly new) current default router.
モバイルノードがそれがもう与えられたリンクを通して届いていなくて、SHOULDであることを決定するときはいつも、すべてを無効にしてください、注意、-、それが手の届かないリンクの上の現在のセットのアドレス接頭語にはないルータから発見したアドレス接頭語に関連しているアドレスは(ことによると新しい)の現在のデフォルトルータで広告を出しました。
11.5.4. Returning Home
11.5.4. 戻っているホーム
A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. In this home registration, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the Lifetime field to zero, and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its home address as the source address in the Binding Update.
モバイルノードはそれを検出します。使用中の動き検出アルゴリズム(セクション11.5.1)でそれはホームのリンクに戻って、モバイルノードが再びそれを検出するとき、ホームサブネット接頭語はリンクです。 そして、モバイルノードSHOULDは、それのためにもうパケットに妨害しない、またはトンネルを堀らないようホームのエージェントに命令するためにホームのエージェントにBinding Updateを送ります。 モバイルノードがこの本国登録では、Acknowledge(A)とホームRegistration(H)ビットを設定して、Lifetime分野をゼロに設定して、セットしなければならない、注意、-、モバイルノードの自己のホームアドレスとの結合のためのアドレス。 モバイルノードはBinding Updateのソースアドレスとしてホームアドレスを使用しなければなりません。
When sending this Binding Update to its home agent, the mobile node must be careful in how it uses Neighbor Solicitation [12] (if needed) to learn the home agent's link-layer address, since the home agent will be currently configured to intercept packets to the mobile node's home address using Duplicate Address Detection (DAD). In particular, the mobile node is unable to use its home address as the Source Address in the Neighbor Solicitation until the home agent stops defending the home address.
このBinding Updateをホームのエージェントに送るモバイルノードが現在慎重であるに違いないときに、それがホームのエージェントのリンクレイヤアドレスを学ぶのに、どう、Neighbor Solicitation[12](必要であるなら)を使用するかで、ホーム以来、エージェントは、モバイルノードのホームアドレスにパケットを妨害するためにDuplicate Address Detection(DAD)を使用することで構成されるでしょう。 特に、ホームのエージェントが、ホームアドレスを防御するのを止めるまで、モバイルノードはSource AddressとしてNeighbor Solicitationでホームアドレスを使用できません。
一覧
スポンサーリンク
