Network Working Group E. Nordmark
Request for Comments: 5533 Sun Microsystems
Category: Standards Track M. Bagnulo
UC3M
June 2009
Shim6: Level 3 Multihoming Shim Protocol for IPv6
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider-allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working.
マルチホーミングは、マルチホームサイトがプロバイダに依存しないIPv6アドレスを有するであろうと仮定することなく、フェイルオーバーと負荷分散特性を有するIPv6のために提供することができるように、このドキュメントは、SHIM6プロトコル、トランスポートプロトコルの下ロケータアジリティを提供するためのレイヤ3のシムを定義しますプレフィックスは、グローバルIPv6ルーティングテーブルに発表されました。状態は、後で別のロケータペアにフェールオーバーするために使用することができるように、ピア・ホストとの状態を設定するために、この文書で指定SHIM6プロトコルを使用する複数のプロバイダに割り当てられたIPv6アドレスプレフィックスを有するサイト、べきオリジナルのものでホスト仕事をやめる。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Goals ......................................................5
1.2. Non-Goals ..................................................5
1.3. Locators as Upper-Layer Identifiers (ULID) .................6
1.4. IP Multicast ...............................................7
1.5. Renumbering Implications ...................................8
1.6. Placement of the Shim ......................................9
1.7. Traffic Engineering .......................................11
2. Terminology ....................................................12
2.1. Definitions ...............................................12
2.2. Notational Conventions ....................................15
2.3. Conceptual ................................................15
3. Assumptions ....................................................15
4. Protocol Overview ..............................................17
4.1. Context Tags ..............................................19
4.2. Context Forking ...........................................19
4.3. API Extensions ............................................20
4.4. Securing Shim6 ............................................20
4.5. Overview of Shim Control Messages .........................21
4.6. Extension Header Order ....................................22
5. Message Formats ................................................23
5.1. Common Shim6 Message Format ...............................23
5.2. Shim6 Payload Extension Header Format .....................24
5.3. Common Shim6 Control Header ...............................25
5.4. I1 Message Format .........................................26
5.5. R1 Message Format .........................................28
5.6. I2 Message Format .........................................29
5.7. R2 Message Format .........................................31
5.8. R1bis Message Format ......................................33
5.9. I2bis Message Format ......................................34
5.10. Update Request Message Format ............................37
5.11. Update Acknowledgement Message Format ....................38
5.12. Keepalive Message Format .................................40
5.13. Probe Message Format .....................................40
5.14. Error Message Format .....................................40
5.15. Option Formats ...........................................42
5.15.1. Responder Validator Option Format .................44
5.15.2. Locator List Option Format ........................44
5.15.3. Locator Preferences Option Format .................46
5.15.4. CGA Parameter Data Structure Option Format ........48
5.15.5. CGA Signature Option Format .......................49
5.15.6. ULID Pair Option Format ...........................49
5.15.7. Forked Instance Identifier Option Format ..........50
5.15.8. Keepalive Timeout Option Format ...................50
6. Conceptual Model of a Host .....................................51
6.1. Conceptual Data Structures ................................51
6.2. Context STATES ............................................52
7. Establishing ULID-Pair Contexts ................................54
7.1. Uniqueness of Context Tags ................................54
7.2. Locator Verification ......................................55
7.3. Normal Context Establishment ..............................56
7.4. Concurrent Context Establishment ..........................56
7.5. Context Recovery ..........................................58
7.6. Context Confusion .........................................60
7.7. Sending I1 Messages .......................................61
7.8. Retransmitting I1 Messages ................................62
7.9. Receiving I1 Messages .....................................62
7.10. Sending R1 Messages ......................................63
7.10.1. Generating the R1 Validator .......................64
7.11. Receiving R1 Messages and Sending I2 Messages ............64
7.12. Retransmitting I2 Messages ...............................65
7.13. Receiving I2 Messages ....................................66
7.14. Sending R2 Messages ......................................67
7.15. Match for Context Confusion ..............................68
7.16. Receiving R2 Messages ....................................69
7.17. Sending R1bis Messages ...................................69
7.17.1. Generating the R1bis Validator ....................70
7.18. Receiving R1bis Messages and Sending I2bis Messages ......71
7.19. Retransmitting I2bis Messages ............................72
7.20. Receiving I2bis Messages and Sending R2 Messages .........72
8. Handling ICMP Error Messages ...................................74
9. Teardown of the ULID-Pair Context ..............................76
10. Updating the Peer .............................................77
10.1. Sending Update Request Messages ..........................77
10.2. Retransmitting Update Request Messages ...................78
10.3. Newer Information while Retransmitting ...................78
10.4. Receiving Update Request Messages ........................79
10.5. Receiving Update Acknowledgement Messages ................81
11. Sending ULP Payloads ..........................................81
11.1. Sending ULP Payload after a Switch .......................82
12. Receiving Packets .............................................83
12.1. Receiving Payload without Extension Headers ..............83
12.2. Receiving Shim6 Payload Extension Headers ................83
12.3. Receiving Shim Control Messages ..........................84
12.4. Context Lookup ...........................................84
13. Initial Contact ...............................................86
14. Protocol Constants ............................................87
15. Implications Elsewhere ........................................88
15.1. Congestion Control Considerations ........................88
15.2. Middle-Boxes Considerations ..............................88
15.3. Operation and Management Considerations ..................89
15.4. Other Considerations .....................................90
16. Security Considerations .......................................91
16.1. Interaction with IPSec ...................................93
16.2. Residual Threats .........................................94
17. IANA Considerations ...........................................95
18. Acknowledgements ..............................................97
19. References ....................................................97
19.1. Normative References .....................................97
19.2. Informative References ...................................97
Appendix A. Possible Protocol Extensions ........................100
Appendix B. Simplified STATE Machine ............................101
B.1. Simplified STATE Machine Diagram ........................108
Appendix C. Context Tag Reuse ...................................109
C.1. Context Recovery ........................................109
C.2. Context Confusion .......................................109
C.3. Three-Party Context Confusion .........................110
C.4. Summary .................................................110
Appendix D. Design Alternatives .................................111
D.1. Context Granularity .....................................111
D.2. Demultiplexing of Data Packets in Shim6 Communications ..111
D.2.1. Flow Label .........................................112
D.2.2. Extension Header ...................................115
D.3. Context-Loss Detection ................................115
D.4. Securing Locator Sets ...................................117
D.5. ULID-Pair Context-Establishment Exchange ............120
D.6. Updating Locator Sets ...................................121
D.7. State Cleanup ...........................................122
This document describes a layer 3 shim approach and protocol for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties [11], without assuming that a multihomed site will have a provider-independent IPv6 address announced in the global IPv6 routing table. The hosts in a site that has multiple provider-allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working (the term locator is defined in Section 2).
マルチホーミングは、マルチホームサイトがプロバイダに依存しないを有するであろうと仮定することなく、フェイルオーバーと負荷分散特性[11]とIPv6のために提供することができるように、この文書では、トランスポートプロトコルの下ロケータアジリティを提供するためのレイヤ3シムアプローチとプロトコルについて説明しますIPv6アドレスは、グローバルIPv6ルーティングテーブルに発表しました。状態は、後で別のロケータペアにフェールオーバーするために使用することができるように、ピア・ホストとの状態を設定するために、この文書で指定SHIM6プロトコルを使用する複数のプロバイダに割り当てられたIPv6アドレスプレフィックスを有するサイト、べきオリジナルのものでホスト作業を停止（用語ロケータは、セクション2で定義されます）。
The Shim6 protocol is a site-multihoming solution in the sense that it allows existing communication to continue when a site that has multiple connections to the Internet experiences an outage on a subset of these connections or further upstream. However, Shim6 processing is performed in individual hosts rather than through site-wide mechanisms.
SHIM6プロトコルは、インターネットへの複数の接続を持っているサイトは、これらの接続またはさらに上流のサブセットに停電を経験するときに継続する通信を既存のを可能にするという意味でサイトマルチホーミングソリューションです。しかし、SHIM6処理は、個々のホストではなく、サイト全体のメカニズムを介して行われます。
We assume that redirection attacks are prevented using Hash-Based Addresses (HBA) as defined in [3].
我々は、リダイレクト攻撃は、[3]で定義されるようにハッシュベースアドレス（HBA）を使用して防止されると仮定する。
The reachability and failure-detection mechanisms, including how a new working locator pair is discovered after a failure, are specified in RFC 5534 [4]. This document allocates message types and option types for that sub-protocol, and leaves the specification of the message and option formats, as well as the protocol behavior, to RFC 5534.
新しい作業ロケータ対が故障した後に発見された方法などの到達可能性と故障検出機構は、RFC 5534で指定されている[4]。この文書は、サブプロトコルのメッセージタイプおよびオプションのタイプを割り当て、RFC 5534に、メッセージおよびオプションのフォーマットの仕様、ならびにプロトコルの動作を残します。
The goals for this approach are to:
このアプローチの目的は、次のとおりです。
o Preserve established communications in the presence of certain classes of failures, for example, TCP connections and UDP streams.
Oたとえば、TCP接続およびUDPストリーム、障害の特定のクラスの存在下で確立された通信を保持。
o Have minimal impact on upper-layer protocols in general and on transport protocols and applications in particular.
O一般に、特にトランスポートプロトコルとアプリケーションに上位層プロトコルに最小限の影響を有します。
o Address the security threats in [15] through a combination of the HBA/CGA approach specified in RFC 5535 [3] and the techniques described in this document.
O [3] RFC 5535で指定されたHBA / CGAアプローチの組み合わせにより[15]のセキュリティ脅威に対応し、この文書に記載された技術。
o Not require an extra roundtrip up front to set up shim-specific state. Instead, allow the upper-layer traffic (e.g., TCP) to flow as normal and defer the set up of the shim state until some number of packets have been exchanged.
Oシム固有の状態を設定するには、フロントまで余分処理を必要としません。代わりに、パケットの一部の数が交換されるまで上位レイヤトラフィック（例えば、TCP）を通常通り流れ、シム状態のセットアップを延期することを可能にします。
o Take advantage of multiple locators/addresses for load spreading so that different sets of communication to a host (e.g., different connections) might use different locators of the host. Note that this might cause load to be spread unevenly; thus, we use the term "load spreading" instead of "load balancing". This capability might enable some forms of traffic engineering, but the details for traffic engineering, including what requirements can be satisfied, are not specified in this document, and form part of potential extensions to this protocol.
O負荷がホストの異なるロケータを使用する可能性があるホスト（例えば、異なる接続）への通信のように異なるセットを拡散するための複数のロケータ/アドレスを利用します。これは、負荷が不均一に広がることを引き起こすかもしれないことに注意してください。したがって、我々は代わりに「ロード・バランシング」の「広がり負荷」という用語を使用します。この機能は、どのような要件を満たすことができ、この文書で指定されており、このプロトコルへの潜在的な拡張の一部を形成していないなどのトラフィックエンジニアリングのいくつかの形態が、トラフィックエンジニアリングの詳細を、有効かもしれません。
The problem we are trying to solve is site multihoming, with the ability to have the set of site prefixes change over time due to site renumbering. Further, we assume that such changes to the set of locator prefixes can be relatively slow and managed: slow enough to allow updates to the DNS to propagate (since the protocol defined in this document depends on the DNS to find the appropriate locator sets). However, note that it is an explicit non-goal to make communication survive a renumbering event (which causes all the locators of a host to change to a new set of locators). This proposal does not attempt to solve the related problem of host mobility. However, it might turn out that the Shim6 protocol can be a useful component for future host mobility solutions, e.g., for route optimization.
私たちが解決しようとしている問題は、サイトのリナンバリングに時間とともに変化するサイトプレフィックスのセットを持っている能力を持つサイトマルチホーミング、です。さらに、我々は、ロケータ接頭語のセットに、そのような変更は比較的遅くして管理することができることを前提としています。DNSの更新が伝播することを可能にするために十分に遅い（この文書で定義されたプロトコルは、適切なロケータセットを見つけるために、DNSに依存しているため）。しかし、通信が（ホストのすべてのロケータがロケータの新しいセットに変化させる）リナンバリングイベントを生き残る作るために、明示的な非目標であることに注意してください。この提案は、ホストモビリティの関連問題を解決しようとしません。しかし、それはSHIM6プロトコルは、経路最適化のために、例えば、将来のホストモビリティソリューションのために有用な成分であることができることを判明するかもしれません。
Finally, this proposal also does not try to provide a new network-level or transport-level identifier name space distinct from the current IP address name space. Even though such a concept would be useful to upper-layer protocols (ULPs) and applications, especially if the management burden for such a name space was negligible and there was an efficient yet secure mechanism to map from identifiers to locators, such a name space isn't necessary (and furthermore doesn't seem to help) to solve the multihoming problem.
最後に、この提案は、現在のIPアドレスの名前空間は異なる新しいネットワーク・レベルまたはトランスポートレベルの識別子の名前空間を提供しようとしません。そのような概念は、そのような名前空間の管理負担は無視できたと、ロケータと識別子から、そのような名前空間をマッピングするための効率的かつ安全な機構があった場合は特に、上位層プロトコル（のULP）とアプリケーションに有用であるにもかかわらず必要はありません（さらに助けていないようです）マルチホーミングの問題を解決します。
The Shim6 proposal doesn't fully separate the identifier and locator functions that have traditionally been overloaded in the IP address. However, throughout this document the term "identifier" or, more specifically, upper-layer identifier (ULID), refers to the identifying function of an IPv6 address. "Locator" refers to the network-layer routing and forwarding properties of an IPv6 address.
SHIM6の提案は完全に伝統的に、IPアドレスにオーバーロードされている識別子とロケータの機能を分離しません。しかしながら、本明細書を通して、用語「識別子」または、より具体的には、上層識別子（ULID）は、IPv6アドレスの識別機能を指します。 「ロケータ」は、IPv6アドレスのネットワーク層ルーティングおよび転送特性を指します。
The approach described in this document does not introduce a new identifier name space but instead uses the locator that is selected in the initial contact with the remote peer as the preserved upper-layer identifier (ULID). While there may be subsequent changes in the selected network-level locators over time (in response to failures in using the original locator), the upper-level protocol stack elements will continue to use this upper-level identifier without change.
この文書に記載されたアプローチは、新しい識別子名前空間を導入する代わりに保存上層識別子（ULID）などのリモートピアとの最初の接触で選択されたロケータを使用しません。 （元のロケータを使用しての失敗に応答して）経時的な選択されたネットワーク・レベルのロケータにおけるその後の変化があってもよいが、上位プロトコルスタック要素は変化することなく、この上位識別子を使用し続けます。
This implies that the ULID selection is performed as today's default address selection as specified in RFC 3484 [7]. Some extensions are needed to RFC 3484 to try different source addresses, whether or not the Shim6 protocol is used, as outlined in [9]. Underneath, and transparently, the multihoming shim selects working locator pairs with the initial locator pair being the ULID pair. If communication subsequently fails, the shim can test and select alternate locators. A subsequent section discusses the issues that arise when the selected ULID is not initially working, which creates the need to switch locators up front.
これは、RFC 3484で指定されたULIDの選択は、今日のデフォルトのアドレス選択として実行されていることを意味する[7]。 [9]に概説されているよういくつかの拡張は、SHIM6プロトコルが使用されているかどうかにかかわらず、異なる送信元アドレスを試すためにRFC 3484に必要とされています。下に、かつ透過、マルチホーミングシムは、最初のロケータペアがULIDペアであることと、作業ロケータペアを選択します。通信がその後失敗した場合、シムは、別のロケータをテストし、選択することができます。以降のセクションには、選択したULIDが最初にアップフロントロケータを切り替える必要性を作成しており、動作していない場合に発生する問題について説明します。
Using one of the locators as the ULID has certain benefits for applications that have long-lived session state or that perform callbacks or referrals, because both the Fully Qualified Domain Name (FQDN) and the 128-bit ULID work as handles for the applications.
ULIDは長命セッション状態を持っているか、そのコールバックや紹介を行うアプリケーションのための特定の利点を持っているようので、完全修飾ドメイン名（FQDN）と128ビットのULID仕事の両方のアプリケーションのためのハンドルとして、ロケータのいずれかを使用します。
However, using a single 128-bit ULID doesn't provide seamless communication when that locator is unreachable. See [18] for further discussion of the application implications.
そのロケータが到達不能である場合しかし、単一の128ビットULIDを使用してシームレスな通信を提供しません。アプリケーションへの影響のさらなる議論については[18]を参照。
There has been some discussion of using non-routable addresses, such as Unique-Local Addresses (ULAs) [14], as ULIDs in a multihoming solution. While this document doesn't specify all aspects of this, it is believed that the approach can be extended to handle the non-routable address case. For example, the protocol already needs to handle ULIDs that are not initially reachable. Thus, the same mechanism can handle ULIDs that are permanently unreachable from outside their site. The issue becomes how to make the protocol perform well when the ULID is known a priori to be unreachable (e.g., the ULID is a ULA), for instance, avoiding any timeout and retries in this case. In addition, one would need to understand how the ULAs would be entered in the DNS to avoid a performance impact on existing, non-Shim6-aware IPv6 hosts potentially trying to communicate to the (unreachable) ULA.
マルチホーミング溶液にULIDsように、このようなユニークローカルアドレス（ULAs）[14]などの非ルーティング可能なアドレスを使用して、いくつかの議論がありました。この文書は、こののすべての側面を指定しませんが、アプローチが非ルーティング可能なアドレスのケースを処理するために拡張することができると考えられています。例えば、プロトコルは、すでに最初に到達できないULIDsを処理する必要があります。このように、同じメカニズムは、自分のサイト外から永久に到達できないULIDsを扱うことができます。問題はULIDは、例えば、（例えば、ULIDはULA）で到達不能であることが事前に知られているこの場合に任意のタイムアウトおよび再試行を避け、十分プロトコルを実行するためにどのようになります。また、1はULAsは、既存のパフォーマンスへの影響を避けるために、DNSに入力されたことになるかを理解する必要があるだろう、非SHIM6対応のIPv6は、潜在的に（到達不能）ULAに通信しようとして開催しています。
IP multicast requires that the IP Source Address field contain a topologically correct locator for the interface that is used to send the packet, since IP multicast routing uses both the source address and the destination group to determine where to forward the packet. In particular, IP multicast routing needs to be able to do the Reverse Path Forwarding (RPF) check. (This isn't much different than the situation with widely implemented ingress filtering [6] for unicast.)
IPマルチキャストルーティングは、パケットの転送先を決定するために、送信元アドレス及び宛先グループの両方を使用するため、IPマルチキャストは、IPソースアドレスフィールドは、パケットを送信するために使用されたインターフェイスのトポロジー的に正しいロケータを含むことを必要とします。具体的には、IPマルチキャストルーティングは、Reverse Path Forwarding（RPF）チェックを行うことができるようにする必要があります。 （これは、ユニキャストのために広く実装イングレスフィルタリング[6]の状況よりも非常に異なるものではありません。）
While in theory it would be possible to apply the shim re-mapping of the IP address fields between ULIDs and locators, the fact that all the multicast receivers would need to know the mapping to perform makes such an approach difficult in practice. Thus, it makes sense to have multicast ULPs operate directly on locators and not use the shim. This is quite a natural fit for protocols that use RTP [10], since RTP already has an explicit identifier in the form of the synchronization source (SSRC) field in the RTP headers. Thus, the actual IP address fields are not important to the application.
理論的には、それはULIDsとロケータの間でIPアドレスフィールドのシムの再マッピングを適用することが可能であろうが、すべてのマルチキャスト受信機が実行するためにマッピングを知る必要があるという事実は、実際には、このようなアプローチを困難にします。したがって、マルチキャストのULPは、ロケータ上で直接動作し、シムを使用していないと意味があります。これは、RTPは既にRTPヘッダ内の同期ソース（SSRC）フィールドの形で明示的識別子を有しているので、RTP [10]を使用するプロトコルのために非常に自然にフィットです。したがって、実際のIPアドレスフィールドには、アプリケーションにとって重要ではありません。
In summary, IP multicast will not need the shim to remap the IP addresses.
要約すると、IPマルチキャストは、IPアドレスを再マッピングするシムを必要としません。
This doesn't prevent the receiver of multicast to change its locators, since the receiver is not explicitly identified; the destination address is a multicast address and not the unicast locator of the receiver.
これは、受信機は、明示的に識別されていないため、そのロケータを変更するには、マルチキャストの受信を防ぐことはできません。宛先アドレスがマルチキャストアドレスではなく、受信機のユニキャストロケータです。
As stated above, this approach does not try to make communication survive renumbering in the general case.
上述したように、このアプローチは、通信は、一般的な場合にはリナンバリング生き残るにしようとしません。
When a host is renumbered, the effect is that one or more locators become invalid, and zero or more locators are added to the host's network interface. This means that the set of locators that is used in the shim will change, which the shim can handle as long as not all the original locators become invalid at the same time; the shim's ability to handle this also depends on the time that is required to update the DNS and for those updates to propagate.
ホストが付け直された場合、効果は、一つ以上のロケータが無効になるということで、ゼロ以上のロケータは、ホストのネットワークインターフェイスに追加されます。これは、シムは限りませんすべてのオリジナルのロケータが同時に無効になるよう処理することができたシムで使用されているロケータのセットは、変更されることを意味します。これを処理するシムの能力はまた、DNSを更新し、その更新が伝播するために必要な時間に依存します。
But IP addresses are also used as ULIDs, and making the communication survive locators becoming invalid can potentially cause some confusion at the upper layers. The fact that a ULID might be used with a different locator over time opens up the possibility that communication between two ULIDs might continue to work after one or both of those ULIDs are no longer reachable as locators, for example, due to a renumbering event. This opens up the possibility that the ULID (or at least the prefix on which it is based) may be reassigned to another site while it is still being used (with another locator) for existing communication.
しかし、IPアドレスもULIDsとして使用され、通信が無効になってロケータを生き残る作ることは、潜在的に上位層でのいくつかの混乱を引き起こす可能性があります。 ULIDは、時間をかけて別のロケータで使用されるかもしれないという事実は、2 ULIDs間の通信が原因リナンバリングイベントに、例えば、またはそれらのULIDsの両方がもはやロケータとして届いているものの後に動作し続けるかもしれないという可能性を開きます。これは、依然として既存の通信用に（別のロケータで）使用されている間ULID（それが基づいているか、少なくともプレフィックス）が別のサイトに再割り当てすることができるという可能性を開きます。
In the worst case, we could end up with two separate hosts using the same ULID while both of them are communicating with the same host.
最悪のケースでは、我々は彼らの両方が同じホストと通信している間、同じULIDを使用して、2つの別々のホストで終わる可能性があります。
This potential source for confusion is avoided by requiring that any communication using a ULID MUST be terminated when the ULID becomes invalid (due to the underlying prefix becoming invalid). This behavior can be accomplished by explicitly discarding the shim state when the ULID becomes invalid. The context-recovery mechanism will then make the peer aware that the context is gone and that the ULID is no longer present at the same locator(s).
混乱のために、この潜在的なソースは、ULIDが（無効ななって下層のプレフィックスに）無効になったときにULIDを使用して、任意の通信が終了しなければならないことを要求することによって回避されます。この動作は、ULIDが無効になったときに、明示的にシム状態を破棄することによって達成することができます。コンテキスト回復メカニズムは、コンテキストがなくなっとULIDはもはや同じロケータ（複数可）に存在するものであることを相手に知らせます。
-----------------------
| Transport Protocols |
-----------------------
-------------- ------------- IP endpoint
| Frag/reass | | Dest opts | sub-layer
-------------- -------------
---------------------
| Shim6 shim layer |
---------------------
------ IP routing
| IP | sub-layer
------
Figure 1: Protocol Stack
図1：プロトコルスタック
The proposal uses a multihoming shim layer within the IP layer, i.e., below the ULPs, as shown in Figure 1, in order to provide ULP independence. The multihoming shim layer behaves as if it is associated with an extension header, which would be placed after any routing-related headers in the packet (such as any hop-by-hop options). However, when the locator pair is the ULID pair, there is no data that needs to be carried in an extension header; thus, none is needed in that case.
図1に示すように、提案は、ULPの独立性を提供するために、IP層内、すなわち、以下のULPマルチホーミングシム層を使用します。それは（例えば、任意のホップバイホップオプションなど）は、パケット内の任意のルーティング関連ヘッダーの後に配置される拡張ヘッダに関連付けられているかのようにマルチホーミングシム層は振る舞います。ロケータペアがULIDペアである場合しかし、拡張ヘッダで運ばれる必要があるデータはありません。このように、いずれもそのような場合には必要ありません。
Layering the Fragmentation header above the multihoming shim makes reassembly robust in the case that there is broken multi-path routing that results in using different paths, hence potentially different source locators, for different fragments. Thus, the multihoming shim layer is placed between the IP endpoint sublayer (which handles fragmentation and reassembly) and the IP routing sublayer (which selects the next hop and interface to use for sending out packets).
マルチホーミングシム上記フラグメンテーションヘッダーを積層する異なるフラグメントについて、異なるパスを使用して、その結果、マルチパスルーティング、したがって潜在的に異なるソースロケータが破損した場合の再アセンブリが頑強なります。したがって、マルチホーミングシム層は、（断片化と再アセンブリを処理する）IPエンドポイントサブレイヤと（パケットを送信するために使用するネクストホップとインタフェースを選択）IPルーティング・サブレイヤとの間に配置されます。
Applications and upper-layer protocols use ULIDs that the Shim6 layer maps to/from different locators. The Shim6 layer maintains state, called ULID-pair context, per ULID pair (that is, such state applies to all ULP connections between the ULID pair) in order to perform this mapping. The mapping is performed consistently at the sender and the receiver so that ULPs see packets that appear to be sent using ULIDs from end to end. This property is maintained even though the packets travel through the network containing locators in the IP address fields, and even though those locators may be changed by the transmitting Shim6 layer.
アプリケーションと上位層プロトコルは、ULIDsを使用することSHIM6層マップへ/別のロケータから。 SHIM6層は、このマッピングを実行するために（すなわち、そのような状態はULIDペア間のすべてのULP接続に適用される）ULIDペアごと、ULID対のコンテキストと呼ばれる状態を維持します。 ULPは、端から端までULIDsを使用して送信されるように見えるパケットを見るようにマッピングは、送信側と受信側で一貫して行われます。パケットがIPアドレスフィールドにロケータを含むネットワークを通って移動していても、このプロパティが維持され、そしてそれらのロケータは送信SHIM6層によって変更することができるにもかかわらず。
The context state is maintained per remote ULID, i.e., approximately per peer host, and not at any finer granularity. In particular, the context state is independent of the ULPs and any ULP connections. However, the forking capability enables Shim6-aware ULPs to use more than one locator pair at a time for a single ULID pair.
コンテキスト状態は、約ピアホストごとではなく、任意のより細かい粒度で、すなわち、リモートULIDごとに維持されます。具体的には、コンテキスト状態のULPと任意ULP接続とは無関係です。しかし、フォークの機能は、単一のULIDペアのため、一度に複数のロケータペアを使用するSHIM6認識のULPを可能にします。
---------------------------- ----------------------------
| Sender A | | Receiver B |
| | | |
| ULP | | ULP |
| | src ULID(A)=L1(A) | | ^ |
| | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) |
| v | | | dst ULID(B)=L1(B) |
| multihoming shim | | multihoming shim |
| | src L2(A) | | ^ |
| | dst L3(B) | | | src L2(A) |
| v | | | dst L3(B) |
| IP | | IP |
---------------------------- ----------------------------
| ^
------- cloud with some routers -------
Figure 2: Mapping with Changed Locators
図2：変更されたロケータとのマッピング
The result of this consistent mapping is that there is no impact on the ULPs. In particular, there is no impact on pseudo-header checksums and connection identification.
この一貫性のマッピングの結果は、のULPには影響がないことです。具体的には、疑似ヘッダチェックサムと接続識別に影響はありません。
Conceptually, one could view this approach as if both ULIDs and locators are present in every packet, and as if a header-compression mechanism is applied that removes the need for the ULIDs to be carried in the packets once the compression state has been established. In order for the receiver to re-create a packet with the correct ULIDs, there is a need to include some "compression tag" in the data packets. This serves to indicate the correct context to use for decompression when the locator pair in the packet is insufficient to uniquely identify the context.
ヘッダ圧縮機構が適用される場合の両方ULIDs及びロケータが圧縮状態が確立された後、パケットで搬送されるULIDsの必要性を除去するすべてのパケットに存在し、そしてかのように概念的に、一方がこのアプローチを見ることができます。正しいULIDsでパケットを再作成するために受信機ためには、データ・パケットの一部の「圧縮タグ」を含める必要があります。パケット内のロケータペアが一意のコンテキストを識別するのに不十分である場合、これは圧縮解除に使用する正確なコンテキストを示すために役立ちます。
There are different types of interactions between the Shim6 layer and other protocols. Those interactions are influenced by the usage of the addresses in these other protocols and the impact of the Shim6 mapping on these usages. A detailed analysis of the interactions of different protocols, including the Stream Control Transmission Protocol (SCTP), mobile IP (MIP), and Host Identity Protocol (HIP), can be found in [19]. Moreover, some applications may need to have a richer interaction with the Shim6 sublayer. In order to enable that, an API [23] has been defined to enable greater control and information exchange for those applications that need it.
SHIM6層と他のプロトコルとの間の相互作用の異なる種類があります。これらの相互作用は、これらの他のプロトコルのアドレスを利用し、これらの用途にSHIM6マッピングの影響によって影響されます。ストリーム制御伝送プロトコル（SCTP）、モバイルIP（MIP）、及びホストアイデンティティプロトコル（HIP）を含む異なるプロトコルの相互作用の詳細な分析は、[19]に見出すことができます。また、一部のアプリケーションはSHIM6サブレイヤとの豊かな相互作用を持っている必要があります。それを可能にするために、API [23]それを必要とするアプリケーションのためのより優れた制御と情報交換を可能にするために定義されています。
At the time of this writing, it is not clear what requirements for traffic engineering make sense for the Shim6 protocol, since the requirements must both result in some useful behavior as well as be implementable using a host-to-host locator agility mechanism like Shim6.
これを書いている時点で、要件がいくつかの有用な動作を引き起こすだけでなく、SHIM6のようなホスト間のロケータの俊敏性のメカニズムを使用して実装可能でなければならないの両方から、SHIM6プロトコルの意味をなすものを交通工学のための要件は明らかではありません。
Inherent in a scalable multihoming mechanism that separates the locator function of the IP address from identifying function of the IP address is that each host ends up with multiple locators. This means that, at least for initial contact, it is the remote peer application (or layer working on its behalf) that needs to select an initial ULID, which automatically becomes the initial locator. In the case of Shim6, this is performed by applying RFC 3484 address selection.
IPアドレスの機能を特定のIPアドレスのロケータの機能を分離するスケーラブルマルチホーミングメカニズムに固有の各ホストが複数のロケータで終わるということです。これは、少なくとも最初の接触のために、それは自動的に初期ロケータなる初期ULIDを選択する必要がリモートピア・アプリケーション（またはその代わりに働い層）であることを意味します。 SHIM6の場合、これは、RFC 3484アドレス選択を適用することによって行われます。
This is quite different than the common case of IPv4 multihoming where the site has a single IP address prefix, since in that case the peer performs no destination address selection.
これは、その場合には、ピアがない宛先アドレスの選択を行わないのでサイトは、単一のIPアドレスプレフィックスを有するのIPv4マルチホーミングの一般的なケースよりもかなり異なっています。
Thus, in "single prefix multihoming", the site (and in many cases its upstream ISPs) can use BGP to exert some control of the ingress path used to reach the site. This capability does not by itself exist in "multiple prefix multihoming" approaches such as Shim6. It is conceivable that extensions allowing site or provider guidance of host-based mechanisms could be developed. But it should be noted that traffic engineering via BGP, MPLS, or other similar techniques can still be applied for traffic on each individual prefix; Shim6 does not remove the capability for this. It does provide some additional capabilities for hosts to choose between prefixes.
このように、「単一プレフィックスマルチホーミング」で、サイトは（そして多くの場合、その上流のISP）サイトに到達するために使用される入力パスのいくつかのコントロールを発揮するためにBGPを使用することができます。この機能は、それ自体で、そのようなSHIM6として「複数のプレフィックスマルチホーミング」アプローチには存在しません。ホストベースのメカニズムのサイトまたはプロバイダ指導を許可する拡張子が開発されることが考えられます。しかし、BGP、MPLS、または他の同様の技術を介したトラフィックエンジニアリングは、まだ個々の接頭辞上のトラフィックのために適用することができることに留意すべきです。 SHIM6は、このための機能が削除されません。これは、接頭辞の間で選択するホストのためのいくつかの追加機能を提供します。
These capabilities also carry some risk for non-optimal behaviour when more than one mechanism attempts to correct problems at the same time. However, it should be noted that this is not necessarily a situation brought about by Shim6. A more constrained form of this capability already exists in IPv6, itself, via its support of multiple prefixes and address-selection rules for starting new communications. Even IPv4 hosts with multiple interfaces may have limited capabilities to choose interfaces on which they communicate. Similarly, upper layers may choose different addresses.
複数のメカニズムが同時に問題を修正しようとしたときにこれらの機能は、非最適な行動のためのいくつかのリスクを運びます。しかし、必ずしもSHIM6によってもたらさ状況ではないことに留意すべきです。この機能のより多くの制約形態は、既に新しい通信を開始するための複数のプレフィックスとアドレス選択規則のそのサポートを介して、IPv6の、それ自体に存在します。複数のインターフェイスでさえのIPv4ホストは、それらが通信するのインターフェイスを選択する限られた能力を有していてもよいです。同様に、上側の層は、異なるアドレスを選択することができます。
In general, it is expected that Shim6 is applicable in relatively small sites and individual hosts where BGP-style traffic engineering operations are unavailable, unlikely, or if run with provider-independent addressing, possibly even harmful, considering the growth rates in the global routing table.
一般的には、SHIM6は、BGP-スタイルトラフィックエンジニアリング事業は、グローバルルーティングにおける成長率を考えると、おそらく有害でさえ、そう利用できない、またはプロバイダに依存しないアドレス指定をして実行した場合、比較的小規模なサイトや個々のホストに適用可能であることが期待されますテーブル。
The protocol provides a placeholder, in the form of the Locator Preferences option, that can be used by hosts to express priority and weight values for each locator. This option is merely a placeholder when it comes to providing traffic engineering; in order to use this in a large site, there would have to be a mechanism by which the host can find out what preference values to use, either statically (e.g., some new DHCPv6 option) or dynamically.
プロトコルは、各ロケータの優先度と重み値を表現するためにホストによって使用することができるロケータ環境設定オプションの形態で、プレースホルダを提供します。それはトラフィックエンジニアリングを提供することになると、このオプションは単なるプレースホルダです。大規模なサイトでこれを使用するために、ホストは静的（例えば、いくつかの新しいDHCPv6のオプション）または動的に、プリファレンス値を使用するように何かを見つけることができる機構があることが必要があります。
Thus, traffic engineering is listed as a possible extension in Appendix A.
このように、トラフィックエンジニアリングは、付録Aの可能な拡張としてリストされています
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
This document introduces the following terms:
このドキュメントでは、次の用語が導入されています。
upper-layer protocol (ULP) A protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP; control protocols such as ICMP; routing protocols such as OSPF; and Internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP, such as the Internet Packet Exchange (IPX), AppleTalk, or IP itself.
上位層プロトコル（ULP）直ちにIP上のプロトコル層。例としては、TCPやUDPなどのトランスポートプロトコルです。 ICMPなどの制御プロトコル。 OSPFなどのルーティングプロトコル。インターネットや下位層プロトコルは、インターネットパケット交換（IPX）、AppleTalkの、又はIP自体としてIP（すなわち、でカプセル化された）上に「トンネリング」されます。
interface A node's attachment to a link.
リンクへのノードの接続のインターフェース。
address An IP-layer name that both contains topological significance and acts as a unique identifier for an interface. 128 bits. This document only uses the "address" term in the case where it isn't specific whether it is a locator or an identifier.
両方がトポロジカルな意味が含まれており、インタフェースの一意の識別子として機能IPレイヤ名に取り組みます。 128ビット。この文書では、それはロケータまたは識別子であるかを特定しない場合には、「アドレス」という用語を使用しています。
locator An IP-layer topological name for an interface or a set of interfaces. 128 bits. The locators are carried in the IP address fields as the packets traverse the network.
インタフェースまたはインタフェースのセットのためにIP層トポロジー名をロケータ。 128ビット。パケットがネットワークを横断するロケータがIPアドレスフィールドに運ばれます。
identifier An IP-layer name for an IP-layer endpoint. The transport endpoint name is a function of the transport protocol and would typically include the IP identifier plus a port number.
IP層のエンドポイントのIPレイヤ名を識別子。トランスポートエンドポイント名は、トランスポートプロトコルの関数であり、一般的にIP識別子を加えたポート番号が含まれます。
NOTE: This proposal does not specify any new form
of IP-layer identifier, but still separates the
identifying and locating properties of the IP
addresses.
upper-layer identifier (ULID) An IP address that has been selected for communication with a peer to be used by the upper-layer protocol. 128 bits. This is used for pseudo-header checksum computation and connection identification in the ULP. Different sets of communication to a host (e.g., different connections) might use different ULIDs in order to enable load spreading.
上層識別子（ULID）ピアとの通信のために選択されたIPアドレスは、上位層プロトコルによって使用されます。 128ビット。これはULPに疑似ヘッダチェックサム計算と接続識別のために使用されます。ホスト（例えば、異なる接続）への通信の異なるセットは、拡散負荷を可能にするために異なるULIDsを使用する場合があります。
Since the ULID is just one of the IP locators/
addresses of the node, there is no need for a
separate name space and allocation mechanisms.
address field The Source and Destination Address fields in the IPv6 header. As IPv6 is currently specified, these fields carry "addresses". If identifiers and locators are separated, these fields will contain locators for packets on the wire.
アドレスフィールドIPv6ヘッダーの送信元アドレスと宛先アドレスフィールドに入力します。 IPv6が現在指定されているように、これらのフィールドは、「アドレス」を運びます。識別子とロケータを分離されている場合、これらのフィールドは、ワイヤ上のパケットのためのロケータが含まれています。
FQDN Fully Qualified Domain Name
FQDN完全修飾ドメイン名
ULID-pair context The state that the multihoming shim maintains between a pair of upper-layer identifiers. The context is identified by a Context Tag for each direction of the communication and also by a ULID-pair and a Forked Instance Identifier (see below).
ULID対コンテキストマルチホーミングシムが上層識別子の対の間に維持した状態。コンテキストは、通信の各方向のコンテキストタグによって、またULID対とフォークインスタンス識別子（以下を参照）によって識別されます。
Context Tag Each end of the context allocates a Context Tag for the context. This is used to uniquely associate both received control packets and Shim6 Payload Extension headers as belonging to the context.
コンテキストタグは、コンテキストの各端部は、コンテキストのコンテキストタグを割り当てます。これは、一意の両方を関連付けるために使用されるコンテキストに属すると制御パケットとSHIM6ペイロード拡張ヘッダを受け取りました。
current locator pair Each end of the context has a current locator pair that is used to send packets to the peer. However, the two ends might use different current locator pairs.
現在の位置決め対は、コンテキストの各端部は、ピアにパケットを送信するために使用される現在のロケータの対を有します。しかし、両端が異なる現在のロケータペアを使用する場合があります。
default context At the sending end, the shim uses the ULID pair (passed down from the ULP) to find the context for that pair. Thus, normally, a host can have at most one context for a ULID pair. We call this the "default context".
送信側のデフォルトのコンテキストは、シムは、そのペアのコンテキストを見つけるために、（ULPから受け継が）ULIDのペアを使用しています。したがって、通常は、ホストがULIDペアの最大1つのコンテキストを持つことができます。私たちは、この「デフォルトコンテキスト」と呼びます。
context forking A mechanism that allows ULPs that are aware of multiple locators to use separate contexts for the same ULID pair, in order to be able use different locator pairs for different communication to the same ULID. Context forking causes more than just the default context to be created for a ULID pair.
同じULIDに異なる通信用できる利用異なるロケータペアであるために、同一のULIDペアに対して別個のコンテキストを使用する複数のロケータを認識しているのULPを可能にする機構をフォーク文脈。コンテキストフォークはULIDのペアのために作成するだけで、デフォルトのコンテキストよりも多くなります。
Forked Instance Identifier (FII) In order to handle context forking, a context is identified by a ULID pair and a Forked Context Identifier. The default context has an FII of zero.
コンテキストは、フォーク処理するために（FII）インスタンス識別子をフォークし、コンテキストはULID対と二股コンテキスト識別子によって識別されます。デフォルトのコンテキストは、ゼロのFIIを持っています。
initial contact We use this term to refer to the pre-shim communication when a ULP decides to start communicating with a peer by sending and receiving ULP packets. Typically, this would not invoke any operations in the shim, since the shim can defer the context establishment until some arbitrary, later point in time.
最初の接触我々はULPは、ULPパケットを送受信することにより、ピアとの通信を開始することを決定したときに前シム通信を参照するためにこの用語を使用します。シムは時間である任意の、後の時点まで、コンテキスト確立を延期することができるので、典型的には、これは、シム内の任意の操作を起動しないであろう。
Hash-Based Addresses (HBA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of all the prefixes assigned to the host. See [3].
ハッシュベースアドレス（HBA）インタフェースIDがホストに割り当てられたすべてのプレフィックスの暗号ハッシュから導出されたIPv6アドレスの形式。 [3]を参照してください。
Cryptographically Generated Addresses (CGA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of the public key. See [2].
暗号化生成アドレス（CGA）インタフェースIDは公開鍵の暗号ハッシュから導出されたIPv6アドレスの形式。 [2]を参照してください。
CGA Parameter Data Structure (PDS) The information that CGA and HBA exchange in order to inform the peer of how the interface ID was computed. See [2] and [3].
CGAパラメータデータ構造（PDS）インターフェースIDが計算されたかのピアに通知するための情報、そのCGAおよびHBA交換。参照してください。[2]、[3]。
A, B, and C are hosts. X is a potentially malicious host.
、B、及びCのホストです。 Xは、潜在的に悪質なホストです。
FQDN(A) is the Fully Qualified Domain Name for A.
FQDN（A）はAの完全修飾ドメイン名であります
Ls(A) is the locator set for A, which consists of the locators L1(A), L2(A), ... Ln(A). The locator set is not ordered in any particular way other than maybe what is returned by the DNS. A host might form different locator sets containing different subnets of the host's IP addresses. This is necessary in some cases for security reasons. See Section 16.1.
LS（A）、L2（A）、ロケータL1（A）からなるA、のロケータセットです... Lnの（A）。ロケータのセットは、DNSによって返されるかもしれないもの以外の任意の特定の方法で発注されていません。ホストは、ホストのIPアドレスの異なるサブネットを含むさまざまなロケータセットを形成する可能性があります。これは、セキュリティ上の理由から、場合によっては必要です。 16.1節を参照してください。
ULID(A) is an upper-layer identifier for A. In this proposal, ULID(A) is always one member of A's locator set.
ULID（A）はこの提案ではAの上位層識別子である、ULID（A）は、常にAのロケータセットの1人のメンバーです。
CT(A) is a Context Tag assigned by A.
CT（A）はAによって割り当てられたコンテキストタグであります
STATE (in uppercase) refers to the specific state of the state machine described in Section 6.2
（大文字）状態は、セクション6.2で説明状態マシンの特定の状態を指し
This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. See Section 6 for a description of the conceptual data structures.
この文書はまた、プロトコルの動作と実装は、システム管理者が変更できるようにしなければならない外部変数を記述するために内部の概念的な変数を利用します。その設定は、プロトコルの動作にどのように影響するか、特定の変数名は、その値がどのように変化するか、およびプロトコルの動作を実証するために設けられています。実装は限りその外部の振舞いが本書に記載されたものと一致しているとして、ここに記載された正確な形でそれらを持ってする必要はありません。概念的なデータ構造の説明については、第6章を参照してください。
The design intent is to ensure that the Shim6 protocol is capable of handling path failures independently of the number of IP addresses (locators) available to the two communicating hosts, and independently of which host detects the failure condition.
設計意図はSHIM6プロトコルは、独立して2つの通信ホストが利用可能なIPアドレス（ロケータ）の数のパスの障害を処理することが可能であることを保証することであり、独立してそのホストが障害状態を検出します。
Consider, for example, the case in which both A and B have active Shim6 state and where A has only one locator while B has multiple locators. In this case, it might be that B is trying to send a packet to A, and has detected a failure condition with the current locator pair. Since B has multiple locators, it presumably has multiple ISPs, and (consequently) likely has alternate egress paths toward A. B cannot vary the destination address (i.e., A's locator), since A has only one locator. However, B may need to vary the source address in order to ensure packet delivery.
例えば、AとBの両方がアクティブSHIM6状態とここで、Bは、複数のロケータを有しているAは、一つだけのロケータを有するを有する場合を考えます。この場合、BはAにパケットを送信しようとしている、と現在のロケータペアで障害状態を検出したことかもしれません。 Bは、複数のロケータを有するので、それはおそらく、複数のISPを有し、そしてAは、一つだけのロケータを有するので（その結果）おそらく、宛先アドレス（すなわち、Aのロケータ）を変えることができないA.のBへの代替イグレス経路を有しています。しかし、Bはパケットの配信を保証するために、送信元アドレスを変更する必要があるかもしれません。
In many cases, normal operation of IP routing may cause the packets to follow a path towards the correct (currently operational) egress. In some cases, it is possible that a path may be selected based on the source address, implying that B will need to select a source address corresponding to the currently operating egress. The details of how routing can be accomplished is beyond the scope of this document.
多くの場合、IPルーティングの正常な動作は、パケットが正しい（現在動作）の出口に向かってパスを追従させることができます。場合によっては、パスBが現在動作出力に対応するソースアドレスを選択する必要があることを意味する、送信元アドレスに基づいて選択することができる可能性があります。ルーティングを行うことができる方法の詳細は、このドキュメントの範囲を超えています。
Also, when the site's ISPs perform ingress filtering based on packet source addresses, Shim6 assumes that packets sent with different source and destination combinations have a reasonable chance of making it through the relevant ISP's ingress filters. This can be accomplished in several ways (all outside the scope of this document), such as having the ISPs relax their ingress filters or selecting the egress such that it matches the IP source address prefix. In the case that one egress path has failed but another is operating correctly, it may be necessary for the packet's source (node B in the previous paragraph) to select a source address that corresponds to the operational egress, in order to pass the ISP's ingress filters.
サイトのISPがパケットの送信元アドレスに基づいて入力フィルタリングを行う際にも、SHIM6は異なる送信元と宛先の組み合わせで送信されたパケットは、関連するISPの入口フィルターを通してそれを作るの合理的なチャンスを持っていることを前提としています。これは、ISPがその入口フィルタをリラックスしたか、それはIP送信元アドレスのプレフィックスに一致するように出力を選択するなど（すべて、このドキュメントの範囲外の）いくつかの方法で達成することができます。 1出口経路に障害が発生したが、別のが正しく動作している場合には、ISPの入口を通過するために、動作出力に対応するソースアドレスを選択するパケットの送信元（前の段落におけるノードB）のために必要であるかもしれませんフィルター。
The Shim6 approach assumes that there are no IPv6-to-IPv6 NATs on the paths, i.e., that the two ends can exchange their own notion of their IPv6 addresses and that those addresses will also make sense to their peer.
SHIM6のアプローチは、2つの端部がそのIPv6アドレスの独自の概念を交換し、それらのアドレスは、それらのピアに意味をなすであろうことができること、すなわち、何のIPv6対のIPv6のNATがパス上に存在しないことを前提としています。
The security of the Shim6 protocol relies on the usage of Hash-Based Addresses (HBA) [3] and/or Cryptographically Generated Addresses (CGA) [2]. In the case that HBAs are used, all the addresses assigned to the host that are included in the Shim6 protocol (either as a locator or as a ULID) must be part of the same HBA set. In the case that CGAs are used, the address used as ULID must be a CGA, but the other addresses that are used as locators do not need to be either CGAs or HBAs. It should be noted that it is perfectly acceptable to run the Shim6 protocol between a host that has multiple locators and another host that has a single IP address. In this case, the address of the host with a single address does not need to be an HBA or a CGA.
SHIM6プロトコルのセキュリティは、[2]ハッシュベースアドレス（HBA）の使用に依存している[3]及び/又は暗号化生成アドレス（CGA）。 HBAが使用された場合に、SHIM6プロトコルに含まれているホストに割り当てられたすべてのアドレスは、（いずれかのロケータとして、またはULIDとして）同じHBAセットの一部でなければなりません。 CGAsが使用されている場合は、ULIDとして使用されるアドレスがCGAである必要がありますが、ロケータとして使用されている他のアドレスはCGAsまたはHBAのいずれかである必要はありません。複数のロケータと、単一のIPアドレスを持つ別のホストを持つホスト間SHIM6プロトコルを実行するために完全に受け入れていることに留意すべきです。この場合、1つのアドレスを持つホストのアドレスは、HBAまたはCGAである必要はありません。
The Shim6 protocol operates in several phases over time. The following sequence illustrates the concepts:
SHIM6プロトコルは、時間の経過とともに、いくつかのフェーズで動作します。次のシーケンスは、概念を示しています。
o An application on host A decides to contact an application on host B using some upper-layer protocol. This results in the ULP on host A sending packets to host B. We call this the initial contact. Assuming the IP addresses selected by default address selection [7] and its extensions [9] work, then there is no action by the shim at this point in time. Any shim context establishment can be deferred until later.
OホストA上のアプリケーションは、いくつかの上位層プロトコルを使用して、ホストB上のアプリケーションに連絡することを決定します。これは、我々は最初の接触これを呼び出すB.をホストするためにパケットを送信するホストAにULPになります。デフォルトのアドレス選択によって選択されたIPアドレスを想定すると、[7]とその拡張機能[9]仕事、そしてこの時点でシムによって何のアクションがありません。どれシムコンテキストの確立は後まで延期することができます。
o Some heuristic on A or B (or both) determine that it is appropriate to pay the Shim6 overhead to make this host-to-host communication robust against locator failures. For instance, this heuristic might be that more than 50 packets have been sent or received, or that there was a timer expiration while active packet exchange was in place. This makes the shim initiate the 4-way, context-establishment exchange. The purpose of this heuristic is to avoid setting up a shim context when only a small number of packets is exchanged between two hosts.
AまたはB（あるいはその両方）のいくつかのヒューリスティックOロケータ障害に対するロバストこのホスト間通信を行うためSHIM6オーバーヘッドを支払うことが適切であると判断。例えば、このヒューリスティックは、50個の以上のパケットが送信または受信、またはアクティブなパケット交換が所定の位置にあったタイマ満了があったとされていることがあるかもしれません。これは、シムは、4ウェイ、コンテキスト確立交換を開始できます。このヒューリスティックの目的は、パケットのほんの数は、2つのホスト間で交換されたときにシムコンテキストを設定しないようにすることです。
As a result of this exchange, both A and B will know a list of locators for each other.
この交換の結果として、AとBの両方がお互いのためにロケータのリストを知っているであろう。
If the context-establishment exchange fails, the initiator will then know that the other end does not support Shim6, and will continue with standard (non-Shim6) behavior for the session.
コンテキスト確立交換が失敗した場合、イニシエータは、もう一方の端はSHIM6をサポートしていないことを知っているだろう、とのセッションのための標準（非SHIM6）の動作を継続します。
o Communication continues without any change for the ULP packets. In particular, there are no Shim6 Extension headers added to the ULP packets, since the ULID pair is the same as the locator pair. In addition, there might be some messages exchanged between the shim sublayers for (un)reachability detection.
O通信は、ULPパケットのためそのまま継続されます。 ULIDペアがロケータペアと同じであるので、特に、ULPパケットに添加しないSHIM6拡張ヘッダが存在しません。また、そこにはいくつかのメッセージが（UN）到達可能性検出のためのシムサブレイヤ間で交換される可能性があります。
o At some point in time, something fails. Depending on the approach to reachability detection, there might be some advice from the ULP, or the shim (un)reachability detection might discover that there is a problem.
ある時点でO、何かが失敗します。到達可能性検出へのアプローチによっては、問題があることを発見するかもしれませんULP、またはシム（UN）到達可能性の検出からいくつかのアドバイスがあるかもしれません。
At this point in time, one or both ends of the communication need to probe the different alternate locator pairs until a working pair is found, and then switch to using that locator pair.
この時点で、通信の一方または両方の端部が作業ペアが見つかるまで、異なる代替ロケータペアを探索し、そのロケータペアの使用に切り替える必要があります。
o Once a working alternative locator pair has been found, the shim will rewrite the packets on transmit and tag the packets with the Shim6 Payload Extension header, which contains the receiver's
作業代替ロケータペアが発見されたらO、シムは、送信上のパケットを書き換えて、受信機の含有SHIM6ペイロード拡張ヘッダを持つパケットをタグ付けします
Context Tag. The receiver will use the Context Tag to find the context state, which will indicate which addresses to place in the IPv6 header before passing the packet up to the ULP. The result is that, from the perspective of the ULP, the packet passes unmodified end-to-end, even though the IP routing infrastructure sends the packet to a different locator.
コンテキストタグ。受信機は、ULPまでパケットを渡す前に、IPv6ヘッダに配置するためにどのアドレスを示しますコンテキスト状態を、見つけるために、コンテキストタグを使用します。結果は、ULPの観点から、パケットはIPルーティングインフラストラクチャが異なるロケータにパケットを送信していても、未修飾のエンド・ツー・エンドを通過する、ということです。
o The shim (un)reachability detection will monitor the new locator pair as it monitored the original locator pair, so that subsequent failures can be detected.
後続の故障が検出できるように、それは、元の位置決め対をモニターしたシム（UN）O到達可能性検出は、新しいロケータペアを監視します。
o In addition to failures detected based on end-to-end observations, one endpoint might know for certain that one or more of its locators is not working. For instance, the network interface might have failed or gone down (at layer 2), or an IPv6 address might have become deprecated or invalid. In such cases, the host can signal its peer that trying this address is no longer recommended. This triggers something similar to a failure handling, and a new working locator pair must be found.
Oエンド・ツー・エンドの観測に基づいて検出された障害に加えて、一方のエンドポイントは、そのロケータの1つ以上が動作していないことを確実に知っているかもしれません。例えば、ネットワークインタフェースは失敗している可能性があるか（レイヤ2で）ダウンして、またはIPv6アドレスが非推奨、または無効になっている場合があります。このような場合には、ホストは、このアドレスをしようとしても、もはや推奨されていることをピアに信号を送ることができます。これは、障害処理に似た何かをトリガし、新しい作業ロケータペアを見つけなければなりません。
The protocol also has the ability to express other forms of locator preferences. A change in any preference can be signaled to the peer, which will have made the peer record the new preferences. A change in the preferences might optionally make the peer want to use a different locator pair. In this case, the peer follows the same locator switching procedure as after a failure (by verifying that its peer is indeed present at the alternate locator, etc).
プロトコルはまた、ロケータの好みの他の形態を発現する能力を有しています。任意の好みの変化は、ピアレコード新しい設定を行っているだろう相手に通知することができます。嗜好の変化は、必要に応じてピアが異なるロケータペアを使用したくなるかもしれません。この場合、ピアは、（そのピアが代替ロケータなどで実際に存在することを確認することによって）障害後の手順を切り替える同じロケータに従います。
o When the shim thinks that the context state is no longer used, it can garbage collect the state; there is no coordination necessary with the peer host before the state is removed. There is a recovery message defined to be able to signal when there is no context state, which can be used to detect and recover from both premature garbage collection as well as from complete state loss (crash and reboot) of a peer.
シムは、コンテキスト状態はもはや使用されていることを考えていない場合には、O、それは状態をごみ収集することができます。状態が削除される前に、ピア・ホストとの必要な調整は行われません。ピアの完全な状態の損失（クラッシュやリブート）から同様に検出し、両方の時期尚早なガベージコレクションから回復するために使用することができないコンテキスト状態が存在しないときに信号することができるように定義された復旧メッセージがあります。
The exact mechanism to determine when the context state is no longer used is implementation dependent. For example, an implementation might use the existence of ULP state (where known to the implementation) as an indication that the state is still used, combined with a timer (to handle ULP state that might not be known to the shim sublayer) to determine when the state is likely to no longer be used.
コンテキスト状態がもはや使用されているときを決定しないように正確なメカニズムは実装依存です。例えば、実装は、タイマーと組み合わせ状態がまだ使用されていることを示すように（実装に知られている）ULP状態の存在を、使用する可能性を決定するために（シムサブレイヤに知られていない可能性があるULP状態を処理します）状態はもはや使用される可能性があるとき。
NOTE 1: The ULP packets in Shim6 can be carried completely unmodified as long as the ULID pair is used as the locator pair. After a switch to a different locator pair, the packets are "tagged" with a Shim6
注1：SHIM6におけるULPパケットがあればULID対がロケータペアとして使用される完全修飾されていない行うことができます。異なるロケータ対に切り替えた後、パケットはSHIM6で「タグ付け」されています
Extension header so that the receiver can always determine the context to which they belong. This is accomplished by including an 8-octet Shim6 Payload Extension header before the (extension) headers that are processed by the IP endpoint sublayer and ULPs. If, subsequently, the original ULIDs are selected as the active locator pair, then the tagging of packets with the Shim6 Extension header is no longer necessary.
拡張ヘッダ受信機は常にそれらが属するコンテキストを決定することができるようになっています。これは、IPエンドポイントサブレイヤとのULPによって処理される（拡張）ヘッダの前に8オクテットSHIM6ペイロード拡張ヘッダを含むことによって達成されます。 、その後、元のULIDsアクティブロケータペアとして選択される場合、SHIM6拡張ヘッダを持つパケットのタグ付けは、もはや必要ではありません。
A context between two hosts is actually a context between two ULIDs. The context is identified by a pair of Context Tags. Each end gets to allocate a Context Tag, and once the context is established, most Shim6 control messages contain the Context Tag that the receiver of the message allocated. Thus, at a minimum, the combination of <peer ULID, local ULID, local Context Tag> have to uniquely identify one context. But, since the Shim6 Payload Extension headers are demultiplexed without looking at the locators in the packet, the receiver will need to allocate Context Tags that are unique for all its contexts. The Context Tag is a 47-bit number (the largest that can fit in an 8-octet extension header), while preserving one bit to differentiate the Shim6 signaling messages from the Shim6 header included in data packets, allowing both to use the same protocol number.
2つのホスト間のコンテキストは、実際には2つのULIDs間のコンテキストです。コンテキストは、コンテキストタグのペアによって識別されます。各端部は、コンテキストタグを割り当てるために取得し、コンテキストが確立されると、ほとんどのSHIM6制御メッセージは、メッセージの受信機が割り当てられたコンテキストのタグが含まれています。このように、最低でも、<ピアULID、ローカルULID、ローカルコンテキストタグ>の組み合わせは一意のコンテキストを識別しなければなりません。しかし、SHIM6ペイロード拡張ヘッダがパケット内のロケータを見ずに逆多重化されているため、受信機は、そのすべてのコンテキストのために一意であるコンテキストタグを割り当てる必要があります。コンテキストタグは、47ビットの数値（8オクテット拡張ヘッダに収まることができる最大）、両方が同じプロトコルを使用することができ、データパケットに含まれるSHIM6ヘッダからSHIM6シグナリングメッセージを区別するために1ビットを保持しながら数。
The mechanism for detecting a loss of context state at the peer assumes that the receiver can tell the packets that need locator rewriting, even after it has lost all state (e.g., due to a crash followed by a reboot). This is achieved because, after a rehoming event, the packets that need receive-side rewriting carry the Shim6 Payload Extension header.
ピアでコンテキスト状態の喪失を検出するための機構は、受信機は、それが（リブートに続いて衝突に起因例えば、）すべての状態を失った後も、ロケータの書き換えを必要とするパケットを伝えることができると仮定しています。リホームイベントの後、 - 受信側書き換え必要パケットがSHIM6ペイロード拡張ヘッダを運び、これが達成されます。
It has been asserted that it will be important for future ULPs -- in particular, future transport protocols -- to be able to control which locator pairs are used for different communication. For instance, host A and host B might communicate using both Voice over IP (VoIP) traffic and ftp traffic, and those communications might benefit from using different locator pairs. However, the basic Shim6 mechanism uses a single current locator pair for each context; thus, a single context cannot accomplish this.
将来のULPのために重要になるだろうと主張してきた - 特に、将来のトランスポートプロトコルは - ロケータペアは異なる通信に使用するかを制御できるようにします。例えば、ホストAとホストBは、ボイスオーバーIP（VoIP）のトラフィックおよびFTPトラフィックの両方を使用して通信する可能性があり、それらの通信は、異なるロケータペアを使用することから利益を得るかもしれません。しかし、基本的なSHIM6機構は、各コンテキストのための単一の電流ロケータペアを使用します。このように、単一のコンテキストは、これを達成することはできません。
For this reason, the Shim6 protocol supports the notion of context forking. This is a mechanism by which a ULP can specify (using some API not yet defined) that a context, e.g., the ULID pair <A1, B2>, should be forked into two contexts. In this case, the forked-off context will be assigned a non-zero Forked Instance Identifier, while the default context has FII zero.
このため、SHIM6プロトコルは、コンテキストフォークの概念をサポートしています。このコンテキストは、例えば、ULID対<A1、B2>、二つのコンテキストに二股されるべきであることを（まだ定義され、いくつかのAPIを使用して）ULP指定できるメカニズムです。デフォルトコンテキストはFIIゼロを有している。この場合、二股オフコンテキストは、非ゼロフォークトインスタンス識別子を割り当てられます。
The Forked Instance Identifier (FII) is a 32-bit identifier that has no semantics in the protocol other than being part of the tuple that identifies the context. For example, a host might allocate FIIs as sequential numbers for any given ULID pair.
フォークトインスタンス識別子（FII）はコンテキストを識別するタプルの一部である以外のプロトコルには意味を持たない32ビットの識別子です。例えば、ホストは、任意の所与のULIDペアのシーケンシャル番号としてFIIsを割り当てるかもしれません。
No other special considerations are needed in the Shim6 protocol to handle forked contexts.
他の特別な考慮事項は、フォークコンテキストを処理するためにSHIM6プロトコルで必要とされていません。
Note that forking as specified does NOT allow A to be able to tell B that certain traffic (a 5-tuple?) should be forked for the reverse direction. The Shim6 forking mechanism as specified applies only to the sending of ULP packets. If some ULP wants to fork for both directions, it is up to the ULP to set this up and then instruct the shim at each end to transmit using the forked context.
指定されたように分岐する特定のトラフィック（5タプルは？）逆方向のために二股されるべきであることをBに伝えることができるように許可していないことに留意されたいです。指定されているようSHIM6フォークメカニズムは唯一のULPパケットの送信に適用されます。いくつかのULPは、両方向のためにフォークを希望する場合は、これを設定して、フォークコンテキストを使用して送信するために各端にシムを指示するULP次第です。
Several API extensions have been discussed for Shim6, but their actual specification is out of scope for this document. The simplest one would be to add a socket option to be able to have traffic bypass the shim (not create any state and not use any state created by other traffic). This could be an IPV6_DONTSHIM socket option. Such an option would be useful for protocols, such as DNS, where the application has its own failover mechanism (multiple NS records in the case of DNS) and using the shim could potentially add extra latency with no added benefits.
いくつかのAPIの拡張はSHIM6のために議論されてきたが、その実際の仕様はこの文書の範囲外です。最も簡単な1シムは（どのような状態を作成していないし、他のトラフィックによって作成された任意の状態を使用していない）トラフィックバイパスを持つことができるようにソケットオプションを追加することです。これはIPV6_DONTSHIMソケットオプションである可能性があります。このようなオプションは、アプリケーションが独自のフェイルオーバー・メカニズム（DNSの場合は、複数のNSレコード）と潜在的に無添加の利点と余分な遅延を追加することができ、シムを使用しているDNS、などのプロトコルのために有用であろう。
Some other API extensions are discussed in Appendix A. The actual API extensions are defined in [23].
他のいくつかのAPIの拡張は、実際のAPIの拡張は[23]で定義されている付録Aで説明されています。
The mechanisms are secured using a combination of techniques:
機構は、技術の組み合わせを使用して固定されています。
o The HBA technique [3] for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else.
O HBA技術[3]他のどこかにパケットストリームをリダイレクトからの攻撃を防ぐためにロケータを検証します。
o Requiring a Reachability Probe+Reply (defined in [4]) before a new locator is used as the destination, in order to prevent 3rd party flooding attacks.
到達可能性プローブ+返信を要求oをサードパーティのフラッディング攻撃を防止するために、新たなロケータを宛先として使用される前に（[4]で定義されます）。
o The first message does not create any state on the responder. Essentially, a 3-way exchange is required before the responder creates any state. This means that a state-based DoS attack (trying to use up all memory on the responder) at least provides an IPv6 address that the attacker was using.
O最初のメッセージは、レスポンダ上の任意の状態を作成しません。応答者がどのような状態を作成する前に、基本的に、3ウェイの交換が必要です。これは、少なくとも、攻撃者が使用していたIPv6アドレスを提供し、状態ベースのDoS攻撃（レスポンダー上のすべてのメモリを使用しようとしている）ことを意味します。
o The context-establishment messages use nonces to prevent replay attacks and to prevent off-path attackers from interfering with the establishment.
oをコンテキスト確立メッセージは、リプレイ攻撃を防ぐためにと設立に干渉オフパス攻撃を防ぐためにナンスを使用しています。
o Every control message of the Shim6 protocol, past the context establishment, carries the Context Tag assigned to the particular context. This implies that an attacker needs to discover that Context Tag before being able to spoof any Shim6 control message. Such discovery probably requires any potential attacker to be along the path in order to sniff the Context Tag value. The result is that through this technique, the Shim6 protocol is protected against off-path attackers.
O SHIM6プロトコルのすべての制御メッセージは、コンテキスト確立を過ぎて、特定のコンテキストに割り当てられたコンテキストタグを運びます。これは、攻撃者が任意のSHIM6制御メッセージを偽装できるようになる前に、そのコンテキストタグを発見する必要があることを意味します。このような発見は、おそらくコンテキストタグ値を盗聴するために、パスに沿うように任意の潜在的な攻撃者が必要です。その結果、この技術によって、SHIM6プロトコルがオフパス攻撃から保護されることです。
The Shim6 context establishment is accomplished using four messages; I1, R1, I2, R2. Normally, they are sent in that order from initiator and responder, respectively. Should both ends attempt to set up context state at the same time (for the same ULID pair), then their I1 messages might cross in flight, and result in an immediate R2 message. (The names of these messages are borrowed from HIP [20].)
SHIM6コンテキスト確立は、4つのメッセージを使用して達成されます。 I1、R1、I2、R2。通常、これらはそれぞれ、イニシエータとレスポンダから順に送信されます。両方が（同じULIDペアの）同時にコンテキスト状態を設定しようとする試みを終了する必要があり、その後そのI1メッセージは、飛行中交差、および即時R2メッセージをもたらすかもしれません。 （これらのメッセージの名前は、[20] HIPから借用されています。）
R1bis and I2bis messages are defined; they are used to recover a context after it has been lost. An R1bis message is sent when a Shim6 control or Shim6 Payload Extension header arrives and there is no matching context state at the receiver. When such a message is received, it will result in the re-creation of the Shim6 context using the I2bis and R2 messages.
R1bisとI2bisメッセージが定義されています。彼らは、それが失われた後にコンテキストを回復するために使用されています。 SHIM6制御又はSHIM6ペイロード拡張ヘッダが到着と一致するコンテキスト状態が受信機に存在しない場合R1bisメッセージが送信されます。そのようなメッセージが受信されると、それはI2bis及びR2メッセージを使用してSHIM6コンテキストの再作成をもたらすであろう。
The peers' lists of locators are normally exchanged as part of the context-establishment exchange. But the set of locators might be dynamic. For this reason, there are Update Request and Update Acknowledgement messages as well as a Locator List option.
ロケータのピアのリストは、通常、コンテキスト確立交換の一部として交換されています。しかし、ロケータのセットは動的なものかもしれません。このため、更新要求と更新肯定応答メッセージだけでなく、ロケータリストのオプションがあります。
Even when the list of locators is fixed, a host might determine that some preferences might have changed. For instance, it might determine that there is a locally visible failure that implies that some locator(s) are no longer usable. This uses a Locator Preferences option in the Update Request message.
ロケータのリストが固定されている場合でも、ホストは、いくつかの設定が変更された可能性があると判断する場合があります。例えば、それはいくつかのロケータ（s）がもはや使用可能であることを意味しないローカルに見える障害があると判断かもしれません。これは、更新要求メッセージでロケータ環境設定オプションを使用しています。
The mechanism for (un)reachability detection is called Forced Bidirectional Communication (FBD). FBD uses a Keepalive message which is sent when a host has received packets from its peer but has not yet sent any packets from its ULP to the peer. The message type is reserved in this document, but the message format and processing rules are specified in [4].
（UN）到達可能性を検出するためのメカニズムは、強制双方向通信（FBD）と呼ばれています。 FBDは、ホストがそのピアからのパケットを受信したときに送信されるが、まだピアにそのULPから任意のパケットを送信していないキープアライブメッセージを使用します。メッセージタイプは、本書では予約されているが、メッセージ・フォーマットおよび処理ルールは、[4]で指定されています。
In addition, when the context is established and there is a subsequent failure, there needs to be a way to probe the set of locator pairs to efficiently find a working pair. This document reserves a Probe message type, with the packet format and processing rules specified in [4].
コンテキストが確立され、その後の障害があるれている場合に加えて、効率的に作業ペアを見つけるために、ロケータペアのセットをプローブする方法が必要です。この文書では、[4]で指定されたパケットフォーマット及び処理ルールを、Probeメッセージのタイプを予約します。
The above Probe and Keepalive messages assume we have an established ULID-pair context. However, communication might fail during the initial contact (that is, when the application or transport protocol is trying to set up some communication). This is handled using the mechanisms in the ULP to try different address pairs as specified in [7] and [9]. In future versions of the protocol, and with a richer API between the ULP and the shim, the shim might be able to help optimize discovering a working locator pair during initial contact. This is for further study.
上記プローブとキープアライブメッセージは、我々が確立ULIDペアコンテキストを持っていると仮定します。 （アプリケーションまたはトランスポートプロトコルは、いくつかの通信を設定しようとしているとき、つまり）しかし、通信が最初の接触時に失敗することがあります。これで指定されるように異なるアドレスの組み合わせを試してULPにメカニズムを使用して処理されている[7]、[9]。プロトコルの将来のバージョンでは、とULPとシムの間に豊かなAPIで、シムは、最初の接触時の作業ロケータペアを発見する最適化を支援することができるかもしれません。これは今後の検討課題です。
Since the shim is placed between the IP endpoint sublayer and the IP routing sublayer, the Shim header will be placed before any Endpoint Extension headers (Fragmentation headers, Destination Options header, AH, ESP) but after any routing-related headers (Hop-by-Hop Extensions header, Routing header, and a Destinations Options header, which precedes a Routing header). When tunneling is used, whether IP-in-IP tunneling or the special form of tunneling that Mobile IPv6 uses (with Home Address options and Routing header type 2), there is a choice whether the shim applies inside the tunnel or outside the tunnel, which affects the location of the Shim6 header.
シムは、IPエンドポイントサブレイヤとIPルーティングサブレイヤとの間に配置されているので、シムヘッダは、任意のエンドポイント拡張ヘッダ（フラグメンテーションヘッダー、宛先オプションヘッダ、AH、ESP）の前に任意ルーティング関連ヘッダーの後に配置される（ホップバイ-Hop拡張ヘッダ、ルーティングヘッダ、ルーティングヘッダの前に目的地オプションヘッダ）。トンネリングを使用する場合、IPインIPトンネル又はモバイルIPv6は、（ホームアドレスオプションとルーティングヘッダタイプ2で）使用するトンネルの特別な形態は、シムがトンネル内やトンネルの外側に適用されるかどうかの選択肢があるかどうか、これSHIM6ヘッダの位置に影響を与えます。
In most cases, IP-in-IP tunnels are used as a routing technique; thus, it makes sense to apply them on the locators, which means that the sender would insert the Shim6 header after any IP-in-IP encapsulation. This is what occurs naturally when routers apply IP-in-IP encapsulation. Thus, the packets would have:
ほとんどの場合、IPインIPトンネルはルーティング技術として使用されています。したがって、送信者が任意のIP-in-IPカプセル化した後SHIM6ヘッダを挿入することを意味し、ロケータにそれらを適用することは理にかなって。これは、ルータがIP-in-IPカプセル化を適用したときに自然に発生するものです。このように、パケットがなければなりません。
o Outer IP header
O外部IPヘッダ
o Inner IP header o Shim6 Extension header (if needed)
O SHIM6拡張ヘッダO内側のIPヘッダ（必要な場合）
o ULP
ああULP
But the shim can also be used to create "shimmed tunnels", i.e., where an IP-in-IP tunnel uses the shim to be able to switch the tunnel endpoint addresses between different locators. In such a case, the packets would have:
しかし、シムはまた、IPインIPトンネルが異なるロケータとの間のトンネルのエンドポイントアドレスを切り替えることができるようにシムを使用して「シムトンネル」、すなわち、作成するために使用することができます。そのような場合には、パケットがなければなりません。
o Outer IP header
O外部IPヘッダ
o Shim6 Extension header (if needed)
O SHIM6拡張ヘッダ（必要な場合）
o Inner IP header
インナーIPヘッダO
o ULP
ああULP
In any case, the receiver behavior is well-defined; a receiver processes the Extension headers in order. However, the precise interaction between Mobile IPv6 and Shim6 is for further study; it might make sense to have Mobile IPv6 operate on locators as well, meaning that the shim would be layered on top of the MIPv6 mechanism.
いずれの場合においても、受信機の動作は、明確に定義されています。受信機は順に拡張ヘッダーを処理します。しかし、モバイルIPv6とSHIM6の間の正確な相互作用は、今後の検討課題です。それはシムがMIPv6のメカニズムの上に階層化されることを意味し、モバイルIPv6が同様にロケータを操作していても意味があります。
The Shim6 messages are all carried using a new IP protocol number (140). The Shim6 messages have a common header (defined below) with some fixed fields, followed by type-specific fields.
SHIM6メッセージは、すべての新しいIPプロトコル番号（140）を使用して実施されます。 SHIM6メッセージはタイプ固有のフィールドに続くいくつかの固定フィールドと共通ヘッダ（以下に定義）を有します。
The Shim6 messages are structured as an IPv6 Extension header since the Shim6 Payload Extension header is used to carry the ULP packets after a locator switch. The Shim6 control messages use the same extension header formats so that a single "protocol number" needs to be allowed through firewalls in order for Shim6 to function across the firewall.
SHIM6ペイロード拡張ヘッダは、ロケータスイッチの後ULPパケットを搬送するために使用されているのでSHIM6メッセージは、IPv6拡張ヘッダとして構成されています。単一の「プロトコル番号」がSHIM6がファイアウォールを越えて機能するために、ファイアウォールの通過を許可する必要があるようにSHIM6制御メッセージは、同じ拡張ヘッダフォーマットを使用します。
The first 17 bits of the Shim6 header is common for the Shim6 Payload Extension header and for the control messages. It looks as follows:
SHIM6ヘッダの最初の17ビットはSHIM6ペイロード拡張ヘッダおよび制御メッセージに共通です。これは次のようになります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: The payload that follows this header.
次ヘッダ：このヘッダに続くペイロード。
Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in 8-octet units, not including the first 8 octets.
HDR拡張レン：8ビットの符号なし整数。最初の8つのオクテットを含まない8オクテット単位でSHIM6ヘッダの長さ。
P: A single bit to distinguish Shim6 Payload Extension headers from control messages.
P：制御メッセージからSHIM6ペイロード拡張ヘッダを区別するための単一ビット。
Shim6 signaling packets may not be larger than 1280 bytes, including the IPv6 header and any intermediate headers between the IPv6 header and the Shim6 header. One way to meet this requirement is to omit part of the locator address information if, with this information included, the packet would become larger than 1280 bytes. Another option is to perform option engineering, dividing into different Shim6 messages the information to be transmitted. An implementation may impose administrative restrictions to avoid excessively large Shim6 packets, such as a limitation on the number of locators to be used.
SHIM6シグナリングパケットは、IPv6ヘッダとIPv6ヘッダとSHIM6ヘッダとの間の任意の中間ヘッダを含む、より大きい1280バイトでなくてもよいです。この要件を満たすための一つの方法は、パケットが1280バイトより大きくなるだろう、この情報が含まれて、場合ロケータアドレス情報の一部を省略することです。別のオプションは、送信する情報が異なるSHIM6メッセージに分割し、オプションのエンジニアリングを実行することです。実装は、そのようなロケータの数を限定するものとして過大SHIM6パケットは、使用されることを回避するための管理制限を課すことができます。
The Shim6 Payload Extension header is used to carry ULP packets where the receiver must replace the content of the Source and/or Destination fields in the IPv6 header before passing the packet to the ULP. Thus, this extension header is required when the locator pair that is used is not the same as the ULID pair.
SHIM6ペイロード拡張ヘッダは、受信機がULPにパケットを渡す前に、IPv6ヘッダーのソースおよび/または宛先フィールドの内容を交換する必要がありULPパケットを搬送するために使用されます。使用されるロケータペアはULIDペアと同じでない場合したがって、この拡張ヘッダが必要です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | 0 |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: The payload that follows this header.
次ヘッダ：このヘッダに続くペイロード。
Hdr Ext Len: 0 (since the header is 8 octets).
HDR拡張レン：0（ヘッダは8つのオクテットであるため）。
P: Set to one. A single bit to distinguish this from the Shim6 control messages.
P：1に設定します。 SHIM6制御メッセージからこれを区別するための単一のビット。
Receiver Context Tag: 47-bit unsigned integer. Allocated by the receiver to identify the context.
レシーバコンテキストタグ：47ビットの符号なし整数。コンテキストを識別するために受信機によって割り当てられます。
The common part of the header has a Next Header field and a Header Extension Length field that are consistent with the other IPv6 Extension headers, even if the Next Header value is always "NO NEXT HEADER" for the control messages.
ヘッダの共通部分は、次のヘッダー値が制御メッセージ用に常に「NO次ヘッダ」でない場合でも、次のヘッダフィールドと他のIPv6拡張ヘッダと一致するヘッダ拡張長フィールドを有しています。
The Shim6 headers must be a multiple of 8 octets; hence, the minimum size is 8 octets.
SHIM6ヘッダは8つのオクテットの倍数でなければなりません。従って、最小サイズは8つのオクテットです。
The common Shim6 Control message header is as follows:
次のように一般的SHIM6制御メッセージヘッダです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |P| Type |Type-specific|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type-specific format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59).
次ヘッダー：8ビットセレクタ。通常NO_NXT_HDR（59）に設定します。
Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in 8-octet units, not including the first 8 octets.
HDR拡張レン：8ビットの符号なし整数。最初の8つのオクテットを含まない8オクテット単位でSHIM6ヘッダの長さ。
P: Set to zero. A single bit to distinguish this from the Shim6 Payload Extension header.
P：ゼロに設定してください。 SHIM6ペイロード拡張ヘッダからこれを区別するための単一ビット。
Type: 7-bit unsigned integer. Identifies the actual message from the table below. Type codes 0-63 will not trigger R1bis messages on a missing context, while codes 64-127 will trigger R1bis.
タイプ：7ビットの符号なし整数。以下の表から実際のメッセージを識別する。コード64-127はR1bisをトリガーする一方、タイプ・コード0-63は、不足している状況にR1bisメッセージをトリガしません。
S: A single bit set to zero that allows Shim6 and HIP to have a common header format yet still distinguishes between Shim6 and HIP messages.
S：SHIM6とHIPがまだ共通ヘッダのフォーマットを持つことができ、ゼロに設定された単一のビットが依然としてSHIM6とHIPメッセージを区別する。
Checksum: 16-bit unsigned integer. The checksum is the 16-bit one's complement of the one's complement sum of the entire Shim6 header message, starting with the Shim6
チェックサム：16ビット符号なし整数。チェックサムはSHIM6始まる、全体SHIM6ヘッダーメッセージの1の補数和の16ビットの1の補数であります
Next Header field and ending as indicated by the Hdr
Ext Len. Thus, when there is a payload following the
Shim6 header, the payload is NOT included in the Shim6
checksum. Note that, unlike protocols like ICMPv6,
there is no pseudo-header checksum part of the
checksum; this provides locator agility without having
to change the checksum.
Type-specific: Part of the message that is different for different message types.
タイプ固有：異なるメッセージタイプの異なるメッセージの一部。
+------------+----------------------------------------------------+
| Type Value | Message |
+------------+----------------------------------------------------+
| 1 | I1 (1st establishment message from the initiator) |
| 2 | R1 (1st establishment message from the responder) |
| 3 | I2 (2nd establishment message from the initiator) |
| 4 | R2 (2nd establishment message from the responder) |
| 5 | R1bis (Reply to reference to non-existent context) |
| 6 | I2bis (Reply to an R1bis message) |
| 64 | Update Request |
| 65 | Update Acknowledgement |
| 66 | Keepalive |
| 67 | Probe Message |
| 68 | Error Message |
+------------+----------------------------------------------------+
Table 1
表1
The I1 message is the first message in the context-establishment exchange.
I1メッセージは、コンテキスト確立交換の最初のメッセージです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 1 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも1は、ヘッダは16オクテットであるからです。
Type: 1
タイプ：1
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Initiator Context Tag: 47-bit field. The Context Tag that the initiator has allocated for the context.
イニシエータコンテキストタグ：47ビットのフィールド。イニシエータは、コンテキストに割り当てられたコンテキストタグ。
Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the responder will return in the R1 message.
イニシエータノンス：32ビット符号なし整数。レスポンダがR1メッセージに返されイニシエータで撮像された乱数、。
The following options are defined for this message:
次のオプションは、このメッセージのために定義されています。
ULID pair: When the IPv6 source and destination addresses in the IPv6 header does not match the ULID pair, this option MUST be included. An example of this is when recovering from a lost context.
ULIDペア：IPv6ヘッダーのIPv6ソースと宛先アドレスがULIDペアと一致しない場合、このオプションを含まなければなりません。失われた状況から回復するときに、この例です。
Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a Forked Instance Identifier option MUST be included to distinguish this new instance from the existent one.
フォークインスタンス識別子：同じULID対で存在コンテキストの別のインスタンスが作成されると、フォーク状インスタンス識別子オプションは存在しないものから、この新しいインスタンスを区別するために含まれなければなりません。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
The R1 message is the second message in the context-establishment exchange. The responder sends this in response to an I1 message, without creating any state specific to the initiator.
R1メッセージは、コンテキスト確立交換における第2のメッセージです。レスポンダは、イニシエータに固有の状態を作成することなく、I1メッセージに応答してこれを送信します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 2 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも1は、ヘッダは16オクテットであるからです。
Type: 2
タイプ：2
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Reserved2: 16-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved2：16ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Initiator Nonce: 32-bit unsigned integer. Copied from the I1 message.
イニシエータノンス：32ビット符号なし整数。 I1メッセージからコピーされました。
Responder Nonce: 32-bit unsigned integer. A number picked by the responder, which the initiator will return in the I2 message.
レスポンダノンス：32ビット符号なし整数。イニシエータはI2メッセージに返されレスポンダによって採取数。
The following options are defined for this message:
次のオプションは、このメッセージのために定義されています。
Responder Validator: Variable length option. This option MUST be included in the R1 message. Typically, it contains a hash generated by the responder, which the responder uses together with the Responder Nonce value to verify that an I2 message is indeed sent in response to an R1 message, and that the parameters in the I2 message are the same as those in the I1 message.
レスポンダバリ：可変長オプション。このオプションは、R1メッセージに含まれなければなりません。典型的には、レスポンダがI2メッセージが実際R1メッセージに応答して送信されることを確認するために、レスポンダノンス値とともに使用応答によって生成されたハッシュを含み、I2メッセージのパラメータは、それらと同じであることI1メッセージインチ
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
The I2 message is the third message in the context-establishment exchange. The initiator sends this in response to an R1 message, after checking the Initiator Nonce, etc.
I2メッセージは、コンテキスト確立交換における第3のメッセージです。イニシエータはなど、イニシエータnonceを確認した後、R1メッセージに応答して、これを送信します
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 3 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 2, since the header is 24 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも2、ヘッダは24オクテットであるからです。
Type: 3
タイプ：3
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Initiator Context Tag: 47-bit field. The Context Tag that the initiator has allocated for the context.
イニシエータコンテキストタグ：47ビットのフィールド。イニシエータは、コンテキストに割り当てられたコンテキストタグ。
Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the responder will return in the R2 message.
イニシエータノンス：32ビット符号なし整数。レスポンダがR2メッセージに返されイニシエータで撮像された乱数、。
Responder Nonce: 32-bit unsigned integer. Copied from the R1 message.
レスポンダノンス：32ビット符号なし整数。 R1メッセージからコピーされました。
Reserved2: 32-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Needed to make the options start on a multiple of 8 octet boundary.)
Reserved2：32ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。 （オプションは8オクテット境界の倍数に開始するために必要。）
The following options are defined for this message:
次のオプションは、このメッセージのために定義されています。
Responder Validator: Variable length option. This option MUST be included in the I2 message and MUST be generated by copying the Responder Validator option received in the R1 message.
レスポンダバリ：可変長オプション。このオプションはI2メッセージに含まれなければならないとR1メッセージで受信レスポンダ検証オプションをコピーして生成されなければなりません。
ULID pair: When the IPv6 source and destination addresses in the IPv6 header do not match the ULID pair, this option MUST be included. An example of this is when recovering from a lost context.
ULIDペア：IPv6ヘッダーのIPv6ソースアドレスと宛先アドレスがULIDペアと一致しない場合、このオプションを含まなければなりません。失われた状況から回復するときに、この例です。
Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a Forked Instance Identifier option MUST be included to distinguish this new instance from the existent one.
フォークインスタンス識別子：同じULID対で存在コンテキストの別のインスタンスが作成されると、フォーク状インスタンス識別子オプションは存在しないものから、この新しいインスタンスを区別するために含まれなければなりません。
Locator List: Optionally sent when the initiator immediately wants to tell the responder its list of locators. When it is sent, the necessary HBA/CGA information for verifying the locator list MUST also be included.
ロケータリスト：イニシエータは、直ちに応答にロケータのリストを伝えたいときに必要に応じて送信されます。それが送信されると、ロケータリストを検証するために必要なHBA / CGAの情報も含まれなければなりません。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
ロケータ設定：ロケータが等しい優先度を持っていないすべてのない時に必要に応じて送信されます。
CGA Parameter Data Structure: This option MUST be included in the I2 message when the locator list is included so the receiver can verify the locator list.
CGAパラメータデータ構造は：受信機は、ロケータリストを確認することができますので、ロケータリストが含まれている場合、このオプションはI2メッセージに含まれなければなりません。
CGA Signature: This option MUST be included in the I2 message when some of the locators in the list use CGA (and not HBA) for verification.
CGAの署名：リスト内のロケータのいくつかは検証のためにCGA（やないHBA）を使用する場合、このオプションはI2メッセージに含まれなければなりません。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
The R2 message is the fourth message in the context-establishment exchange. The responder sends this in response to an I2 message. The R2 message is also used when both hosts send I1 messages at the same time and the I1 messages cross in flight.
R2メッセージは、コンテキスト確立交換における第4のメッセージです。レスポンダはI2メッセージに応答して、これを送信します。両方のホストが同時にI1メッセージを送信し、I1メッセージが飛行中に交差するときR2メッセージも使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 4 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Responder Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも1は、ヘッダは16オクテットであるからです。
Type: 4
タイプ：4
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Responder Context Tag: 47-bit field. The Context Tag that the responder has allocated for the context.
レスポンダコンテキストタグ：47ビットのフィールド。応答者は、コンテキストに割り当てたコンテキストタグ。
Initiator Nonce: 32-bit unsigned integer. Copied from the I2 message.
イニシエータノンス：32ビット符号なし整数。 I2メッセージからコピーされました。
The following options are defined for this message:
次のオプションは、このメッセージのために定義されています。
Locator List: Optionally sent when the responder immediately wants to tell the initiator its list of locators. When it is sent, the necessary HBA/CGA information for verifying the locator list MUST also be included.
ロケータリスト：応答者がすぐにイニシエータにロケータのリストを伝えたいときに必要に応じて送信されます。それが送信されると、ロケータリストを検証するために必要なHBA / CGAの情報も含まれなければなりません。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
ロケータ設定：ロケータが等しい優先度を持っていないすべてのない時に必要に応じて送信されます。
CGA Parameter Data Structure: Included when the locator list is included so the receiver can verify the locator list.
CGAパラメータデータ構造：受信機は、ロケータリストを確認することができますので、ロケータリストが含まれている場合に含まれます。
CGA Signature: Included when some of the locators in the list use CGA (and not HBA) for verification.
CGAの署名：リスト内のロケータのいくつかは検証のためにCGA（やないHBA）を使用する場合に含まれます。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
Should a host receive a packet with a Shim6 Payload Extension header or Shim6 control message with type code 64-127 (such as an Update or Probe message), and the host does not have any context state for the received Context Tag, then it will generate a R1bis message.
ホストは、タイプコード64-127（そのような更新またはプローブメッセージとして）とSHIM6ペイロード拡張ヘッダまたはSHIM6制御メッセージとパケットを受信しなければならない、そしてホストは、それがし、受信したコンテキストタグのどのようなコンテキスト状態を有していませんR1bisメッセージを生成します。
This message allows the sender of the packet referring to the non-existent context to re-establish the context with a reduced context-establishment exchange. Upon the reception of the R1bis message, the receiver can proceed with re-establishing the lost context by directly sending an I2bis message.
このメッセージは減少し、コンテキスト確立交換してコンテキストを再確立するために存在しないコンテキストを参照するパケットの送信者を可能にします。 R1bisメッセージを受信すると、受信機は、直接I2bisメッセージを送信することにより失われたコンテキストを再確立を進めることができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 5 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Packet Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも1は、ヘッダは16オクテットであるからです。
Type: 5
タイプ：5
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Packet Context Tag: 47-bit unsigned integer. The Context Tag contained in the received packet that triggered the generation of the R1bis message.
パケットコンテキストタグ：47ビットの符号なし整数。 R1bisメッセージの生成をトリガし、受信したパケットに含まれるコンテキスト・タグ。
Responder Nonce: 32-bit unsigned integer. A number picked by the responder which the initiator will return in the I2bis message.
レスポンダノンス：32ビット符号なし整数。イニシエータはI2bisメッセージに返されレスポンダによって採取数。
The following options are defined for this message:
次のオプションは、このメッセージのために定義されています。
Responder Validator: Variable length option. Typically, a hash generated by the responder, which the responder uses together with the Responder Nonce value to verify that an I2bis message is indeed sent in response to an R1bis message.
レスポンダバリ：可変長オプション。典型的には、レスポンダはレスポンダノンス値とともに使用応答によって生成されたハッシュは、I2bisメッセージが実際R1bisメッセージに応答して送信されていることを確認します。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
The I2bis message is the third message in the context-recovery exchange. This is sent in response to an R1bis message, after checking that the R1bis message refers to an existing context, etc.
I2bisメッセージは、コンテキスト回復交換における第3のメッセージです。これはR1bisメッセージは既存のコンテキスト、等を意味することを確認した後、R1bisメッセージに応答して送られます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 6 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Packet Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 3, since the header is 32 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも3は、ヘッダは32オクテットであるからです。
Type: 6
タイプ：6
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Initiator Context Tag: 47-bit field. The Context Tag that the initiator has allocated for the context.
イニシエータコンテキストタグ：47ビットのフィールド。イニシエータは、コンテキストに割り当てられたコンテキストタグ。
Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the responder will return in the R2 message.
イニシエータノンス：32ビット符号なし整数。レスポンダがR2メッセージに返されイニシエータで撮像された乱数、。
Responder Nonce: 32-bit unsigned integer. Copied from the R1bis message.
レスポンダノンス：32ビット符号なし整数。 R1bisメッセージからコピーされました。
Reserved2: 49-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Note that 17 bits are not sufficient since the options need to start on a multiple-of-8-octet boundary.)
Reserved2：49ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。 （オプションは、複数の-8オクテット境界上で開始する必要があるので、17ビットが十分でないことに注意してください。）
Packet Context Tag: 47-bit unsigned integer. Copied from the Packet Context Tag field contained in the received R1bis.
パケットコンテキストタグ：47ビットの符号なし整数。受信R1bisに含まれるパケットコンテキストタグフィールドからコピーされます。
The following options are defined for this message:
次のオプションは、このメッセージのために定義されています。
Responder Validator: Variable length option. Just a copy of the Responder Validator option in the R1bis message.
レスポンダバリ：可変長オプション。 R1bisメッセージでレスポンダ検証オプションのちょうどコピー。
ULID pair: When the IPv6 source and destination addresses in the IPv6 header do not match the ULID pair, this option MUST be included.
ULIDペア：IPv6ヘッダーのIPv6ソースアドレスと宛先アドレスがULIDペアと一致しない場合、このオプションを含まなければなりません。
Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a Forked Instance Identifier option is included to distinguish this new instance from the existent one.
フォークインスタンス識別子：同じULID対で存在コンテキストの別のインスタンスが作成されると、フォーク状インスタンス識別子オプションが存在しないものから、この新しいインスタンスを区別するために含まれています。
Locator List: Optionally sent when the initiator immediately wants to tell the responder its list of locators. When it is sent, the necessary HBA/CGA information for verifying the locator list MUST also be included.
ロケータリスト：イニシエータは、直ちに応答にロケータのリストを伝えたいときに必要に応じて送信されます。それが送信されると、ロケータリストを検証するために必要なHBA / CGAの情報も含まれなければなりません。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
ロケータ設定：ロケータが等しい優先度を持っていないすべてのない時に必要に応じて送信されます。
CGA Parameter Data Structure: Included when the locator list is included so the receiver can verify the locator list.
CGAパラメータデータ構造：受信機は、ロケータリストを確認することができますので、ロケータリストが含まれている場合に含まれます。
CGA Signature: Included when some of the locators in the list use CGA (and not HBA) for verification.
CGAの署名：リスト内のロケータのいくつかは検証のためにCGA（やないHBA）を使用する場合に含まれます。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
The Update Request message is used to update either the list of locators, the locator preferences, or both. When the list of locators is updated, the message also contains the option(s) necessary for HBA/CGA to secure this. The basic sanity check that prevents off-path attackers from generating bogus updates is the Context Tag in the message.
更新要求メッセージは、ロケータのリスト、ロケータの好み、あるいはその両方を更新するために使用されます。ロケータのリストが更新されると、メッセージも、これを確保するHBA / CGAのために必要なオプション（複数可）が含まれています。偽の更新を発生させるから、オフパス攻撃を防ぐ基本的な妥当性検査は、メッセージ中のコンテキストタグです。
The Update Request message contains options (the Locator List and the Locator Preferences) that, when included, completely replace the previous locator list and locator preferences, respectively. Thus, there is no mechanism to just send deltas to the locator list.
更新要求メッセージには、含まれている場合、完全にそれぞれ、前のロケータリストとロケータ嗜好を置き換えるオプション（ロケータリストとロケータ設定）が含まれています。このように、単にロケータリストにデルタを送信するためのメカニズムはありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 64 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも1は、ヘッダは16オクテットであるからです。
Type: 64
タイプ：64
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Receiver Context Tag: 47-bit field. The Context Tag that the receiver has allocated for the context.
レシーバコンテキストタグ：47ビットのフィールド。受信機は、コンテキストに割り当てたコンテキストタグ。
Request Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the peer will return in the Update Acknowledgement message.
32ビット符号なし整数：nonceを要求します。ピアが更新肯定応答メッセージで返されイニシエータで撮像された乱数、。
The following options are defined for this message:
次のオプションは、このメッセージのために定義されています。
Locator List: The list of the sender's (new) locators. The locators might be unchanged and only the preferences have changed.
ロケータリスト：送信者（新）ロケータのリスト。ロケータは変わらないとだけ設定が変更されているかもしれません。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
ロケータ設定：ロケータが等しい優先度を持っていないすべてのない時に必要に応じて送信されます。
CGA Parameter Data Structure (PDS): Included when the locator list is included and the PDS was not included in the I2/ I2bis/R2 messages, so the receiver can verify the locator list.
CGAパラメータデータ構造（PDS）：ロケータのリストが含まれており、PDSがI2 / I2bis / R2メッセージに含まれていなかったので、受信機は、ロケータのリストを確認できた場合に含まれます。
CGA Signature: Included when some of the locators in the list use CGA (and not HBA) for verification.
CGAの署名：リスト内のロケータのいくつかは検証のためにCGA（やないHBA）を使用する場合に含まれます。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
This message is sent in response to an Update Request message. It implies that the Update Request has been received and that any new locators in the Update Request can now be used as the source locators of packets. But it does not imply that the (new) locators have been verified to be used as a destination, since the host might defer the verification of a locator until it sees a need to use a locator as the destination.
このメッセージは、更新要求メッセージに応答して送信されます。これは、更新要求を受信したことと更新要求に新たなロケータが今、パケットの送信元ロケータとして使用できることを意味します。しかし、それは宛先としてロケータを使用する必要性を認識するまで、ホストはロケータの検証を延期する可能性があるので、（新しい）ロケータは、デスティネーションとして使用することが確認されたことを意味するものではありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 65 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
HDR拡張レン：NOオプションが存在しないときに、少なくとも1は、ヘッダは16オクテットであるからです。
Type: 65
タイプ：65
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved1：7ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。
Receiver Context Tag: 47-bit field. The Context Tag the receiver has allocated for the context.
レシーバコンテキストタグ：47ビットのフィールド。受信機は、コンテキストに割り当てたコンテキストタグ。
Request Nonce: 32-bit unsigned integer. Copied from the Update Request message.
32ビット符号なし整数：nonceを要求します。更新要求メッセージからコピーされました。
No options are currently defined for this message.
オプションなしは現在、このメッセージに定義されていません。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
将来のプロトコル拡張は、このメッセージの追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。セクション5.15を参照してください。
This message format is defined in [4].
このメッセージ・フォーマットは、[4]で定義されています。
The message is used to ensure that when a peer is sending ULP packets on a context, it always receives some packets in the reverse direction. When the ULP is sending bidirectional traffic, no extra packets need to be inserted. But for a unidirectional ULP traffic pattern, the shim will send back some Keepalive messages when it is receiving ULP packets.
メッセージは、ピアがコンテキストにULPパケットを送信しているとき、それは常に逆方向にいくつかのパケットを受信することを保証するために使用されます。 ULPは、双方向のトラフィックを送信しているときに、余分なパケットを挿入する必要はありません。それはULPパケットを受信しているときには一方向のULPのトラフィックパターンのために、シムは、いくつかのキープアライブメッセージを送り返します。
This message and its semantics are defined in [4].
このメッセージとその意味は、[4]で定義されています。
The goal of this mechanism is to test whether or not locator pairs work in the general case. In particular, this mechanism is to be able to handle the case when one locator pair works from A to B and another locator pair works from B to A, but there is no locator pair that works in both directions. The protocol mechanism is that, as A is sending Probe messages to B, B will observe which locator pairs it has received and report that back in Probe messages it sends to A.
このメカニズムの目標は、ロケータペアは一般的なケースで働くかどうかをテストすることです。具体的には、このメカニズムは、一つの位置決め対は、AからBに動作し、別の位置決め対はAとBから動作しますが、両方向に動作ないロケータペアが存在しない場合を扱うことができることです。プロトコル機構は、AがBにプローブメッセージを送信しているように、Bは、それが受信したロケータペアを観察し、それがAに送信するプローブメッセージでその背中を報告する、ということです
The Error message is generated by a Shim6 receiver upon the reception of a Shim6 message containing critical information that cannot be processed properly.
エラーメッセージが正しく処理できない重要な情報を含むSHIM6メッセージの受信時SHIM6受信機によって生成されます。
In the case that a Shim6 node receives a Shim6 packet that contains information that is critical for the Shim6 protocol and that is not supported by the receiver, it sends an Error Message back to the originator of the Shim6 message. The Error message is unacknowledged.
SHIM6ノードがSHIM6プロトコルにとって重要であり、それが受信機によってサポートされていない情報が含まSHIM6パケットを受信した場合には、バックSHIM6メッセージの発信者にエラーメッセージを送信します。エラーメッセージは未確認です。
In addition, Shim6 Error messages defined in this section can be used to identify problems with Shim6 implementations. In order to do so, a range of Error Code types is reserved for that purpose. In particular, implementations may generate Shim6 Error messages with Code types in that range, instead of silently discarding Shim6 packets during the debugging process.
加えて、このセクションで定義されたSHIM6エラーメッセージがSHIM6実装の問題を特定するために使用することができます。そうするためには、エラーコードの種類の範囲は、その目的のために予約されています。具体的には、実装は静かにデバッギングプロセス中SHIM6パケットを廃棄するのではなく、その範囲内のコードタイプとSHIM6エラーメッセージを生成してもよいです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 68 | Error Code |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Packet in error +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Next Header: NO_NXT_HDR (59).
次のヘッダ：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets. Depends on the specific Error Data.
HDR拡張レン：少なくとも1、ヘッダは16オクテットであるからです。特定のエラーデータに依存します。
Type: 68
タイプ：68
Error Code: 7-bit field describing the error that generated the Error message. See Error Code list below.
エラーコード：エラーメッセージを生成したエラーを説明する7ビットのフィールド。以下のエラーコード一覧を参照してください。
Pointer: 16-bit field. Identifies the octet offset within the invoking packet where the error was detected.
ポインタ：16ビットのフィールド。エラーが検出された起動パケット内のオクテットオフセットを識別します。
Packet in error: As much of invoking packet as possible without the Error message packet exceeding the minimum IPv6 MTU.
エラーでパケット：最小のIPv6 MTUを超えるエラーメッセージパケットなしで可能な限りパケットを呼び出すようにはるか。
The following Error Codes are defined:
以下のエラーコードが定義されています。
+---------+---------------------------------------------------------+
| Code | Description |
| Value | |
+---------+---------------------------------------------------------+
| 0 | Unknown Shim6 message type |
| 1 | Critical option not recognized |
| 2 | Locator verification method failed (Pointer to the |
| | inconsistent verification method octet) |
| 3 | Locator List Generation number out of sync. |
| 4 | Error in the number of locators in a Locator Preference |
| | option |
| 120-127 | Reserved for debugging purposes |
+---------+---------------------------------------------------------+
Table 2
表2
The format of the options is a snapshot of the current HIP option format [20]. However, there is no intention to track any changes to the HIP option format, nor is there an intent to use the same name space for the option type values. But using the same format will hopefully make it easier to import HIP capabilities into Shim6 as extensions to Shim6, should this turn out to be useful.
オプションのフォーマットは、現在のHIPオプション形式[20]のスナップショットです。しかし、HIPオプション形式への変更を追跡する意図はない、またオプション型の値に同じ名前空間を使用する意図があります。これが有用であることが判明しなければならないが、同じフォーマットを使用すると、うまくいけば、それが簡単にSHIM6の拡張機能としてSHIM6にHIP機能をインポートするようになります。
All of the TLV parameters have a length (including Type and Length fields) that is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. If padding is added, the Length field MUST NOT include the padding. Any added padding bytes MUST be zeroed by the sender, and their values SHOULD NOT be checked by the receiver.
TLVパラメータの全ては、8バイトの倍数である（タイプと長さフィールドを含む）の長さを有します。必要なときに全長が8バイトの倍数になるように、パディングは、パラメータの末尾に追加する必要があります。このルールは、データの適切なアライメントを保証します。パディングが追加されている場合は、Lengthフィールドは、パディングを含んではいけません。任意の追加パディングバイトは、送信者によってゼロにしなければならない、とそれらの値は、受信機によって確認されるべきではありません。
Consequently, the Length field indicates the length of the Contents field (in bytes). The total length of the TLV parameter (including Type, Length, Contents, and Padding) is related to the Length field according to the following formula:
結果として、長さフィールドは、（バイト）内容フィールドの長さを示します。 （タイプ、長さ、内容、およびパディングを含む）TLVパラメータの全長は、以下の式に従ってLengthフィールドに関連しています。
Total Length = 11 + Length - (Length + 3) mod 8;
全長= 11 +長さ - （長さ+ 3）MOD 8。
The total length of the option is the smallest multiple of 8 bytes that allows for the 4 bytes of the Option header and option, itself. The amount of padding required can be calculated as follows:
オプションの全長はオプションヘッダとオプションの4バイト、それ自体を可能にする8バイトの最小倍数です。次のように必要なパディングの量を計算することができます。
padding = 7 - ((Length + 3) mod 8)
パディング= 7 - （（長さ+ 3）MOD 8）
And:
そして：
Total Length = 4 + Length + padding
全長= 4 +長さ+パディング
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 |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Contents ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Type: 15-bit identifier of the type of option. The options defined in this document are below.
タイプ：オプションの種類の15ビットの識別子。この文書で定義されたオプションは以下の通りです。
C: Critical. One, if this parameter is critical and MUST be recognized by the recipient; zero otherwise. An implementation might view the C-bit as part of the Type field by multiplying the type values in this specification by two.
C：クリティカル。一つは、このパラメータは重要であり、受信者によって認識されなければならない場合。そうでない場合はゼロ。実装は、二つによって本明細書にタイプ値を乗算することによりTypeフィールドの一部としてのCビットを表示するかもしれません。
Length: Length of the Contents, in bytes.
長さ：バイト単位のコンテンツの長さ。
Contents: Parameter-specific, defined by Type.
内容量：パラメータ固有の、タイプによって定義されます。
Padding: Padding, 0-7 bytes, added if needed.
パディング：必要に応じてパディング、0-7バイトが、追加しました。
+------+------------------------------+
| Type | Option Name |
+------+------------------------------+
| 1 | Responder Validator |
| 2 | Locator List |
| 3 | Locator Preferences |
| 4 | CGA Parameter Data Structure |
| 5 | CGA Signature |
| 6 | ULID Pair |
| 7 | Forked Instance Identifier |
| 10 | Keepalive Timeout Option |
+------+------------------------------+
Table 3
表3
Future protocol extensions might define additional options for the Shim6 messages. The C-bit in the option format defines how such a new option will be handled by an implementation.
将来のプロトコル拡張はSHIM6メッセージ用の追加オプションを定義できます。オプションフォーマットのCビットは、新しいオプションを実装することによって処理される方法を定義します。
If a host receives an option that it does not understand (an option that was defined in some future extension to this protocol) or that is not listed as a valid option for the different message types above, then the Critical bit in the option determines the outcome.
ホストは、それが、またはそれは、上記の異なるメッセージタイプのための有効なオプションとして表示されていない（このプロトコルの将来の拡張で定義されたオプション）を理解していないオプションを受信した場合、その後、オプションでクリティカルビットが決定します結果。
o If C=0, then the option is silently ignored, and the rest of the message is processed.
O C = 0の場合、オプションは黙って無視され、メッセージの残りの部分が処理されます。
o If C=1, then the host SHOULD send back a Shim6 Error message with Error Code=1, with the Pointer field referencing the first octet in the Option Type field. When C=1, the rest of the message MUST NOT be processed.
O、C = 1の場合、ホストはオプションタイプフィールドの最初のオクテットを参照するポインタフィールドと、エラーコード= 1でSHIM6エラーメッセージを返すべきです。 C = 1、メッセージの残りの部分が処理されてはならないとき。
The responder can choose exactly what input is used to compute the validator and what one-way function (such as MD5 or SHA1) it uses, as long as the responder can check that the validator it receives back in the I2 or I2bis message is indeed one that:
レスポンダは、レスポンダはバリそれがI2に戻って受け取るか、またはI2bisメッセージが実際にあることを確認することができますよう、それは限り、使用した入力がバリデータを計算するために使用し、どのような一方向関数（MD5などまたはSHA1）され、正確なものを選択することができます1その：
1) computed,
1）計算され、
2) computed for the particular context, and
2）特定のコンテキストの計算、及び
3) isn't a replayed I2/I2bis message.
3）再生I2 / I2bisメッセージではありません。
Some suggestions on how to generate the validators are captured in Sections 7.10.1 and 7.17.1.
バリデータを生成する方法についていくつかの提案は、セクション7.10.1と7.17.1に取り込まれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Validator ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Validator: Variable length content whose interpretation is local to the responder.
検証：その解釈レスポンダーに対してローカルである可変長内容。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
パディング：必要に応じてパディング、0-7バイトが、追加しました。セクション5.15を参照してください。
The Locator List option is used to carry all the locators of the sender. Note that the order of the locators is important, since the Locator Preferences option refers to the locators by using the index in the list.
ロケータリストオプションは、送信者のすべてのロケータを運ぶために使用されます。ロケータ環境設定オプションは、リスト内のインデックスを使用してロケータを参照するため、ロケータの順序は、重要であることに注意してください。
Note that we carry all the locators in this option even though some of them can be created automatically from the CGA Parameter Data Structure.
それらのいくつかはCGAパラメータデータ構造から自動的に作成することができるにもかかわらず、私たちは、このオプションでは、すべてのロケータを運ぶことに注意してください。
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 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Locators | N Octets of Verification Method |
+-+-+-+-+-+-+-+-+ |
~ ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Locators 1 through N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Locator List Generation: 32-bit unsigned integer. Indicates a generation number that is increased by one for each new locator list. This is used to ensure that the index in the Locator Preferences refers to the right version of the locator list.
ロケータリスト生成：32ビット符号なし整数。それぞれの新しいロケータのリストについては、1つずつ増加された世代番号を示します。これは、ロケータの環境でインデックスがロケータリストの正しいバージョンを指していることを確実にするために使用されます。
Num Locators: 8-bit unsigned integer. The number of locators that are included in the option. We call this number "N" below.
民ロケータ：8ビットの符号なし整数。オプションに含まれているロケータの数。私たちは、以下の「N」は、この番号に電話します。
Verification Method: N octets. The ith octet specifies the verification method for the ith locator.
検証方法：Nオクテット。 i番目のオクテットは、i番目のロケータの検証方法を指定します。
Padding: Padding, 0-7 bytes, added if needed so that the Locators start on a multiple-of-8-octet boundary. Note that for this option, there is never a need to pad at the end since the Locators are a multiple-of-8- octets in length. This internal padding is included in the Length field.
パディング：ロケータは、複数の-8オクテット境界で開始するように、必要に応じてパディング、0-7バイトが、追加しました。ロケータの長さが複数の-8-オクテットであるため、このオプションのために、最後のパッドに必要が決してないことに注意してください。この内部パディングはLengthフィールドに含まれています。
Locators: N 128-bit locators.
ロケータ：N 128ビットのロケータ。
The defined verification methods are:
定義された検証方法は以下のとおりです。
+---------+----------------------------------+
| Value | Method |
+---------+----------------------------------+
| 0 | Reserved |
| 1 | HBA |
| 2 | CGA |
| 3-200 | Allocated using Standards action |
| 201-254 | Experimental use |
| 255 | Reserved |
+---------+----------------------------------+
Table 4
表4
The Locator Preferences option can have some flags to indicate whether or not a locator is known to work. In addition, the sender can include a notion of preferences. It might make sense to define "preferences" as a combination of priority and weight, the same way that DNS SRV records have such information. The priority would provide a way to rank the locators, and, within a given priority, the weight would provide a way to do some load sharing. See [5] for how SRV defines the interaction of priority and weight.
ロケータ環境設定オプションは、ロケータが動作することが知られているかどうかを示すために、いくつかのフラグを持つことができます。また、送信者は好みの概念を含めることができます。これは、優先度と重みの組み合わせとしてDNS SRVレコードは、そのような情報を持っているのと同じように、「環境設定」を定義しても意味があります。優先順位は、ロケータをランク付けする方法を提供するだろう、と、優先以内、重量はいくつかの負荷分散を行うための方法を提供します。 SRVは、優先度と重みとの相互作用を定義する方法については、[5]を参照。
The minimum notion of preferences we need is to be able to indicate that a locator is "dead". We can handle this using a single octet flag for each locator.
我々が必要好みの最小概念はロケータは「デッド」であることを示すことができるようにすることです。私たちは、各ロケータの単一オクテットフラグを使用してこれを扱うことができます。
We can extend that by carrying a larger "element" for each locator. This document presently also defines 2-octet and 3-octet elements, and we can add more information by having even larger elements if need be.
私たちは、各ロケータの大きな「要素」を実施することによってこれを拡張することができます。このドキュメントでは、現在も2オクテットと3オクテットの要素を定義し、必要であれば、私たちはさらに大きな要素を有することにより、より多くの情報を追加することができます。
The locators are not included in the preference list. Instead, the first element refers to the locator that was in the first element in the Locator List option. The generation number carried in this option and the Locator List option is used to verify that they refer to the same version of the locator list.
ロケータは、優先リストに含まれていません。代わりに、最初の要素は、ロケータリスト・オプションの最初の要素にあったロケータを指します。このオプションとロケータリスト]オプションで運ば世代番号は、それらがロケータリストの同じバージョンを参照することを確認するために使用されます。
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 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Len | Element[1] | Element[2] | Element[3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Case of Element Len = 1 is depicted.
エレメントレン= 1の場合が示されています。
Fields:
フィールド：
Locator List Generation: 32-bit unsigned integer. Indicates a generation number for the locator list to which the elements should apply.
ロケータリスト生成：32ビット符号なし整数。要素が適用先となるロケータリストの生成数を示します。
Element Len: 8-bit unsigned integer. The length in octets of each element. This specification defines the cases when the length is 1, 2, or 3.
要素レン：8ビットの符号なし整数。各要素のオクテットの長さ。長さは1、2、または3である場合、この仕様では、ケースを定義します。
Element[i]: A field with a number of octets defined by the Element Len field. Provides preferences for the ith locator in the Locator List option that is in use.
要素[I]：要素LENフィールドによって定義されたオクテットの数のフィールド。使用されているロケータリスト]オプションのi番目のロケータの環境を提供します。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
パディング：必要に応じてパディング、0-7バイトが、追加しました。セクション5.15を参照してください。
When the Element length equals one, then the element consists of only a one-octet Flags field. The currently defined set of flags are:
素子長が1に等しい場合、その要素は、1オクテットのフラグフィールドから成ります。フラグの現在定義されているセットは以下のとおりです。
BROKEN: 0x01
BROKEN：0x01の
TRANSIENT: 0x02
TRANSIENT：0×02
The intent of the BROKEN flag is to inform the peer that a given locator is known to be not working. The intent of TRANSIENT is to allow the distinction between more stable addresses and less stable addresses when Shim6 is combined with IP mobility, and when we might have more stable home locators and less stable care-of-locators.
BROKENフラグの目的は、与えられたロケータが動作していないことが知られているピアに通知することです。 TRANSIENTの意図はSHIM6がIPモビリティと組み合わせた場合、より安定したアドレスと少ない安定したアドレス間の区別を可能にするためであり、我々は、より安定した家庭ロケータの少ない安定したケア・オブ・ロケータを持っている可能性がある場合。
When the Element length equals two, then the element consists of a one-octet Flags field followed by a one-octet Priority field. This Priority field has the same semantics as the Priority field in DNS SRV records.
素子長が2に等しい場合、その要素は、1オクテットの優先度フィールドに続く1オクテットのフラグフィールドから成ります。この優先度フィールドには、DNS SRVレコードでPriorityフィールドと同じ意味を持っています。
When the Element length equals three, then the element consists of a one-octet Flags field followed by a one-octet Priority field and a one-octet Weight field. This Weight field has the same semantics as the Weight field in DNS SRV records.
エレメントの長さが3と等しい場合、その要素は、1オクテットの優先フィールドと1オクテットのWeightフィールドに続く1オクテットのFlagsフィールドで構成されています。このWeightフィールドには、DNS SRVレコードで重フィールドと同じ意味を持っています。
This document doesn't specify the format when the Element length is more than three, except that any such formats MUST be defined so that the first three octets are the same as in the above case, that is, a one-octet Flags field followed by a one-octet Priority field, and a one-octet Weight field.
このような形式は、最初の3つのオクテットは、上記の場合と同様であるように、即ち、1オクテットのフラグフィールドが続く定義しなければならないことを除き、要素の長さは、つ以上ある場合は、この文書のフォーマットを指定していません1オクテットの優先フィールド、および1オクテットのWeightフィールドによって。
This option contains the CGA Parameter Data Structure (PDS). When HBA is used to verify the locators, the PDS contains the HBA multiprefix extension in addition to the PDS mandatory fields and other extensions unrelated to Shim6 that the PDS might have. When CGA is used to verify the locators, in addition to the PDS option, the host also needs to include the signature in the form of a CGA Signature option.
このオプションは、CGAパラメータデータ構造（PDS）が含まれています。 HBAは、ロケータを検証するために使用される場合、PDSは、PDS PDSを持っている可能性があることを必須フィールドとSHIM6とは関係のない他の拡張機能に加えて、HBA multiprefix拡張が含まれています。 CGAは、ロケータを検証するために使用される場合、PDSのオプションに加えて、ホストは、CGA署名オプションの形式で署名を含める必要があります。
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 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Parameter Data Structure ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
CGA Parameter Data Structure: Variable length content. Content defined in [2] and [3].
CGAパラメータデータ構造：可変長内容。 [2]及び[3]で定義されたコンテンツ。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
パディング：必要に応じてパディング、0-7バイトが、追加しました。セクション5.15を参照してください。
When CGA is used for verification of one or more of the locators in the Locator List option, then the message in question will need to contain this option.
CGAは、ロケータリストオプションでロケータのうちの1つまたは複数の検証に使用されている場合は、問題のメッセージは、このオプションを含める必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Signature ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
CGA Signature: A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets:
CGAの署名：PKCS＃1 v1.5のシグネチャを含む可変長フィールドは、オクテット以下の一連のオーバー送信者の秘密鍵を用いて構成します：
1. The 128-bit CGA Message Type tag [CGA] value for
Shim6: 0x4A 30 5662 4858 574B 3655 416F 506A 6D48.
(The tag value has been generated randomly by the
editor of this specification.).
2. The Locator List Generation number of the correspondent Locator List option.
2.特派ロケータリストオプションのロケータ一覧世代番号に。
3. The subset of locators included in the correspondent Locator List option whose verification method is set to CGA. The locators MUST be included in the order in which they are listed in the Locator List Option.
3.ロケータのサブセットは、その検証方法CGAに設定されている対応ロケータリストオプションに含まれています。ロケータは、それらがロケータリスト・オプションにリストされている順序に含めなければなりません。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
パディング：必要に応じてパディング、0-7バイトが、追加しました。セクション5.15を参照してください。
I1, I2, and I2bis messages MUST contain the ULID pair; normally, this is in the IPv6 Source and Destination fields. In case the ULID for the context differs from the address pair included in the Source and Destination Address fields of the IPv6 packet used to carry the I1/ I2/I2bis message, the ULID Pair option MUST be included in the I1/I2/ I2bis message.
I1、I2、およびI2bisメッセージがULIDペアを含まなければなりません。通常、これは、IPv6送信元と送信先のフィールドです。場合は、コンテキストのためのULIDは、I1 / I2 / I2bisメッセージを運ぶために使用されたIPv6パケットの送信元アドレスと宛先アドレスフィールドに含まれるアドレスのペアとは異なり、ULIDペアオプションは、I1 / I2 / I2bisメッセージに含まれなければなりません。
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 = 6 |0| Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Sender ULID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receiver ULID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Reserved2: 32-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Needed to make the ULIDs start on a multiple-of-8-octet boundary.)
Reserved2：32ビットのフィールド。将来の使用のために予約されています。送信上のゼロ。領収書で無視しなければなりません。 （ULIDsは、複数の-8オクテット境界上で起動させる必要がありました。）
Sender ULID: A 128-bit IPv6 address.
送信者ULID：128ビットのIPv6アドレス。
Receiver ULID: A 128-bit IPv6 address.
レシーバーULID：128ビットのIPv6アドレス。
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 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forked Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
フィールド：
Forked Instance Identifier: 32-bit field containing the identifier of the particular forked instance.
フォークインスタンス識別子：特定のフォークのインスタンスの識別子を含む32ビットのフィールド。
This option is defined in [4].
このオプションは、[4]で定義されています。
This section describes a conceptual model of one possible data structure organization that hosts will maintain for the purposes of Shim6. The described organization is provided to facilitate the explanation of how the Shim6 protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
このセクションでは、ホストはSHIM6の目的のために維持する一つの可能なデータ構造組織の概念モデルを記載しています。説明組織はSHIM6プロトコルがどのように振る舞うべきかの説明を容易にするために提供されます。この文書では、実装がいる限り彼らの外部の振舞いが本書に記載されたものと一致しているとして、このモデルに準拠することを強制しません。
The key conceptual data structure for the Shim6 protocol is the ULID-pair context. This is a data structure that contains the following information:
SHIM6プロトコルの鍵概念的なデータ構造は、ULID対コンテキストです。これは、以下の情報を含むデータ構造であります：
o The state of the context. See Section 6.2.
コンテキストの状態O。 6.2節を参照してください。
o The peer ULID: ULID(peer).
ピアULID O：ULID（ピア）。
o The local ULID: ULID(local).
ULID（ローカル）：ローカルULID O。
o The Forked Instance Identifier: FII. This is zero for the default context, i.e., when there is no forking.
フォークトインスタンス識別子O：FII。何のフォークがないとき、これは、つまり、デフォルトのコンテキストはゼロです。
o The list of peer locators with their preferences: Ls(peer).
Lsは（ピア）：自分の好みとのピアロケータのリストO。
o The generation number for the most recently received, verified peer locator list.
最も最近受信し、検証済みのピアロケータリストの世代番号O。
o For each peer locator, the verification method to use (from the Locator List option).
O各ピアロケータについて、検証方法は、（ロケータリストオプションから）を使用します。
o For each peer locator, a flag specifying whether it has been verified using HBA or CGA, and a bit specifying whether the locator has been probed to verify that the ULID is present at that location.
各ピアロケータ、それがHBAまたはCGAを使用して検証されたかどうかを指定するフラグ、及びロケータはULIDがその場所に存在することを確認するためにプローブされているかどうかを指定するビットについてはO。
o The current peer locator is the locator used as the destination address when sending packets: Lp(peer).
Lpの（ピア）：O現在のピア・ロケータは、パケットを送信するときに宛先アドレスとして使用されるロケータです。
o The set of local locators and the preferences: Ls(local).
Lsの（ローカル）：ローカルロケータと好みのセットO。
o The generation number for the most recently sent Locator List option.
最近送られたロケータリストオプションの世代番号O。
o The current local locator is the locator used as the source address when sending packets: Lp(local).
O現在のローカルロケータは、パケットを送信するときに送信元アドレスとして使用ロケータである：（ローカル）のLp。
o The Context Tag used to transmit control messages and Shim6 Payload Extension headers; this is allocated by the peer: CT(peer).
制御メッセージとSHIM6ペイロード拡張ヘッダを送信するために使用されるコンテキストタグO。 CT（ピア）：これは、ピアによって割り当てられます。
o The context to expect in received control messages and Shim6 Payload Extension headers; this is allocated by the local host: CT(local).
Oコンテキストは、受信した制御メッセージとSHIM6ペイロード拡張ヘッダに期待します。 CT（ローカル）：これは、ローカルホストによって割り当てられます。
o Timers for retransmission of the messages during context-establishment and update messages.
Oコンテキスト確立及び更新メッセージ中のメッセージの再送信のためのタイマー。
o Depending how an implementation determines whether a context is still in use, there might be a need to track the last time a packet was sent/received using the context.
O実装は、コンテキストがまだ使用中であるかどうかを判定する方法によっては、パケットが送信された最後の時間を追跡する必要があるかもしれません/コンテキストを使用して受信。
o Reachability state for the locator pairs as specified in [4].
[4]で指定されるように、ロケータペアのO到達可能性状態。
o During pair exploration, information about the Probe messages that have been sent and received as specified in [4].
Oペア探査、[4]で指定されるように送信され、受信されたプローブ・メッセージに関する情報中。
o During context-establishment phase, the Initiator Nonce, Responder Nonce, Responder Validator, and timers related to the different packets sent (I1,I2, R2), as described in Section 7.
Oコンテキスト確立フェーズの間、イニシエータノンス、レスポンダノンス、レスポンダバリデータ、および第7章に記載されているように、異なる送信されたパケット（I1、I2、R2）をに関連するタイマー。
The STATES that are used to describe the Shim6 protocol are as follows:
次のようにSHIM6プロトコルを記述するために使用される状態は次のとおりです。
+---------------------+---------------------------------------------+
| STATE | Explanation |
+---------------------+---------------------------------------------+
| IDLE | State machine start |
| | |
| I1-SENT | Initiating context-establishment exchange |
| | |
| I2-SENT | Waiting to complete context-establishment |
| | exchange |
| | |
| I2BIS-SENT | Potential context loss detected |
| | |
| ESTABLISHED | SHIM context established |
| | |
| E-FAILED | Context-establishment exchange failed |
| | |
| NO-SUPPORT | ICMP Unrecognized Next Header type |
| | (type 4, code 1) received, indicating |
| | that Shim6 is not supported |
+---------------------+---------------------------------------------+
In addition, in each of the aforementioned STATES, the following state information is stored:
加えて、前述の状態のそれぞれにおいて、次の状態情報が格納されています。
+---------------------+---------------------------------------------+
| STATE | Information |
+---------------------+---------------------------------------------+
| IDLE | None |
| | |
| I1-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | INIT Nonce, Lp(local), Lp(peer), Ls(local) |
| | |
| I2-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | INIT Nonce, RESP Nonce, Lp(local), Lp(peer),|
| | Ls(local), Responder Validator |
| | |
| ESTABLISHED | ULID(peer), ULID(local), [FII], CT(local), |
| | CT(peer), Lp(local), Lp(peer), Ls(local), |
| | Ls(peer), INIT Nonce?(to receive late R2) |
| | |
| I2BIS-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | CT(peer), Lp(local), Lp(peer), Ls(local), |
| | Ls(peer), CT(R1bis), RESP Nonce, |
| | INIT Nonce, Responder Validator |
| | |
| E-FAILED | ULID(peer), ULID(local) |
| | |
| NO-SUPPORT | ULID(peer), ULID(local) |
+---------------------+---------------------------------------------+
ULID-pair contexts are established using a 4-way exchange, which allows the responder to avoid creating state on the first packet. As part of this exchange, each end allocates a Context Tag and shares this Context Tag and its set of locators with the peer.
ULID対コンテキストは応答者が最初のパケットで状態を作成しないことを可能にする4ウェイ交換を使用して確立されています。この交換の一環として、各端部は、コンテキストタグと共有このContextタグとピアとのロケータのセットを割り当てます。
In some cases, the 4-way exchange is not necessary -- for instance, when both ends try to set up the context at the same time, or when recovering from a context that has been garbage collected or lost at one of the hosts.
いくつかのケースでは、4ウェイの交換が不要である - 両端が同時にコンテキストを設定しようとすると、例えば、またはガベージコレクションまたはホストのいずれかで失われている文脈から回復します。
As part of establishing a new context, each host has to assign a unique Context Tag. Since the Shim6 Payload Extension headers are demultiplexed based solely on the Context Tag value (without using the locators), the Context Tag MUST be unique for each context.
新しいコンテキストの確立の一環として、各ホストは固有のコンテキストタグを割り当てることがあります。 SHIM6ペイロード拡張ヘッダを（ロケータを使用せずに）単独コンテキストタグ値に基づいて逆多重化されているので、コンテキストタグは、各コンテキストのために一意でなければなりません。
It is important that Context Tags are hard to guess for off-path attackers. Therefore, if an implementation uses structure in the Context Tag to facilitate efficient lookups, at least 30 bits of the Context Tag MUST be unstructured and populated by random or pseudo-random bits.
コンテキストタグは、オフパス攻撃者のために推測しにくいことが重要です。実装は、効率的な検索を容易にするために、コンテキストタグ構造を使用する場合したがって、コンテキストタグの少なくとも30ビットは、非構造化およびランダムまたは疑似ランダムビットによって取り込まなければなりません。
In addition, in order to minimize the reuse of Context Tags, the host SHOULD randomly cycle through the unstructured tag name space that is reserved for randomly assigned Context Tag values (e.g., following the guidelines described in [13]).
また、コンテキストタグの再使用を最小限にするために、ホストがランダムサイクルランダムに割り当てられたコンテキストタグ値のために予約されている構造化されていないタグの名前空間を介して（例えば、[13]に記載のガイドラインに従って）べきです。
The peer's locators might need to be verified during context establishment as well as when handling locator updates in Section 10.
ピアのロケータは、セクション10にロケータの更新を処理するときだけでなく、コンテキストが確立しているときに検証する必要があるかもしれません。
There are two separate aspects of locator verification. One is to verify that the locator is tied to the ULID, i.e., that the host that "owns" the ULID is also the one that is claiming the locator "ownership". The Shim6 protocol uses the HBA or CGA techniques for doing this verification. The other aspect is to verify that the host is indeed reachable at the claimed locator. Such verification is needed not only to make sure communication can proceed but also to prevent 3rd party flooding attacks [15]. These different aspects of locator verification happen at different times since the first might need to be performed before packets can be received by the peer with the source locator in question, but the latter verification is only needed before packets are sent to the locator.
ロケータ検証2つの別々の側面があります。一つは、ホストがULIDもロケータ「所有権」を主張するものである「所有する」ということを、すなわち、ロケータがULIDに結びついていることを確認することです。 SHIM6プロトコルは、この検証を行うためのHBAまたはCGA技術を使用しています。他の態様は、ホストが実際に主張ロケータで到達可能であることを確認することです。このような検証を進めることができることを確認して通信をしないようにだけ必要とされているだけでなく、サードパーティ製のフラッディング攻撃[15]を防ぐために。最初は、パケットが問題のソースロケータとのピアによって受信することができる前に実行する必要がある場合がありますので、ロケータ検証のこれらの異なる側面は、異なる時間に起こるが、パケットがロケータに送信される前に、後者の検証にのみ必要とされています。
Before a host can use a locator (different than the ULID) as the source locator, it must know that the peer will accept packets with that source locator as part of this context. Thus, the HBA/CGA verification SHOULD be performed by the host before the host acknowledges the new locator by sending either an Update Acknowledgement message or an R2 message.
ホストはソースロケータとして（ULIDとは異なる）のロケータを使用する前に、それはピアが、このコンテキストの一部として、そのソースロケータを持つパケットを受け入れることを知っている必要があります。ホストが更新肯定応答メッセージまたはR2のメッセージのいずれかを送信することによって、新たなロケータを認識する前にこのように、HBA / CGA検証は、ホストによって実行されるべきです。
Before a host can use a locator (different than the ULID) as the destination locator, it MUST perform the HBA/CGA verification if this was not performed upon reception of the locator set. In addition, it MUST verify that the ULID is indeed present at that locator. This verification is performed by doing a return-routability test as part of the Probe sub-protocol [4].
ホストが宛先ロケータとして（ULIDとは異なる）のロケータを使用する前に、このロケータセットの受信時に行われなかった場合には、HBA / CGA検証を実行しなければなりません。また、ULIDが実際にそのロケータに存在していることを確かめなければなりません。この検証は、[4]プローブサブプロトコルの一部としてリターン・ルータビリティ・テストを実行することによって行われます。
If the verification method in the Locator List option is not supported by the host, or if the verification method is not consistent with the CGA Parameter Data Structure (e.g., the Parameter Data Structure doesn't contain the multiprefix extension and the verification method says to use HBA), then the host MUST ignore the
ロケータリスト]オプションでの検証方法は、ホストによってサポートされていないか、確認方法は、CGAパラメータデータ構造と一致しない場合（例えば、パラメータデータ構造はmultiprefix拡張が含まれていないと検証方法がに言うならば、その後、ホストは無視しなければならない）HBAを使用します
Locator List and the message in which it is contained. The host SHOULD generate a Shim6 Error message with Error Code=2 and with the Pointer referencing the octet in the verification method that was found inconsistent.
ロケータリストとそれが含まれるメッセージ。ホストは、エラーコード= 2と矛盾が見出された検証方法においてオクテットを参照するポインタでSHIM6エラーメッセージを生成する必要があります。
The normal context establishment consists of a 4-message exchange in the order of I1, R1, I2, R2, as can be seen in Figure 3.
図3に見られるように、通常のコンテキストの確立は、I1、R1、I2、R2の順に4メッセージ交換から成ります。
Initiator Responder
イニシエータレスポンダ
IDLE IDLE
------------- I1 -------------->
I1-SENT
<------------ R1 ---------------
IDLE
------------- I2 -------------->
I2-SENT
<------------ R2 ---------------
ESTABLISHED ESTABLISHED
Figure 3: Normal Context Establishment
図3：通常のコンテキストの確立
When both ends try to initiate a context for the same ULID pair, then we might end up with crossing I1 messages. Alternatively, since no state is created when receiving the I1, a host might send an I1 after having sent an R1 message.
両端が同じULIDペアのためのコンテキストを起動しようとすると、我々は交差I1メッセージで終わるかもしれません。 I1を受信したときに何も状態が作成されないので、あるいは、ホストは、R1メッセージを送信した後、I1を送信するかもしれません。
Since a host remembers that it has sent an I1, it can respond to an I1 from the peer (for the same ULID pair) with an R2, resulting in the message exchange shown in Figure 4. Such behavior is needed for reasons such as correctly responding to retransmitted I1 messages, which occur when the R2 message has been lost.
ホストは、それがI1を送信したことを覚えているので、このような挙動は、そのような正確などの理由のために必要とされる図4に示すメッセージ交換が生じる、R2と（同じULIDペアの）ピアからI1に応答することができますR2メッセージが失われたときに発生する再送I1メッセージに応答します。
Host A Host B
ホストBホスト
IDLE IDLE
-\
I1-SENT---\
---\ /---
--- I1 ---\ /--- I1-SENT
---\
/--- I1 ---/ ---\
/--- -->
<---
-\
I1-SENT---\
---\ /---
--- R2 ---\ /--- I1-SENT
---\
/--- R2 ---/ ---\
/--- -->
<--- ESTABLISHED
ESTABLISHED
Figure 4: Crossing I1 Messages
図4：交差I1メッセージ
If a host has received an I1 and sent an R1, it has no state to remember this. Thus, if the ULP on the host sends down packets, this might trigger the host to send an I1 message itself. Thus, while one end is sending an I1, the other is sending an I2, as can be seen in Figure 5.
ホストがI1を受け、R1を送信した場合、それはこのことを覚えて何の状態を持っていません。ホスト上のULPがパケットを送信する場合ダウンしたがって、これは、I1メッセージ自体を送信するホストをトリガすることがあります。一端がI1を送信している間に、図5に見られるようにこのように、もう一方は、I2を送信しています。
Host A Host B
ホストBホスト
IDLE IDLE
-\
---\
I1-SENT ---\
--- I1 ---\
---\
---\
-->
/---
/--- IDLE
---
/--- R1--/
/---
<---
-\
I2-SENT---\
---\ /---
--- I2---\ /--- I1-SENT
---\
/--- I1 ---/ ---\
/--- -->
<--- ESTABLISHED
-\
I2-SENT---\
---\ /---
--- R2 ---\ /---
---\
/--- R2 ---/ ---\
/--- -->
<--- ESTABLISHED
ESTABLISHED
Figure 5: Crossing I2 and I1
図5：クロッシングI2とI1
Due to garbage collection, we can end up with one end having and using the context state, and the other end not having any state. We need to be able to recover this state at the end that has lost it before we can use it.
ガベージコレクションのために、我々は、一端があるとコンテキスト状態を使用して、他端がどのような状態を持っていないで終わることができます。我々はそれを使用することができます前に、それを失ってしまった最後に、この状態を回復できるようにする必要があります。
This need can arise in the following cases:
この必要性は、以下の場合に発生する可能性があります。
o The communication is working using the ULID pair as the locator pair but a problem arises, and the end that has retained the context state decides to probe alternate locator pairs.
O通信は、ロケータペアとしてULID対を用いて動作しているが、問題が発生し、コンテキスト状態を保持している端部は、代替ロケータペアを探索することを決定します。
o The communication is working using a locator pair that is not the ULID pair; hence, the ULP packets sent from a peer that has retained the context state use the Shim6 Payload Extension header.
O通信ULID対ないロケータペアを使用して動作しています。したがって、コンテキスト状態を保持しているピアから送信されたULPパケットはSHIM6ペイロード拡張ヘッダを使用します。
o The host that retained the state sends a control message (e.g., an Update Request message).
O状態を保持し、ホストは制御メッセージ（例えば、更新要求メッセージ）を送信します。
In all cases, the result is that the peer without state receives a shim message for which it has no context for the Context Tag.
全ての場合において、結果は、状態なしで、ピアは、それがコンテキストタグのためのコンテキストを持たないためシムメッセージを受信することです。
We can recover the context by having the node that doesn't have a context state send back an R1bis message, and then complete the recovery with an I2bis and R2 message, as can be seen in Figure 6.
我々はR1bisメッセージを返送コンテキスト状態を持たないノードを有することによって、コンテキストを回復し、図6に見られるように、次いで、I2bis及びR2メッセージをリカバリを完了することができます。
Host A Host B
ホストBホスト
Context for CT(peer)=X Discards context for CT(local)=X
CT CTのための（ピア）= X廃棄コンテキスト（ローカル）= Xのコンテキスト
ESTABLISHED IDLE
ESTABLISHED IDLE
---- payload, probe, etc. -----> No context state
for CT(local)=X
<------------ R1bis ------------
IDLE
------------- I2bis ----------->
I2BIS_SENT
<------------ R2 ---------------
ESTABLISHED ESTABLISHED
Figure 6: Context Loss at Receiver
図6：受信機でのコンテキストの損失
If one end has garbage collected or lost the context state, it might try to create a new context state (for the same ULID pair), by sending an I1 message. In this case, the peer (that still has the context state) will reply with an R1 message, and the full 4-way exchange will be performed again, as can be seen in Figure 7.
一端がガベージコレクトまたはコンテキスト状態を失った場合、それはI1メッセージを送信することにより、（同じULIDペアの）新しいコンテキストの状態を作成しようとします。この場合、（まだコンテキスト状態を有している）ピアはR1メッセージで応答する、図7に見られるように、完全な4ウェイ交換は、再度実行されます。
Host A Host B
ホストBホスト
Context for CT(peer)=X Discards context for ULIDs A1, B1 CT(local)=X
CT ULIDs A1、B1 CT（ローカル）のための（ピア）= X廃棄コンテキスト= Xのコンテキスト
ESTABLISHED IDLE
ESTABLISHED IDLE
Finds <------------ I1 --------------- Tries to set up
existing for ULIDs A1, B1
context,
but CT(peer) I1-SENT
doesn't match
------------- R1 --------------->
Left old context
in ESTABLISHED
<------------ I2 ---------------
Re-create context
with new CT(peer) I2-SENT
and Ls(peer).
ESTABLISHED
------------- R2 -------------->
ESTABLISHED ESTABLISHED
Figure 7: Context Loss at Sender
図7：送信者のコンテキストの損失
Since each end might garbage collect the context state, we can have the case where one end has retained the context state and tries to use it, while the other end has lost the state. We discussed this in the previous section on recovery. But, for the same reasons, when one host retains Context Tag X as CT(peer) for ULID pair <A1, B1>, the other end might end up allocating that Context Tag as CT(local) for another ULID pair (e.g., <A3, B1>) between the same hosts. In this case, we cannot use the recovery mechanisms since there needs to be separate Context Tags for the two ULID pairs.
各終わるかもしれないごみは、コンテキスト状態を収集しているので、私たちは、一端がコンテキスト状態を保持し、もう一方の端は状態を失ったが、それを使用しようとしたケースを持つことができます。私たちは、回復の前のセクションでこれを議論しました。 1つのホストがULIDペア<A1、B1>のためにCT（ピア）としてコンテキストタグXを保持する場合でも、同じ理由で、もう一方の端は、例えば（別のULIDペアの（ローカル）CTように、そのコンテキストタグを割り当てるに終わるかもしれません<A3、B1>）同じホスト間。 2 ULIDのペアのための独立したコンテキストタグがある必要があるので、このケースでは、リカバリ・メカニズムを使用することはできません。
This type of "confusion" can be observed in two cases (assuming it is A that has retained the state and B that has dropped it):
「混乱」のこのタイプは、（それが低下した状態とBを保持しているものであると仮定して）2つの場合に観察することができます。
o B decides to create a context for ULID pair <A3, B1>, allocates X as its Context Tag for this, and sends an I1 to A.
O Bは、ULID対<A3、B1>のためのコンテキストを作成することを決定し、このためにそのコンテキストタグとしてXを割り当て、AにI1を送信します。
o A decides to create a context for ULID pair <A3, B1> and starts the exchange by sending I1 to B. When B receives the I2 message, it allocates X as the Context Tag for this context.
O AはULID対<A3、B1>のためのコンテキストを作成することを決定し、BはI2メッセージを受信し、それは、このコンテキストのコンテキストタグとしてXを割り当てる場合BにI1を送信することによって、交換を開始します。
In both cases, A can detect that B has allocated X for ULID pair <A3, B1> even though A still has X as CT(peer) for ULID pair <A1, B1>. Thus, A can detect that B must have lost the context for <A1, B1>.
両方の場合において、Aは、Bは、Aがまだ<A1、B1> ULIDペアのCTとしてX（ピア）を有していてもULID対<A3、B1>のためのXが割り当てられている検出することができます。従って、Aは、Bが<A1、B1>のコンテキストを失っている必要があります検出することができます。
The confusion can be detected when I2/I2bis/R2 is received, since we require that those messages MUST include a sufficiently large set of locators in a Locator List option that the peer can determine whether or not two contexts have the same host as the peer by comparing if there is any common locators in Ls(peer).
I2 / I2bis / R2を受信したときに、我々はそれらのメッセージは、ピアは、2つのコンテキストがピアと同じホストを持っているかどうかを判断することができるロケータリストオプションにロケータの十分に大きなセットを含まなければならないことを必要とするため、混乱を検出することができますLsの（ピア）のいずれかの一般的なロケータが存在する場合に比較して。
The old context that used the Context Tag MUST be removed; it can no longer be used to send packets. Thus, A would forcibly remove the context state for <A1, B1, X> so that it can accept the new context for <A3, B1, X>. An implementation MAY re-create a context to replace the one that was removed -- in this case, for <A1, B1>. The normal I1, R1, I2, R2 establishment exchange would then pick unique Context Tags for that replacement context. This re-creation is OPTIONAL, but might be useful when there is ULP communication that is using the ULID pair whose context was removed.
コンテキストタグを使用し、古いコンテキストを削除する必要があります。もはやパケットを送信するために使用することはできません。従って、Aは、強制的に<A1、B1、X>が<A3、B1、X>のために新しいコンテキストを受け入れることができるようにするためのコンテキスト状態を除去するであろう。 <A1、B1>のために、このケースで - 実装が削除されたものを置き換えるために、コンテキストを再作成することができます。通常I1、R1、I2、R2の確立交換は、その交換用のコンテキストのためのユニークなコンテキストタグを選ぶだろう。この再作成はオプションですが、コンテキスト削除されたULIDのペアを使用しているULPの通信がある場合に便利かもしれません。
Note that an I1 message with a duplicate Context Tag should not cause the removal of the old context state; this operation needs to be deferred until the reception of the I2 message.
重複コンテキストタグを持つI1メッセージが古いコンテキスト状態の除去を起こすべきではないことに注意してください。この操作は、I2メッセージを受信するまで延期する必要があります。
When the shim layer decides to set up a context for a ULID pair, it starts by allocating and initializing the context state for its end. As part of this, it assigns a random Context Tag to the context that is not being used as CT(local) by any other context . In the case that a new API is used and the ULP requests a forked context, the Forked Instance Identifier value will be set to a non-zero value. Otherwise, the FII value is zero. Then the initiator can send an I1 message and set the context STATE to I1-SENT. The I1 message MUST include the ULID pair -- normally, in the IPv6 Source and Destination fields. But if the ULID pair for the context is not used as a locator pair for the I1 message, then a ULID option MUST be included in the I1 message. In addition, if a Forked Instance Identifier value is non-zero, the I1 message MUST include a Context Instance Identifier option containing the correspondent value.
シム層はULIDペアのコンテキストを設定することを決定すると、その端のコンテキスト状態を割り当てて初期化することによって開始します。その一環として、それは、他のコンテキストによってCT（ローカル）として使用されていないコンテキストにランダムコンテキストタグを割り当てます。新しいAPIが使用され、ULPはフォークコンテキストを要求する場合には、フォークトインスタンス識別子の値がゼロ以外の値に設定されます。それ以外の場合は、FII値はゼロです。その後、イニシエータは、I1メッセージを送信し、I1-SENTにコンテキスト状態を設定することができます。通常、IPv6の送信元と送信先の分野で - I1メッセージはULIDのペアを含まなければなりません。コンテキストのULIDペアがI1メッセージのロケータペアとして使用されていない場合は、次にULIDオプションはI1メッセージに含まれなければなりません。また、フォークト・インスタンス識別子の値が非ゼロである場合、I1メッセージは対応した値を含むコンテキスト・インスタンス識別子オプションを含まなければなりません。
If the host does not receive an R1 or R2 message in response to the I1 message after I1_TIMEOUT time, then it needs to retransmit the I1 message. The retransmissions should use a retransmission timer with binary exponential backoff to avoid creating congestion issues for the network when lots of hosts perform I1 retransmissions. Also, the actual timeout value should be randomized between 0.5 and 1.5 of the nominal value to avoid self-synchronization.
ホストがI1_TIMEOUT時間後I1メッセージに応答して、R1やR2メッセージを受信しない場合、それはI1メッセージを再送信する必要があります。再送信は、ホストの多くはI1の再送を実行するときにネットワークの輻輳の問題を作成しないように、バイナリ指数バックオフして再送タイマーを使用する必要があります。また、実際のタイムアウト値は0.5と自己同期化を避けるために、公称値の1.5との間にランダム化されるべきです。
If, after I1_RETRIES_MAX retransmissions, there is no response, then most likely the peer does not implement the Shim6 protocol (or there could be a firewall that blocks the protocol). In this case, it makes sense for the host to remember not to try again to establish a context with that ULID. However, any such negative caching should be retained for at most NO_R1_HOLDDOWN_TIME, in order to be able to later set up a context should the problem have been that the host was not reachable at all when the shim tried to establish the context.
、I1_RETRIES_MAX再送信後、応答がない場合は、最も可能性の高いピアがSHIM6プロトコルを実装していない（またはそのブロックのプロトコルにファイアウォールがあるかもしれません）。ホストがそのULIDとのコンテキストを確立するために、再度試してみません覚えておくために、この場合には、それは理にかなっています。しかし、そのようなネガティブキャッシュは後にコンテキストを設定することができるようにするために、問題がシムはコンテキストを確立しようとしたときに、ホストが全く到達しなかったことをされている必要があり、ほとんどのNO_R1_HOLDDOWN_TIMEでのために保持する必要があります。
If the host receives an ICMP error with "Unrecognized Next Header" type (type 4, code 1) and the included packet is the I1 message it just sent, then this is a more reliable indication that the peer ULID does not implement Shim6. Again, in this case, the host should remember not to try again to establish a context with that ULID. Such negative caching should be retained for at most ICMP_HOLDDOWN_TIME, which should be significantly longer than the previous case.
ホストは、「認識できない次ヘッダ」タイプ（タイプ4、コード1）とICMPエラーを受信し、含まれるパケットは、それがちょうど送信I1メッセージである場合、これは、ピアULIDがSHIM6を実装していないことがより信頼できる指標です。繰り返しますが、この場合には、ホストがそのULIDとのコンテキストを確立するために再試行しないで覚えておいてください。このようなネガティブキャッシュは、以前の場合よりも大幅に長くする必要があります最もICMP_HOLDDOWN_TIME、でために保持する必要があります。
A host MUST silently discard any received I1 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに12.3節で指定されたものに加えて、以下の妥当性チェックのすべてを満たさないどんな受信I1メッセージを捨てなければなりません。
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
O HDR拡張LENフィールドは、少なくとも1であり、すなわち、長さが少なくとも16オクテットです。
Upon the reception of an I1 message, the host extracts the ULID pair and the Forked Instance Identifier from the message. If there is no ULID-pair option, then the ULID pair is taken from the Source and Destination fields in the IPv6 header. If there is no FII option in the message, then the FII value is taken to be zero.
I1メッセージを受信すると、ホストは、メッセージからULID対およびフォークトインスタンス識別子を抽出します。何ULIDペアオプションがない場合、ULIDのペアは、IPv6ヘッダーの送信元と送信先フィールドから取得されます。メッセージにはFIIオプションがない場合、FII値がゼロであるとみなされます。
Next, the host looks for an existing context that matches the ULID pair and the FII.
次に、ホストは、ULIDのペアとFIIに一致する既存のコンテキストを探します。
If no state is found (i.e., the STATE is IDLE), then the host replies with an R1 message as specified below.
ない状態（すなわち、STATEがアイドル状態である）見つからない場合、以下に指定されるように、ホストは、R1メッセージで応答します。
If such a context exists in ESTABLISHED STATE, the host verifies that the locator of the initiator is included in Ls(peer). (This check is unnecessary if there is no ULID-pair option in the I1 message.)
そのようなコンテキストは、設立された状態で存在する場合、ホストは、イニシエータのロケータをLsと（ピア）に含まれていることを検証します。 （I1メッセージにはULID対のオプションが存在しない場合、このチェックは不要です。）
If the state exists in ESTABLISHED STATE and the locators do not fall in the locator sets, then the host replies with an R1 message as specified below. This completes the I1 processing, with the context STATE being unchanged.
状態がESTABLISHED状態で存在し、ロケータがロケータセットに該当しない場合は、以下のように指定し、ホストは、R1メッセージで応答します。これは、コンテキスト状態は変わらないもので、I1の処理を完了します。
If the state exists in ESTABLISHED STATE and the locators do fall in the sets, then the host compares CT(peer) for the context with the CT contained in the I1 message.
状態が設立された状態で存在し、ロケータがセットに落ちるならば、ホストはI1メッセージに含まれるCTとコンテキストのCT（ピア）とを比較します。
o If the Context Tags match, then this probably means that the R2 message was lost and this I1 is a retransmission. In this case, the host replies with an R2 message containing the information available for the existent context.
コンテキストマッチにタグを付けた場合は、O、これはおそらく、R2メッセージが失われたことを意味し、このI1は再送信です。この場合、ホストは、既存のコンテキストのために利用可能な情報を含むR2メッセージで応答します。
o If the Context Tags do not match, then it probably means that the initiator has lost the context information for this context and is trying to establish a new one for the same ULID pair. In this case, the host replies with an R1 message as specified below. This completes the I1 processing, with the context STATE being unchanged.
コンテキストタグが一致しない場合は、O、それはおそらく、イニシエータは、このコンテキストのコンテキスト情報が失われたと同じULIDのペアのために新しいものを確立しようとしていることを意味します。以下に指定されるように、この場合、ホストは、R1メッセージで応答します。これは、コンテキスト状態は変わらないもので、I1の処理を完了します。
If the state exists in other STATE (I1-SENT, I2-SENT, I2BIS-SENT), we are in the situation of concurrent context establishment, described in Section 7.4. In this case, the host leaves CT(peer) unchanged and replies with an R2 message. This completes the I1 processing, with the context STATE being unchanged.
状態が他方の状態（I1-SENT、I2-SENT、I2BIS-SENT）に存在する場合、我々は、セクション7.4で説明同時コンテキスト確立の状況にあります。この場合、ホストは不変CT（ピア）を残し、R2メッセージで応答します。これは、コンテキスト状態は変わらないもので、I1の処理を完了します。
When the host needs to send an R1 message in response to the I1 message, it copies the Initiator Nonce from the I1 message to the R1 message, generates a Responder Nonce, and calculates a Responder Validator option as suggested in the following section. No state is created on the host in this case. (Note that the information used to generate the R1 reply message is either contained in the received I1 message or is global information that is not associated with the particular requested context (the S and the Responder Nonce values.))
ホストはI1メッセージに応答してR1のメッセージを送信する必要がある場合、R1メッセージに対するI1メッセージからコピーしイニシエータnonceを、レスポンダnonceを生成し、次のセクションで示唆したようにレスポンダ検証オプションを算出します。いかなる状態は、この場合、ホスト上に作成されません。 （情報を受信I1メッセージに含まれるかR1応答メッセージを生成するために使用されるか、または特定の要求されたコンテキスト（Sとレスポンダノンス値に関連付けられていないグローバルな情報であることに注意してください。））
When the host needs to send an R2 message in response to the I1 message, it copies the Initiator Nonce from the I1 message to the R2 message, and otherwise follows the normal rules for forming an R2 message (see Section 7.14).
ホストはI1メッセージに応答して、R2メッセージを送信する必要があるとき、それはR2メッセージにI1メッセージからコピーイニシエータnonceを、それ以外R2メッセージを形成するための通常の規則に従う（セクション7.14を参照）。
As it is stated in Section 5.15.1, the validator-generation mechanism is a local choice since the validator is generated and verified by the same node, i.e., the responder. However, in order to provide the required protection, the validator needs to be generated by fulfilling the conditions described in Section 5.15.1. One way for the responder to properly generate validators is to maintain a single secret (S) and a running counter (C) for the Responder Nonce that is incremented in fixed periods of time (this allows the responder to verify the age of a Responder Nonce, independently of the context in which it is used).
それは、セクション5.15.1に記載されたように、バリ発生のメカニズムは、バリデータが同じノードによって生成され、検証されているので、ローカルの選択、すなわち、レスポンダです。しかし、必要な保護を提供するために、バリデータは、セクション5.15.1に記載された条件を満たすことで生成する必要があります。適切バリデータを生成するために応答するための一つの方法は、単一の秘密（S）と、時間の固定期間でインクリメントされるレスポンダノンスのランニングカウンタ（C）を維持することである（これは、レスポンダノンスの年齢を確認する応答を可能にします、独立して、それが使用される文脈の）。
When the validator is generated to be included in an R1 message sent in response to a specific I1 message, the responder can perform the following procedure to generate the validator value:
バリデータは、特定I1メッセージに応答して送信されたR1メッセージに含まれるように生成されると、レスポンダは、バリデータ値を生成するために、次の手順を実行することができます。
First, the responder uses the current counter C value as the Responder Nonce.
まず、レスポンダはレスポンダノンスとして現在のカウンタCの値を使用します。
Second, it uses the following information (concatenated) as input to the one-way function:
第二に、それは一方向関数への入力として、以下の情報（連結）を使用します。
o The secret S
秘密S O
o That Responder Nonce
ナンス返信こと
o The Initiator Context Tag from the I1 message
I1メッセージからイニシエータコンテキストタグO
o The ULIDs from the I1 message
I1メッセージからULIDs O
o The locators from the I1 message (strictly only needed if they are different from the ULIDs)
I1メッセージからロケータO（彼らはULIDsと異なっている場合、厳密にのみ必要）
o The Forked Instance Identifier, if such option was included in the I1 message
フォークトインスタンス識別子O、そのようなオプションはI1メッセージに含まれていた場合
Third, it uses the output of the hash function as the validator value included in the R1 message.
第三に、それはR1メッセージに含まれるバリ値としてハッシュ関数の出力を使用します。
A host MUST silently discard any received R1 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに12.3節で指定されたものに加えて、以下の妥当性チェックのすべてを満たさないどんな受信R1メッセージを捨てなければなりません。
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
O HDR拡張LENフィールドは、少なくとも1であり、すなわち、長さが少なくとも16オクテットです。
Upon the reception of an R1 message, the host extracts the Initiator Nonce and the Locator Pair from the message (the latter from the Source and Destination fields in the IPv6 header). Next, the host looks for an existing context that matches the Initiator Nonce and where the locators are contained in Ls(peer) and Ls(local), respectively. If no such context is found, then the R1 message is silently discarded.
R1メッセージを受信すると、ホストは、メッセージ（IPv6ヘッダーの送信元および宛先フィールドから後者）からイニシエータノンスとロケータペアを抽出します。次に、ホストは、ロケータは、それぞれLsの（ピア）及びLS（ローカル）に含まれているイニシエータとノンスと一致する既存のコンテキストを探し。そのような状況が見つからない場合、R1のメッセージは静かに捨てられます。
If such a context is found, then the host looks at the STATE:
そのような状況が発見された場合、ホストはSTATEになります。
o If the STATE is I1-SENT, then it sends an I2 message as specified below.
STATEは、I1-送信される場合、以下に指定されるように、O、それはI2メッセージを送信します。
o In any other STATE (I2-SENT, I2BIS-SENT, ESTABLISHED), then the host has already sent an I2 message and this is probably a reply to a retransmitted I1 message, so this R1 message MUST be silently discarded.
O他の状態（I2-SENT、I2BIS-SENT、ESTABLISHED）で、ホストはすでにI2メッセージを送信しており、これはおそらく再送I1メッセージに対する応答であるので、このR1メッセージは静かに捨てなければなりません。
When the host sends an I2 message, it includes the Responder Validator option that was in the R1 message. The I2 message MUST include the ULID pair -- normally, in the IPv6 Source and Destination fields. If a ULID-pair option was included in the I1 message, then it MUST be included in the I2 message as well. In addition, if the Forked Instance Identifier value for this context is non-zero, the I2 message MUST contain a Forked Instance Identifier option carrying the Forked Instance Identifier value. Besides, the I2 message contains an Initiator Nonce. This is not required to be the same as the one included in the previous I1 message.
ホストはI2メッセージを送信するときに、R1メッセージにあったレスポンダバリデータのオプションが含まれています。通常、IPv6の送信元と送信先の分野で - I2のメッセージは、ULIDのペアを含まなければなりません。 ULID対オプションがI1メッセージに含まれていた場合、それは同様にI2メッセージに含まれなければなりません。このコンテキストのフォークトインスタンス識別子の値が非ゼロである場合に加えて、I2のメッセージは、フォークト・インスタンス識別子の値を運ぶフォークトインスタンス識別子オプションを含まなければなりません。また、I2メッセージには、イニシエータnonceを含んでいます。これは、以前のI1メッセージに含まれたものと同じである必要はありません。
The I2 message may also include the initiator's locator list. If this is the case, then it must also include the CGA Parameter Data Structure. If CGA (and not HBA) is used to verify one or more of the locators included in the locator list, then the initiator must also include a CGA Signature option containing the signature.
I2メッセージには、イニシエータのロケータリストを含むことができます。このような場合は、それはまたCGAパラメータデータ構造を含める必要があります。 CGA（としないHBA）がロケータリストに含まれるロケータの一つ以上を確認するために使用される場合、開始剤はまた、署名を含むCGA署名オプションを含める必要があります。
When the I2 message has been sent, the STATE is set to I2-SENT.
I2メッセージが送信された場合、状態はI2-SENTに設定されています。
If the initiator does not receive an R2 message after I2_TIMEOUT time after sending an I2 message, it MAY retransmit the I2 message, using binary exponential backoff and randomized timers. The Responder Validator option might have a limited lifetime -- that is, the peer might reject Responder Validator options that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In the case that the initiator decides not to retransmit I2 messages, or in the case that the initiator still does not receive an R2 message after retransmitting I2 messages I2_RETRIES_MAX times, the initiator SHOULD fall back to retransmitting the I1 message.
イニシエータはI2メッセージを送信した後I2_TIMEOUT時間後にR2メッセージを受信しない場合、それは、バイナリ指数バックオフとランダム化されたタイマーを使用して、I2のメッセージを再送信することができます。レスポンダバリオプションは限られた寿命を持っているかもしれない - つまり、ピアは、リプレイ攻撃を避けるためにVALIDATOR_MIN_LIFETIMEより古いレスポンダバリデータのオプションを拒否することがあります。イニシエータはI2メッセージを再送信しないと決定した場合、または場合イニシエータがまだI2メッセージをI2_RETRIES_MAX回再送した後、R2メッセージを受信しないことを、イニシエータは、I1メッセージを再送信にフォールバックすべきです。
A host MUST silently discard any received I2 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに12.3節で指定されたものに加えて、以下の妥当性チェックのすべてを満たさないどんな受信I2メッセージを捨てなければなりません。
o The Hdr Ext Len field is at least 2, i.e., the length is at least 24 octets.
O HDR拡張LENフィールドは、少なくとも2であり、すなわち、長さが少なくとも24オクテットです。
Upon the reception of an I2 message, the host extracts the ULID pair and the Forked Instance Identifier from the message. If there is no ULID-pair option, then the ULID pair is taken from the Source and Destination fields in the IPv6 header. If there is no FII option in the message, then the FII value is taken to be zero.
I2メッセージを受信すると、ホストは、メッセージからULID対およびフォークトインスタンス識別子を抽出します。何ULIDペアオプションがない場合、ULIDのペアは、IPv6ヘッダーの送信元と送信先フィールドから取得されます。メッセージにはFIIオプションがない場合、FII値がゼロであるとみなされます。
Next, the host verifies that the Responder Nonce is a recent one (nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent) and that the Responder Validator option matches the validator the host would have computed for the ULID, locators, Responder Nonce, Initiator Nonce, and FII.
次に、ホストは、レスポンダnonceが最近のもの（無VALIDATOR_MIN_LIFETIMEは最近考慮されるべきであるよりも古いナンス）であるとResponderの検証オプションは、ホストがULID、ロケータ、レスポンダナンス、イニシエータに対して計算されているでしょうバリデータと一致していることをことを確認しますノンス、およびFII。
If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify if the actual PDS contained in the message corresponds to the ULID(peer).
CGAパラメータデータ構造（PDS）がメッセージに含まれている場合、メッセージに含まれる実際のPDSがULID（ピア）に対応する場合、ホストは確認しなければなりません。
If any of the above verifications fail, then the host silently discards the message; it has completed the I2 processing.
上記検証のいずれかが失敗した場合、ホストは静かにメッセージを破棄する。それはI2の処理を完了しました。
If all the above verifications are successful, then the host proceeds to look for a context state for the initiator. The host looks for a context with the extracted ULID pair and FII. If none exist, then STATE of the (non-existing) context is viewed as being IDLE; thus, the actions depend on the STATE as follows:
上記のすべての検証が成功した場合、ホストは、イニシエータのためのコンテキスト状態を探しに進みます。ホストは、抽出されたULIDペアとFIIとのコンテキストを探します。何も存在しない場合、（存在しない）コンテキストの状態がIDLEであるとみなされます。次のようにこのように、アクションはSTATEによって異なります。
o If the STATE is IDLE (i.e., the context does not exist), the host allocates a Context Tag (CT(local)), creates the context state for the context, and sets its STATE to ESTABLISHED. It records CT(peer) and the peer's locator set as well as its own locator set in the context. It SHOULD perform the HBA/CGA verification of the peer's locator set at this point in time, as specified in Section 7.2. Then, the host sends an R2 message back as specified below.
O STATE（すなわち、コンテキストが存在しない）アイドル状態の場合、ホストは、コンテキストタグ（CT）（ローカル）は、コンテキストのコンテキスト状態を作成割り当て、および確立されたために、その状態を設定します。これは、CT（ピア）を記録し、ピアのロケータは、コンテキストに設定された独自のロケータとしても設定します。セクション7.2で指定されたように、それは、この時点で設定ピアのロケータのHBA / CGA検証を実行する必要があります。以下に指定されるように、その後、ホストはR2メッセージを返送します。
o If the STATE is I1-SENT, then the host verifies if the source locator is included in Ls(peer) or in the Locator List contained in the I2 message and that the HBA/CGA verification for this specific locator is successful.
STATEは、I1-送信される場合、ソースロケータがI2メッセージに含まれ、この特定のロケータのHBA / CGA検証が成功したことをLsと（ピア）またはロケータリストに含まれている場合、O、ホストは検証します。
* If this is not the case, then the message is silently discarded and the context STATE remains unchanged.
そうでない場合は*、その後、メッセージは静かに破棄され、コンテキスト状態は変更されません。
* If this is the case, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2 message, and the host MUST send an R2 message back as specified below. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The host moves to ESTABLISHED STATE.
*この場合、ホストはI2メッセージに含まれるデータとコンテキスト情報（CT（ピア）、Lsは（ピア））を更新し、以下に示すように、ホストはR2メッセージを返送しなければなりません。セクション7.2で指定されるようにLsの（ピア）の情報を更新する前に、ホストは、この時点で設定ピアのロケータのHBA / CGA検証を実行すべきであることに留意されたいです。ホストがESTABLISHED状態に移動します。
o If the STATE is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host verifies if the source locator is included in Ls(peer) or in the Locator List contained in the I2 message and that the HBA/CGA verification for this specific locator is successful.
ソースロケータがLsの（ピア）またはロケータのリストに含まれていれば、状態が確立されると、I2-SENT、またはI2BIS-SENT O、ホストはI2メッセージ及びこれに対するHBA / CGA検証ことが含まれる検証します特定のロケータは成功しています。
* If this is not the case, then the message is silently discarded and the context STATE remains unchanged.
そうでない場合は*、その後、メッセージは静かに破棄され、コンテキスト状態は変更されません。
* If this is the case, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2 message, and the host MUST send an R2 message back as specified in Section 7.14. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The context STATE remains unchanged.
*この場合、ホストはI2メッセージに含まれるデータとコンテキスト情報（CT（ピア）、Lsは（ピア））を更新し、セクション7.14で指定されたホストは、R2メッセージを返送しなければなりません。セクション7.2で指定されるようにLsの（ピア）の情報を更新する前に、ホストは、この時点で設定ピアのロケータのHBA / CGA検証を実行すべきであることに留意されたいです。コンテキスト状態は変わりません。
Before the host sends the R2 message, it MUST look for a possible context confusion, i.e., where it would end up with multiple contexts using the same CT(peer) for the same peer host. See Section 7.15.
ホストはR2メッセージを送信する前に、それは同じピア・ホストに同じCT（ピア）を使用して複数のコンテキストで終わるであろう可能なコンテキストの混乱、即ち、を探さなければなりません。セクション7.15を参照してください。
When the host needs to send an R2 message, the host forms the message and its Context Tag, and copies the Initiator Nonce from the triggering message (I2, I2bis, or I1). In addition, it may include alternative locators and necessary options so that the peer can verify them. In particular, the R2 message may include the responder's locator list and the PDS option. If CGA (and not HBA) is used to verify the locator list, then the responder also signs the key parts of the message and includes a CGA Signature option containing the signature.
ホストはR2メッセージを送信する必要がある場合、ホストは、メッセージとそのコンテキストタグ、コピー開始トリガメッセージからノンス（I2、I2bis、又はI1）を形成します。ピアがそれらを確認できるように、また、別のロケータと必要なオプションを含んでもよいです。具体的には、R2のメッセージは、応答者のロケータリストとPDSのオプションを含むことができます。 CGA（としないHBA）がロケータリストを検証するために使用される場合、次いでレスポンダは、メッセージの重要な部分に署名し、署名を含むCGA署名オプションを含みます。
R2 messages are never retransmitted. If the R2 message is lost, then the initiator will retransmit either the I2/I2bis or I1 message. Either retransmission will cause the responder to find the context state and respond with an R2 message.
R2メッセージが再送されることはありません。 R2メッセージが失われた場合、その後、イニシエータはI2 / I1 I2bis又はメッセージのいずれかを再送します。どちらの再送信は、コンテキスト状態を見つけ、R2メッセージで応答する応答を引き起こします。
When the host receives an I2, I2bis, or R2, it MUST look for a possible context confusion, i.e., where it would end up with multiple contexts using the same CT(peer) for the same peer host. This can happen when the host has received the above messages, since they create a new context with a new CT(peer). The same issue applies when CT(peer) is updated for an existing context.
ホストはI2、I2bis、又はR2を受信すると、それは、同じピア・ホストに同じCT（ピア）を使用して複数のコンテキストで終わるであろう可能なコンテキストの混乱、即ち、を探さなければなりません。彼らは新しいCT（ピア）との新しいコンテキストを作成するため、ホストは、上記のメッセージを受信したときに発生することがあります。 CT（ピア）は、既存のコンテキストのために更新されたときに同じ問題が適用されます。
The host takes CT(peer) for the newly created or updated context, and looks for other contexts which:
ホストは、新しく作成されたか、更新されたコンテキストのためにCT（ピア）を取り、そしてどの他のコンテキストを探します。
o Are in STATE ESTABLISHED or I2BIS-SENT
O STATEに確立されているかI2BIS-SENT
o Have the same CT(peer)
O持っている同じCT（ピア）
o Have an Ls(peer) that has at least one locator in common with the newly created or updated context
O持って、新しく作成されたか、更新されたコンテキストで少なくとも1つの共通のロケータを持っているLsは（ピア）
If such a context is found, then the host checks if the ULID pair or the Forked Instance Identifier are different than the ones in the newly created or updated context:
そのようなコンテキストが見つかった場合、ホストチェックULID対又はフォークトインスタンス識別子は、新たに作成または更新されたコンテキスト内のものとは異なる場合。
o If either or both are different, then the peer is reusing the Context Tag for the creation of a context with different ULID pair or FII, which is an indication that the peer has lost the original context. In this case, we are in a context confusion situation, and the host MUST NOT use the old context to send any packets. It MAY just discard the old context (after all, the peer has discarded it), or it MAY attempt to re-establish the old context by sending a new I1 message and moving its STATE to I1-SENT. In any case, once that this situation is detected, the host MUST NOT keep two contexts with overlapping Ls(peer) locator sets and the same Context Tag in ESTABLISHED STATE, since this would result in demultiplexing problems on the peer.
いずれかまたは両方が異なる場合、O、ピアは、ピアは、元のコンテキストを失ったことを示す別ULID対またはFIIとコンテキストを作成するためのコンテキストタグを再利用されます。この場合、我々はコンテキストの混乱状況にあり、ホストはすべてのパケットを送信するために、古いコンテキストを使用してはなりません。それだけで（結局、相手がそれを廃棄した）古いコンテキストを破棄したり、それが新しいI1メッセージを送信し、I1-SENTにその状態を移動して、古いコンテキストを再確立しようとします。これは、ピアの分離の問題につながるので、いずれの場合も、一度このような状況が検出されたことを、ホストは、ESTABLISHED状態での重複Lsは（ピア）ロケータセットと同じコンテキストタグで2つのコンテキストを維持してはなりません。
o If both are the same, then this context is actually the context that is created or updated; hence, there is no confusion.
両者が同じであれば、O、そしてこのような状況は、実際に作成または更新されたコンテキストです。したがって、混乱はありません。
A host MUST silently discard any received R2 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに12.3節で指定されたものに加えて、以下の妥当性チェックのすべてを満たさないどんな受信R2メッセージを捨てなければなりません。
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
O HDR拡張LENフィールドは、少なくとも1であり、すなわち、長さが少なくとも16オクテットです。
Upon the reception of an R2 message, the host extracts the Initiator Nonce and the Locator Pair from the message (the latter from the Source and Destination fields in the IPv6 header). Next, the host looks for an existing context that matches the Initiator Nonce and where the locators are Lp(peer) and Lp(local), respectively. Based on the STATE:
R2メッセージを受信すると、ホストは、メッセージ（IPv6ヘッダーの送信元および宛先フィールドから後者）からイニシエータノンスとロケータペアを抽出します。次に、ホストは、イニシエータノンスと一致し、ロケータは、それぞれのLp（ピア）とLP（ローカル）である既存のコンテキストを探します。状態に基づいて：
o If no such context is found, i.e., the STATE is IDLE, then the message is silently dropped.
そのようなコンテキストが見つからない場合、O、即ち、STATEがアイドル状態である場合、メッセージは黙って廃棄されます。
o If STATE is I1-SENT, I2-SENT, or I2BIS-SENT, then the host performs the following actions. If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify that the actual PDS contained in the message corresponds to the ULID(peer) as specified in Section 7.2. If the verification fails, then the message is silently dropped. If the verification succeeds, then the host records the information from the R2 message in the context state; it records the peer's locator set and CT(peer). The host SHOULD perform the HBA/CGA verification of the peer's locator set at this point in time, as specified in Section 7.2. The host sets its STATE to ESTABLISHED.
STATEは、I1-SENT、I2-SENT、またはI2BIS-送信される場合、O、ホストは次のアクションを実行します。 CGAパラメータデータ構造（PDS）は、メッセージに含まれている場合、ホストは、セクション7.2で指定されたメッセージに含まれる実際のPDSがULID（ピア）に対応していることを確認しなければなりません。検証が失敗した場合、メッセージは黙って落とされます。検証が成功した場合、ホストは、コンテキスト状態でR2メッセージからの情報を記録します。それはピアのロケータセットとCT（ピア）を記録します。ホストは、セクション7.2で指定されるように、この時点で設定ピアのロケータのHBA / CGA検証を実行する必要があります。ホストは、確立にその状態を設定します。
o If the STATE is ESTABLISHED, the R2 message is silently ignored, (since this is likely to be a reply to a retransmitted I2 message).
状態が確立されている場合（これは再送I2メッセージへの応答である可能性が高いため）O、R2メッセージは黙って、無視されます。
Before the host completes the R2 processing, it MUST look for a possible context confusion, i.e., where it would end up with multiple contexts using the same CT(peer) for the same peer host. See Section 7.15.
ホストはR2の処理を完了する前に、それは同じピア・ホストに同じCT（ピア）を使用して複数のコンテキストで終わるであろう可能なコンテキストの混乱、即ち、を探さなければなりません。セクション7.15を参照してください。
Upon the receipt of a Shim6 Payload Extension header where there is no current Shim6 context at the receiver, the receiver is to respond with an R1bis message in order to enable a fast re-establishment of the lost Shim6 context.
受信機では電流SHIM6コンテキストが存在しないSHIM6ペイロード拡張ヘッダを受信すると、受信器は失わSHIM6コンテキストの速い再確立を可能にするためにR1bisメッセージで応答することです。
Also, a host is to respond with an R1bis upon receipt of any control messages that have a message type in the range 64-127 (i.e., excluding the context-setup messages such as I1, R1, R1bis, I2, I2bis, R2, and future extensions), where the control message refers to a non-existent context.
また、ホストは、I1、R1、R1bis、I2、I2bis、R2、としてコンテキストセットアップメッセージを除く、範囲64-127（すなわち、メッセージタイプを持つ任意の制御メッセージを受信するとR1bisで応答しますそして将来の拡張）は、ここで、制御メッセージが存在しない状況を指します。
We assume that all the incoming packets that trigger the generation of an R1bis message contain a locator pair (in the address fields of the IPv6 header) and a Context Tag.
我々はR1bisメッセージの生成をトリガするすべての着信パケットが（IPv6ヘッダのアドレスフィールド内の）ロケータペアとコンテキストタグを含むと仮定する。
Upon reception of any of the packets described above, the host will reply with an R1bis including the following information:
上記パケットのいずれかを受信すると、ホストは、次の情報を含むR1bisで応答します。
o The Responder Nonce is a number picked by the responder that the initiator will return in the I2bis message.
レスポンダノンスoをイニシエータがI2bisメッセージに戻ることレスポンダで撮像された番号です。
o Packet Context Tag is the Context Tag contained in the received packet that triggered the generation of the R1bis message.
OパケットコンテキストタグはR1bisメッセージの生成をトリガし、受信したパケットに含まれるコンテキスト・タグです。
o The Responder Validator option is included, with a validator that is computed as suggested in the next section.
Oレスポンダ検証オプションは、次のセクションで示唆したように計算されるバリデータと、含まれています。
One way for the responder to properly generate validators is to maintain a single secret (S) and a running counter C for the Responder Nonce that is incremented in fixed periods of time (this allows the responder to verify the age of a Responder Nonce, independently of the context in which it is used).
適切バリデータを生成するために応答するための一つの方法は、単一の秘密（S）と、時間の固定期間でインクリメントされたレスポンダナンス用ランニングカウンタCを維持することである（これは、独立して、レスポンダは、レスポンダノンスの年齢を確認することができそれが使用される文脈の）。
When the validator is generated to be included in an R1bis message -- that is, sent in response to a specific control packet or a packet containing the Shim6 Payload Extension header message -- the responder can perform the following procedure to generate the validator value:
バリはR1bisメッセージに含まれるように生成された場合 - すなわち、特定の制御パケット又はSHIM6ペイロード拡張ヘッダメッセージを含むパケットに応答して送信 - 応答は、バリデータ値を生成するために、次の手順を実行することができます。
First, the responder uses the counter C value as the Responder Nonce.
まず、レスポンダはレスポンダノンスとしてカウンタCの値を使用します。
Second, it uses the following information (concatenated) as input to the one-way function:
第二に、それは一方向関数への入力として、以下の情報（連結）を使用します。
o The secret S
秘密S O
o That Responder Nonce
ナンス返信こと
o The Receiver Context Tag included in the received packet
Oレシーバコンテキストタグは、受信したパケットに含ま
o The locators from the received packet
受信したパケットからロケータO
Third, it uses the output of the hash function as the validator string.
第三に、それはバリデータ列としてハッシュ関数の出力を使用しています。
A host MUST silently discard any received R1bis messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに12.3節で指定されたものに加えて、以下の妥当性チェックのすべてを満たさないどんな受信R1bisメッセージを捨てなければなりません。
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
O HDR拡張LENフィールドは、少なくとも1であり、すなわち、長さが少なくとも16オクテットです。
Upon the reception of an R1bis message, the host extracts the Packet Context Tag and the Locator Pair from the message (the latter from the Source and Destination fields in the IPv6 header). Next, the host looks for an existing context where the Packet Context Tag matches CT(peer) and where the locators match Lp(peer) and Lp(local), respectively.
R1bisメッセージを受信すると、ホストは、メッセージ（IPv6ヘッダーの送信元および宛先フィールドから後者）からパケットコンテキストタグとロケータペアを抽出します。次に、ホストは、パケットコンテキストタグは、CT（ピア）とここでロケータは、それぞれのLp（ピア）とLP（ローカル）と一致すると一致する既存のコンテキストを探し。
o If no such context is found, i.e., the STATE is IDLE, then the R1bis message is silently discarded.
そのようなコンテキストが見つからない場合、O、すなわち、状態がIDLE、次いでR1bisメッセージは黙って破棄されます。
o If the STATE is I1-SENT, I2-SENT, or I2BIS-SENT, then the R1bis message is silently discarded.
STATEは、I1-SENT、I2-SENT、またはI2BIS-送信される場合、O、次いでR1bisメッセージは黙って破棄されます。
o If the STATE is ESTABLISHED, then we are in the case where the peer has lost the context, and the goal is to try to re-establish it. For that, the host leaves CT(peer) unchanged in the context state, transitions to I2BIS-SENT STATE, and sends an I2bis message, including the computed Responder Validator option, the Packet Context Tag, and the Responder Nonce that were received in the R1bis message. This I2bis message is sent using the locator pair included in the R1bis message. In the case that this locator pair differs from the ULID pair defined for this context, then a ULID option MUST be included in the I2bis message. In addition, if the Forked Instance Identifier for this context is non-zero, then a Forked Instance Identifier option carrying the instance identifier value for this context MUST be included in the I2bis message. The I2bis message may also include a locator list. If this is the case, then it must also include the CGA Parameter Data Structure. If CGA (and not HBA) is used to verify one or more of the locators included in the locator list, then the initiator must also include a CGA Signature option containing the signature.
STATEが確立されている場合は、O、そして私たちは、ピアがコンテキストを失った場合にあり、目標はそれを再確立しようとすることです。そのため、ホストは、コンテキスト状態で変化しないCT（ピア）を残すI2BIS-SENT状態に遷移し、計算されたレスポンダ検証オプション、パケットコンテキストタグ、及びで受信されたレスポンダノンスを含む、I2bisメッセージを送信します。 R1bisメッセージ。このI2bisメッセージはR1bisメッセージに含まロケータペアを使用して送信されます。このロケータペアは、このコンテキストに定義されたULID対と異なる場合には、次にULIDオプションはI2bisメッセージに含まれなければなりません。このコンテキストのフォークトインスタンス識別子が非ゼロである場合に加えて、このコンテキストのインスタンス識別子の値を運ぶフォークトインスタンス識別子オプションはI2bisメッセージに含まれなければなりません。 I2bisメッセージはまた、ロケータリストを含むことができます。このような場合は、それはまたCGAパラメータデータ構造を含める必要があります。 CGA（としないHBA）がロケータリストに含まれるロケータの一つ以上を確認するために使用される場合、開始剤はまた、署名を含むCGA署名オプションを含める必要があります。
If the initiator does not receive an R2 message after I2bis_TIMEOUT time after sending an I2bis message, it MAY retransmit the I2bis message, using binary exponential backoff and randomized timers. The Responder Validator option might have a limited lifetime -- that is, the peer might reject Responder Validator options that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In the case that the initiator decides not to retransmit I2bis messages, or in the case that the initiator still does not receive an R2 message after retransmitting I2bis messages I2bis_RETRIES_MAX times, the initiator SHOULD fall back to retransmitting the I1 message.
イニシエータはI2bisメッセージを送信した後I2bis_TIMEOUT時間後にR2メッセージを受信しない場合、それは、バイナリ指数バックオフとランダム化されたタイマーを使用して、I2bisメッセージを再送信することができます。レスポンダバリオプションは限られた寿命を持っているかもしれない - つまり、ピアは、リプレイ攻撃を避けるためにVALIDATOR_MIN_LIFETIMEより古いレスポンダバリデータのオプションを拒否することがあります。イニシエータはI2bisメッセージを再送信する、または開始剤が依然としてI2bisメッセージI2bis_RETRIES_MAX回再送した後、R2メッセージを受信しない場合にはしないことを決定する場合には、イニシエータは、I1メッセージを再送信にフォールバックすべきです。
A host MUST silently discard any received I2bis messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに任意のセクション12.3で指定されたものに加えて、以下の妥当性チェックのすべてを満たさないI2bisメッセージを受信捨てなければなりません：
o The Hdr Ext Len field is at least 3, i.e., the length is at least 32 octets.
O HDR拡張LENフィールドは、少なくとも3であるすなわち、長さが少なくとも32オクテットです。
Upon the reception of an I2bis message, the host extracts the ULID pair and the Forked Instance Identifier from the message. If there is no ULID-pair option, then the ULID pair is taken from the Source and Destination fields in the IPv6 header. If there is no FII option in the message, then the FII value is taken to be zero.
I2bisメッセージを受信すると、ホストは、メッセージからULID対およびフォークトインスタンス識別子を抽出します。何ULIDペアオプションがない場合、ULIDのペアは、IPv6ヘッダーの送信元と送信先フィールドから取得されます。メッセージにはFIIオプションがない場合、FII値がゼロであるとみなされます。
Next, the host verifies that the Responder Nonce is a recent one (nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent) and that the Responder Validator option matches the validator the host would have computed for the locators, Responder Nonce, and Receiver Context Tag as part of sending an R1bis message.
次に、ホストは、レスポンダnonceが最近のもの（無VALIDATOR_MIN_LIFETIMEは最近考慮されるべきであるよりも古いナンス）であるとResponderの検証オプションは、ホストがロケータのために計算されているでしょうバリ、レスポンダノンス、およびレシーバコンテキストと一致していることをことを確認しますR1bisメッセージを送るの一部としてタグ付け。
If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify if the actual PDS contained in the message corresponds to the ULID(peer).
CGAパラメータデータ構造（PDS）がメッセージに含まれている場合、メッセージに含まれる実際のPDSがULID（ピア）に対応する場合、ホストは確認しなければなりません。
If any of the above verifications fail, then the host silently discards the message; it has completed the I2bis processing.
上記検証のいずれかが失敗した場合、ホストは静かにメッセージを破棄する。それはI2bis処理を完了しました。
If both verifications are successful, then the host proceeds to look for a context state for the initiator. The host looks for a context with the extracted ULID pair and FII. If none exist, then STATE of the (non-existing) context is viewed as being IDLE; thus, the actions depend on the STATE as follows: o If the STATE is IDLE (i.e., the context does not exist), the host allocates a Context Tag (CT(local)), creates the context state for the context, and sets its STATE to ESTABLISHED. The host SHOULD NOT use the Packet Context Tag in the I2bis message for CT(local); instead, it should pick a new random Context Tag just as when it processes an I2 message. It records CT(peer) and the peer's locator set as well as its own locator set in the context. It SHOULD perform the HBA/CGA verification of the peer's locator set at this point in time, as specified in Section 7.2. Then the host sends an R2 message back as specified in Section 7.14.
両方の検証が成功した場合、ホストは、イニシエータのためのコンテキスト状態を探しに進みます。ホストは、抽出されたULIDペアとFIIとのコンテキストを探します。何も存在しない場合、（存在しない）コンテキストの状態がIDLEであるとみなされます。次のようにこのように、アクションが状態に依存：STATEがアイドル状態の場合（つまり、コンテキストが存在しない）、ホストはコンテキストタグを割り当てO（CT）（ローカル）は、コンテキストのコンテキスト状態を作成し、セットその状態がために設立します。ホストは、CT用I2bisメッセージ（ローカル）でパケットコンテキストタグを使用しません。代わりに、それはちょうどそれがI2のメッセージを処理するときに、新しいランダムなコンテキストタグを選択する必要があります。これは、CT（ピア）を記録し、ピアのロケータは、コンテキストに設定された独自のロケータとしても設定します。セクション7.2で指定されたように、それは、この時点で設定ピアのロケータのHBA / CGA検証を実行する必要があります。その後、ホストは、7.14項で指定されたR2メッセージを送り返します。
o If the STATE is I1-SENT, then the host verifies if the source locator is included in Ls(peer) or in the Locator List contained in the I2bis message and if the HBA/CGA verification for this specific locator is successful.
STATEは、I1-送信される場合、ソースロケータがI2bisメッセージに含まLsの（ピア）またはロケータのリストに含まれていれば、この特定のロケータのHBA / CGA検証が成功した場合、O、ホストは検証します。
* If this is not the case, then the message is silently discarded. The context STATE remains unchanged.
そうでない場合は*、その後、メッセージは静かに捨てられます。コンテキスト状態は変わりません。
* If this is the case, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2bis message, and the host MUST send an R2 message back as specified below. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The host moves to ESTABLISHED STATE.
*この場合、ホストはI2bisメッセージに含まれるデータとコンテキスト情報（CT（ピア）、Lsは（ピア））を更新し、以下に示すように、ホストは、バックR2メッセージを送らなければなりません。セクション7.2で指定されるようにLsの（ピア）の情報を更新する前に、ホストは、この時点で設定ピアのロケータのHBA / CGA検証を実行すべきであることに留意されたいです。ホストがESTABLISHED状態に移動します。
o If the STATE is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host determines whether at least one of the two following conditions hold: i) if the source locator is included in Ls(peer) or, ii) if the source locator is included in the Locator List contained in the I2bis message and if the HBA/CGA verification for this specific locator is successful.
O状態が確立されると、I2-SENT、またはI2BIS-SENT、ホストは次の二つの条件の少なくとも一方が成立するか否かを判定するた：i）ソース・ロケータをLsと（ピア）に含まれる、または、IIされている場合）であればソース・ロケータがロケータリストに含まI2bisメッセージに含まれていると、この特定のロケータのHBA / CGAの検証が成功した場合です。
* If none of the two aforementioned conditions hold, then the message is silently discarded. The context STATE remains unchanged.
上記の2つの条件のいずれもが成立しない場合*、メッセージは黙って破棄されます。コンテキスト状態は変わりません。
* If at least one of the two aforementioned conditions hold, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2bis message, and the host MUST send an R2 message back, as specified in Section 7.14. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The context STATE remains unchanged.
上記の2つの条件の少なくとも一方が成立した場合*、ホストは（Lsの（ピア）CT（ピア））I2bisメッセージに含まれるデータと、ホストのように、バックR2メッセージを送信しなければならないコンテキスト情報を更新します7.14項で指定されました。セクション7.2で指定されるようにLsの（ピア）の情報を更新する前に、ホストは、この時点で設定ピアのロケータのHBA / CGA検証を実行すべきであることに留意されたいです。コンテキスト状態は変わりません。
The routers in the path as well as the destination might generate ICMP error messages. In some cases, the Shim6 can take action and solve the problem that resulted in the error. In other cases, the Shim6 layer cannot solve the problem, and it is critical that these packets make it back up to the ULPs so that they can take appropriate action.
パスだけでなく、先のルータはICMPエラーメッセージが生成される可能性があります。いくつかのケースでは、SHIM6は行動を取ると、エラーになった問題を解決することができます。他の例では、SHIM6層は、問題を解決することはできません、彼らが適切な行動をとることができるように、これらのパケットはバックのULPまでそれを作ることが重要です。
This is an implementation issue in the sense that the mechanism is completely local to the host itself. But the issue of how ICMP errors are correctly dispatched to the ULP on the host are important; hence, this section specifies the issue.
これは、メカニズムはホスト自体に完全にローカルであるという意味で、実装上の問題です。しかし、ICMPエラーが正しくホスト上のULPに派遣されているかの問題が重要です。したがって、このセクションでは、問題を指定します。
All ICMP messages MUST be delivered to the ULP in all cases, except when Shim6 successfully acts on the message (e.g., selects a new path). There SHOULD be a configuration option to unconditionally deliver all ICMP messages (including ones acted on by shim6) to the ULP.
すべてのICMPメッセージはSHIM6が正常に（例えば、新たな経路を選択する）、メッセージに作用する場合を除いて、全ての場合において、ULPに送達されなければなりません。無条件にULPに（SHIM6の作用を受けたものを含む）すべてのICMPメッセージを配信する設定オプションがあるはずです。
According to that recommendation, the following ICMP error messages should be processed by the Shim6 layer and not passed to the ULP:
その勧告によると、次のICMPエラーメッセージがSHIM6層によって処理されなければならないとULPに渡されません。
ICMP error Destination Unreachable, with codes: 0 (No route to destination) 1 (Communication with destination administratively prohibited) 2 (Beyond scope of source address) 3 (Address unreachable) 5 (Source address failed ingress/egress policy) 6 (Reject route to destination)
コードで到達不能ICMPエラー先：0（宛先へのNoルート）1（管理上禁止先との通信）2 5（送信元アドレスが失敗した入口/出口ポリシー）3（アドレス到達不能）（ソースアドレスの範囲を超えて）6（拒否経路）宛先へ
ICMP Time exceeded error.
ICMPタイムはエラーを上回りました。
ICMP Parameter problem error, with the parameter that caused the error being a Shim6 parameter.
SHIM6のパラメータであるエラーの原因となったパラメータを持つICMPパラメータ問題エラー、。
The following ICMP error messages report problems that cannot be addressed by the Shim6 layer and that should be passed to the ULP (as described below):
次のICMPエラーメッセージがSHIM6層によって対処することができないと（後述のように）それはULPに渡されるべき問題を報告します：
ICMP Packet too big error.
ICMPパケットが大きすぎるエラー。
ICMP Destination Unreachable with Code 4 (Port unreachable).
コード4（ポート到達不能）と到達不能ICMP宛先。
ICMP Parameter problem (if the parameter that caused the problem is not a Shim6 parameter).
ICMPパラメータ問題（問題の原因となったパラメータがSHIM6パラメータではない場合）。
+--------------+
| IPv6 Header |
| |
+--------------+
| ICMPv6 |
| Header |
- - +--------------+ - -
| IPv6 Header |
| src, dst as | Can be dispatched
IPv6 | sent by ULP | unmodified to ULP
| on host | ICMP error handler
Packet +--------------+
| ULP |
in | Header |
+--------------+
Error | |
~ Data ~
| |
- - +--------------+ - -
Figure 8: ICMP Error Handling without the
Shim6 Payload Extension Header
When the ULP packets are sent without the Shim6 Payload Extension header -- that is, while the initial locators=ULIDs are working -- this introduces no new concerns; an implementation's existing mechanism for delivering these errors to the ULP will work. See Figure 8.
ULPパケットはSHIM6ペイロード拡張ヘッダなしで送信されたとき - 初期ロケータながらつまり、= ULIDsが働いている - これは新しい問題を導入しません。 ULPにこれらのエラーを提供するための実装の既存のメカニズムが動作します。図8を参照してください。
But when the shim on the transmitting side inserts the Shim6 Payload Extension header and replaces the ULIDs in the IP address fields with some other locators, then an ICMP error coming back will have a "packet in error", which is not a packet that the ULP sent. Thus, the implementation will have to apply reverse mapping to the "packet in error" before passing the ICMP error up to the ULP, including the ICMP extensions defined in [25]. See Figure 9.
送信側のシムがSHIM6ペイロード拡張ヘッダを挿入し、他のいくつかのロケータとIPアドレスフィールドでULIDsを置き換えるときしかし、その後、戻ってくるICMPエラーパケットではありません「というエラーでパケットを」、持っているということULPを送信しました。したがって、実装は[25]で定義されたICMPの拡張を含む、ULPまでのICMPエラーを渡す前に、「誤ったパケット」への逆マッピングを適用する必要があります。図9を参照してください。
+--------------+
| IPv6 Header |
| |
+--------------+
| ICMPv6 |
| Header |
- - +--------------+ - -
| IPv6 Header |
| src, dst as | Needs to be
IPv6 | modified by | transformed to
| shim on host | have ULIDs
+--------------+ in src, dst fields,
Packet | Shim6 ext. | and Shim6 Ext.
| Header | header removed
in +--------------+ before it can be
| Transport | dispatched to the ULP
Error | Header | ICMP error handler.
+--------------+
| |
~ Data ~
| |
- - +--------------+ - -
Figure 9: ICMP Error Handling with the Shim6 Payload Extension Header
図9：SHIM6ペイロード拡張ヘッダを持つICMPエラー処理
Note that this mapping is different than when receiving packets from the peer with Shim6 Payload Extension headers because, in that case, the packets contain CT(local). But the ICMP errors have a "packet in error" with a Shim6 Payload Extension header containing CT(peer). This is because they were intended to be received by the peer. In any case, since the <Source Locator, Destination Locator, CT(peer)> has to be unique when received by the peer, the local host should also only be able to find one context that matches this tuple.
その場合、パケットは（ローカル）CTを含有するので、このマッピングはSHIM6ペイロード拡張ヘッダを持つピアからパケットを受信した場合とは異なることに留意されたいです。しかし、ICMPエラーはSHIM6ペイロード拡張ヘッダを含むCT（ピア）と「エラーでパケット」を有します。彼らはピアによって受信されることが意図されていたためです。いずれの場合も、<ソースロケータ、宛先ロケータ、CT（ピア）は>相手が受信したときに一意である必要があるため、ローカルホストは、これだけのタプルと一致するもののコンテキストを見つけることができるはずです。
If the ICMP error is a "packet too big", the reported MTU must be adjusted to be 8 octets less, since the shim will add 8 octets when sending packets.
ICMPエラーが「大きすぎるパケット」である場合は、パケットを送信するときに、シムは8つのオクテットを追加するために、報告されたMTUは、8つのオクテットより少なくなるように調整しなければなりません。
After the "packet in error" has had the original ULIDs inserted, then this Shim6 Payload Extension header can be removed. The result is a "packet in error" that is passed to the ULP which looks as if the shim did not exist.
「エラーでパケットが」オリジナルULIDs挿入あった後、このSHIM6ペイロード拡張ヘッダを除去することができます。その結果、シムが存在しなかったかのように見えますULPに渡され、「エラーでパケット」です。
Each host can unilaterally decide when to tear down a ULID-pair context. It is RECOMMENDED that hosts do not tear down the context when they know that there is some upper-layer protocol that might use the context. For example, an implementation might know this if there is an open socket that is connected to the ULID(peer). However, there might be cases when the knowledge is not readily available to the shim layer, for instance, for UDP applications that do not connect their sockets or for any application that retains some higher-level state across (TCP) connections and UDP packets.
ULIDペアコンテキストを取り壊すすると、各ホストが一方的に決めることができます。彼らが、コンテキストを使用する可能性がありますいくつかの上位層プロトコルがあることを知っているときホストがコンテキストを取り壊すしないことをお勧めします。 ULID（ピア）に接続されているオープンソケットが存在する場合、例えば、実装はこれを知っているかもしれません。知識が自分のソケットを接続していないUDPアプリケーションのためか（TCP）接続とUDPパケット間でいくつかのより高いレベルの状態を保持する任意のアプリケーションのために、例えば、シム層に容易に利用できない場合しかし、ケースがあるかもしれません。
Thus, it is RECOMMENDED that implementations minimize premature teardown by observing the amount of traffic that is sent and received using the context, and tear down the state only after it appears quiescent. A reasonable approach would be to not tear down a context until at least 5 minutes have passed since the last message was sent or received using the context. (Note that packets that use the ULID pair as a locator pair and that do not require address rewriting by the Shim6 layer are also considered as packets using the associated Shim6 context.)
したがって、実装がコンテキストを使用して送信し、受信されたトラフィックの量を観察することによって、早期ティアダウンを最小限にし、それが静止のみ表示された後の状態を取り壊すことが推奨されます。合理的なアプローチは、最後のメッセージがコンテキストを使用して送信または受信されてから少なくとも5分経過するまでコンテキストを切断しないことであろう。 （ロケータペアとしてULID対を使用し、それはSHIM6層によってアドレスの書き換えを必要としないパケットは、関連するSHIM6コンテキストを使用してパケットとみなされることに注意してください。）
Since there is no explicit, coordinated removal of the context state, there are potential issues around Context Tag reuse. One end might remove the state and potentially reuse that Context Tag for some other communication, and the peer might later try to use the old context (which it didn't remove). The protocol has mechanisms to recover from this, which work whether the state removal was total and accidental (e.g., crash and reboot of the host) or just a garbage collection of shim state that didn't seem to be used. However, the host should try to minimize the reuse of Context Tags by trying to randomly cycle through the 2^47 Context Tag values. (See Appendix C for a summary of how the recovery works in the different cases.)
コンテキスト状態の明示的、協調的除去が存在しないため、コンテキストタグの再利用の周りの潜在的な問題があります。一方の端は状態を削除して、潜在的にいくつかの他の通信のためにそのコンテキストタグを再利用し、ピアは、後で（それが削除されませんでした）古いコンテキストを使用しようとする場合があります。プロトコルは、状態の除去は、総および偶発（ホストの例えば、クラッシュして再起動）したかどうかを作業この状態から回復するためのメカニズム、または使用されていないようでしたシム状態のちょうどガベージコレクションを持っています。ただし、ホストは2 ^ 47コンテキストタグ値によってランダムサイクルしようとすることで、コンテキストタグの再利用を最小限にしようとする必要があります。 （回復が異なる場合にどのように動作するかの概要については、付録Cを参照してください。）
The Update Request and Acknowledgement are used both to update the list of locators (only possible when CGA is used to verify the locator(s)) and to update the preferences associated with each locator.
更新要求と肯定応答が（CGAはロケータ（単数または複数）を確認するために使用された場合にのみ可能）ロケータのリストを更新するために、各ロケータに関連付けられた設定を更新するための両方に使用されます。
When a host has a change in the locator set, it can communicate this to the peer by sending an Update Request. When a host has a change in the preferences for its locator set, it can also communicate this to the peer. The Update Request message can include just a Locator List option (to convey the new set of locators), just a Locator Preferences option, or both a new Locator List and new Locator Preferences.
ホストはロケータセットの変更がある場合は、更新要求を送信することによって、ピアに、これを通信することができます。ホストはそのロケータセットの環境の変化がある場合、それはまた、ピアに、これを通信することができます。更新要求メッセージは、単にロケータリストオプション（ロケータの新しいセットを伝えるために）、単にロケータ環境設定オプション、または新しいロケータのリストと新しいロケータの設定の両方を含めることができます。
Should the host send a new Locator List, the host picks a new random, local generation number, records this in the context, and puts it in the Locator List option. Any Locator Preference option, whether sent in the same Update Request or in some future Update Request, will use that generation number to make sure the preferences get applied to the correct version of the locator list.
ホストが新しいロケータのリストを送信する必要があり、ホストは、新たなランダム、地元の世代番号を選ぶ文脈でこれを記録し、ロケータリスト]オプションに入れます。どれロケータ優先オプションは、同じ更新要求にまたはいくつかの将来の更新要求で送信されたかどうか、好みがロケータリストの正しいバージョンに適用され得ることを確認するために、その世代番号を使用します。
The host picks a random Request Nonce for each update and keeps the same nonce for any retransmissions of the Update Request. The nonce is used to match the acknowledgement with the request.
ホストは、更新ごとにランダムな要求のnonceを選ぶとアップデート要求のいずれかの再送信のために同じnonceを保持します。ナンスは、要求に確認応答を一致させるために使用されます。
The Update Request message can also include a CGA Parameter Data Structure (this is needed if the CGA PDS was not previously exchanged). If CGA (and not HBA) is used to verify one or more of the locators included in the locator list, then a CGA Signature option containing the signature must also be included in the Update Request message.
（CGA PDSは以前に交換されていなかった場合、これは必要とされている）更新要求メッセージはまた、CGAパラメータデータ構造を含めることができます。 CGA（としないHBA）がロケータリストに含まれるロケータの一つ以上を確認するために使用されている場合は、署名を含むCGA署名オプションは、更新要求メッセージに含まれていなければなりません。
If the host does not receive an Update Acknowledgement R2 message in response to the Update Request message after UPDATE_TIMEOUT time, then it needs to retransmit the Update Request message. The retransmissions should use a retransmission timer with binary exponential backoff to avoid creating congestion issues for the network when lots of hosts perform Update Request retransmissions. Also, the actual timeout value should be randomized between 0.5 and 1.5 of the nominal value to avoid self-synchronization.
ホストがUPDATE_TIMEOUT時間後の更新要求メッセージに応答して更新確認応答R2メッセージを受信しない場合、それは更新要求メッセージを再送信する必要があります。再送信は、ホストの多くは更新要求の再送信を実行するときにネットワークの輻輳の問題を作成しないように、バイナリ指数バックオフして再送タイマーを使用する必要があります。また、実際のタイムアウト値は0.5と自己同期化を避けるために、公称値の1.5との間にランダム化されるべきです。
Should there be no response, the retransmissions continue forever. The binary exponential backoff stops at MAX_UPDATE_TIMEOUT. But the only way the retransmissions would stop when there is no acknowledgement is when Shim6, through the REAP protocol or some other mechanism, decides to discard the context state due to lack of ULP usage in combination with no responses to the REAP protocol.
無応答でなければなりません、再送信は永遠に続けます。バイナリ指数バックオフはMAX_UPDATE_TIMEOUTで停止します。しかし、確認応答がない場合には再送信が停止する唯一の方法はSHIM6は、REAPプロトコルまたは他のいくつかのメカニズムを介して、原因REAPプロトコルへの無応答との組み合わせでULPの使用量の不足のためにコンテキスト状態を破棄することを決定したときです。
There can be at most one outstanding Update Request message at any time. Thus until, for example, an update with a new Locator List has been acknowledged, any newer Locator List or new Locator Preferences cannot just be sent. However, when there is newer information and the older information has not yet been acknowledged, the host can, instead of waiting for an acknowledgement, abandon the previous update and construct a new Update Request (with a new Request Nonce) that includes the new information as well as the information that hasn't yet been acknowledged.
任意の時点で最大1つの優れた更新要求メッセージが存在する場合があります。例えば、新しいロケータのリストとの更新が認められている、までこのように、任意の新しいロケータ一覧や、新たなロケータの設定だけで送信することはできません。しかし、まだ確認されていない新しい情報と古い情報があり、新たな情報が含まれ、代わりに受信確認を待つのではなく、以前の更新を放棄し、（新しいRequestナンス付き）新しい更新要求を構築することができますホストだけでなく、まだ確認されていない情報。
For example, if the original locator list was just (A1, A2), and if an Update Request with the Locator List (A1, A3) is outstanding, and the host determines that it should both add A4 to the locator list and mark A1 as BROKEN, then it would need to:
たとえば、元ロケータリストは、ちょうど（A1、A2）だった場合、およびロケータリスト（A1、A3）とアップデート要求が顕著である、そしてホストはそれが両方のロケータリストとマークA1にA4を追加すべきであると判断した場合BROKENとして、それはする必要があります：
o Pick a new random Request Nonce for the new Update Request.
O新しい更新要求のための新しいランダム要求のnonceを選択します。
o Pick a new random generation number for the new locator list.
O新しいロケータリストのための新しいランダムな世代番号を選択します。
o Form the new locator list: (A1, A3, A4).
（A1、A3、A4）：Oの新しいロケータのリストを形成します。
o Form a Locator Preference option that uses the new generation number and has the BROKEN flag for the first locator.
O新しい世代番号を使用し、最初のロケータの中断フラグを有するロケータ優先オプションを形成しています。
o Send the Update Request and start a retransmission timer.
O更新要求を送信し、再送タイマーを起動します。
Any Update Acknowledgement that doesn't match the current Request Nonce (for instance, an acknowledgement for the abandoned Update Request) will be silently ignored.
現在のリクエストナンスと一致していない任意の更新確認応答（例えば、放棄された更新要求に対する肯定応答）は無視されます。
A host MUST silently discard any received Update Request messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに任意のセクション12.3で指定されたものに加えて、以下の妥当性チェックのすべてを満たさない更新要求メッセージを受信捨てなければなりません：
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
O HDR拡張LENフィールドは、少なくとも1であり、すなわち、長さが少なくとも16オクテットです。
Upon the reception of an Update Request message, the host extracts the Context Tag from the message. It then looks for a context that has a CT(local) that matches the Context Tag. If no such context is found, it sends an R1bis message as specified in Section 7.17.
更新要求メッセージを受信すると、ホストは、メッセージからコンテキストタグを抽出します。その後、コンテキストタグに一致するCT（ローカル）を持つコンテキストを探します。そのような状況が見つからない場合は、セクション7.17で指定され、それがR1bisメッセージを送信します。
Since Context Tags can be reused, the host MUST verify that the IPv6 Source Address field is part of Ls(peer) and that the IPv6 Destination Address field is part of Ls(local). If this is not the case, the sender of the Update Request has a stale context that happens to match the CT(local) for this context. In this case, the host MUST send an R1bis message and otherwise ignore the Update Request message.
コンテキストタグを再利用することができますので、ホストは、IPv6ソースアドレスフィールドは、Lsの一部（ピア）で、IPv6の宛先アドレスフィールドには、（ローカル）Lsの一部であることをことを確かめなければなりません。そうでない場合は、アップデート要求の送信者は、このコンテキストのCT（ローカル）を一致させるためにたまたま古いコンテキストを持っています。この場合、ホストはR1bisメッセージを送信し、そうでない場合は更新要求メッセージを無視しなければなりません。
If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify if the actual PDS contained in the packet corresponds to the ULID(peer). If this verification fails, the message is silently discarded.
CGAパラメータデータ構造（PDS）は、メッセージに含まれていれば、パケットに含まれる実際のPDSがULID（ピア）に対応する場合、ホストは確認しなければなりません。この検証が失敗した場合、メッセージは静かに捨てられます。
Then, depending on the STATE of the context:
次に、コンテキストの状態に応じて：
o If ESTABLISHED, proceed to process message.
ESTABLISHED場合は、O、メッセージを処理するために進みます。
o If I1-SENT, discard the message and stay in I1-SENT.
O I1-SENT場合は、メッセージを破棄し、I1-SENTに滞在。
o If I2-SENT, send I2 and proceed to process the message.
O I2-SENT場合、I2を送信し、メッセージを処理するために進みます。
o If I2BIS-SENT, send I2bis and proceed to process the message.
O I2BIS-SENT場合は、I2bisを送信し、メッセージを処理するために進みます。
The verification issues for the locators carried in the Update Request message are specified in Section 7.2. If the locator list cannot be verified, this procedure should send a Shim6 Error message with Error Code=2. In any case, if it cannot be verified, there is no further processing of the Update Request.
更新要求メッセージで運ばロケータに対する検証問題はセクション7.2で指定されています。ロケータリストが確認できない場合は、この手順は、エラーコード= 2でSHIM6エラーメッセージを送信する必要があります。それが確認できない場合はいずれの場合にも、更新要求のさらなる処理はありません。
Once any Locator List option in the Update Request has been verified, the peer generation number in the context is updated to be the one in the Locator List option.
更新要求に任意のロケータリスト]オプションが確認されると、コンテキスト内のピア世代番号は、ロケータリストのオプションの1に更新されます。
If the Update Request message contains a Locator Preference option, then the generation number in the preference option is compared with the peer generation number in the context. If they do not match, then the host generates a Shim6 Error message with Error Code=3 and with the Pointer field referring to the first octet in the Locator List Generation number in the Locator Preference option. In addition, if the number of elements in the Locator Preference option does not match the number of locators in Ls(peer), then a Shim6 Error message with Error Code=4 is sent with the Pointer field referring to the first octet of the Length field in the Locator Preference option. In both cases of failure, no further processing is performed for the Update Request message.
更新要求メッセージは、ロケータ優先オプションが含まれている場合、優先オプションで世代番号は、コンテキスト内のピアの世代番号とを比較します。それらが一致しない場合、ホストは、エラーコード= 3とし、ポインタフィールドはロケータ優先オプションでロケータ一覧世代番号の最初のオクテットを参照してSHIM6エラーメッセージを生成します。また、ロケータ優先オプションの要素の数は、Lsの（ピア）にロケータの数と一致しない場合、次に= 4がポインタフィールドは、長さの最初のオクテットを参照して送信されるエラーコードをSHIM6エラーメッセージロケータ優先オプションのフィールド。失敗の両方の場合において、さらなる処理は、更新要求メッセージのために実行されません。
If the generation numbers match, the locator preferences are recorded in the context.
世代番号が一致した場合、ロケータの好みは、コンテキスト内に記録されています。
Once the Locator List option (if present) has been verified and any new locator list or locator preferences have been recorded, the host sends an Update Acknowledgement message, copying the nonce from the request and using the CT(peer) as the Receiver Context Tag.
ロケータリストオプションが（もしあれば）確認されているし、新しいロケータリストまたはロケータ好みが記録されていたら、ホストが要求からナンスをコピーし、更新確認メッセージを送信し、受信側のコンテキストタグとしてCT（ピア）を使用して、 。
Any new locators (or, more likely, new locator preferences) might result in the host wanting to select a different locator pair for the context -- for instance, if the Locator Preferences option lists the current Lp(peer) as BROKEN. The host uses the reachability exploration procedure described in [4] to verify that the new locator is reachable before changing Lp(peer).
例えば、ロケータ環境設定オプションがBROKENとして現在のLp（ピア）を一覧表示した場合 - すべての新しいロケータ（または、より多くの可能性が高い、新しいロケータの好みは）コンテキストの異なるロケータペアを選択したいホストになる可能性があります。ホストが新しいロケータのLp（ピア）を変更する前に、到達可能であることを確認する[4]に記載の到達性探査手順を使用します。
A host MUST silently discard any received Update Acknowledgement messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
ホストは静かに12.3節で指定されたものに加えて、以下の妥当性チェックのすべてを満たさないどんな受信された更新確認応答メッセージを捨てなければなりません。
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
O HDR拡張LENフィールドは、少なくとも1であり、すなわち、長さが少なくとも16オクテットです。
Upon the reception of an Update Acknowledgement message, the host extracts the Context Tag and the Request Nonce from the message. It then looks for a context that has a CT(local) that matches the Context Tag. If no such context is found, it sends an R1bis message as specified in Section 7.17.
更新肯定応答メッセージを受信すると、ホストは、コンテキストタグ及びメッセージからの要求nonceを抽出します。その後、コンテキストタグに一致するCT（ローカル）を持つコンテキストを探します。そのような状況が見つからない場合は、セクション7.17で指定され、それがR1bisメッセージを送信します。
Since Context Tags can be reused, the host MUST verify that the IPv6 Source Address field is part of Ls(peer) and that the IPv6 Destination Address field is part of Ls(local). If this is not the case, the sender of the Update Acknowledgement has a stale context that happens to match the CT(local) for this context. In this case, the host MUST send an R1bis message and otherwise ignore the Update Acknowledgement message.
コンテキストタグを再利用することができますので、ホストは、IPv6ソースアドレスフィールドは、Lsの一部（ピア）で、IPv6の宛先アドレスフィールドには、（ローカル）Lsの一部であることをことを確かめなければなりません。そうでない場合は、アップデート確認応答の送信者は、このコンテキストのCT（ローカル）を一致させるためにたまたま古いコンテキストを持っています。この場合、ホストはR1bisメッセージを送信し、そうでなければ更新確認メッセージを無視しなければなりません。
Then, depending on the STATE of the context:
次に、コンテキストの状態に応じて：
o If ESTABLISHED, proceed to process message.
ESTABLISHED場合は、O、メッセージを処理するために進みます。
o If I1-SENT, discard the message and stay in I1-SENT.
O I1-SENT場合は、メッセージを破棄し、I1-SENTに滞在。
o If I2-SENT, send R2 and proceed to process the message.
O I2-SENT場合は、R2を送信し、メッセージを処理するために進みます。
o If I2BIS-SENT, send R2 and proceed to process the message.
O I2BIS-SENT場合は、R2を送信し、メッセージを処理するために進みます。
If the Request Nonce doesn't match the nonce for the last sent Update Request for the context, then the Update Acknowledgement is silently ignored. If the nonce matches, then the update has been completed and the Update retransmit timer can be reset.
リクエストnonceがコンテキストの最後に送信更新要求のためにナンスと一致しない場合は、[更新謝辞は黙って無視されます。ナンスが一致した場合、更新が完了し、更新再送信タイマーをリセットすることができます。
When there is no context state for the ULID pair on the sender, there is no effect on how ULP packets are sent. If the host is using some heuristic for determining when to perform a deferred context establishment, then the host might need to do some accounting (count the number of packets sent and received) even before there is a ULID-pair context.
送信者のULIDのペアのためのコンテキスト状態が存在しない場合には、ULPのパケットが送信される方法に影響はありません。ホストは繰延コンテキスト確立を実行するかを決定するために、いくつかのヒューリスティックを使用している場合、ホストはULIDペアコンテキストがあっても前にいくつかの会計処理を行う（送信されたパケットの数をカウントし、受信）する必要がある場合があります。
If the context is not in ESTABLISHED or I2BIS-SENT STATE, then there is also no effect on how the ULP packets are sent. Only in the ESTABLISHED and I2BIS-SENT STATEs does the host have CT(peer) and Ls(peer) set.
コンテキストが確立されるかI2BIS-SENT状態でない場合は、ULPパケットの送信方法には何の影響もありません。のみ確立し、I2BIS-SENTの状態でホストがCT（ピア）とLS（ピア）のセットを持っていません。
If there is a ULID-pair context for the ULID pair, then the sender needs to verify whether the context uses the ULIDs as locators -- that is, whether Lp(peer) == ULID(peer) and Lp(local) == ULID(local).
ULIDペアのULID対コンテキストがある場合、送信者は、文脈がロケータとしてULIDsを使用するかどうかを確認する必要がある - つまり、Lpの（ピア）== ULID（ピア）とLP（ローカル）かどうか== ULID（ローカル）。
If this is the case, then packets can be sent unmodified by the shim. If it is not the case, then the logic in Section 11.1 will need to be used.
このような場合は、パケットは、シムでそのまま送信することができます。それがない場合は、セクション11.1内のロジックを使用する必要があります。
There will also be some maintenance activity relating to (un)reachability detection, whether or not packets are sent with the original locators. The details of this are out of scope for this document and are specified in [4].
また、パケットが元ロケータに送信されたかどうか、（UN）到達可能性の検出に関連するいくつかのメンテナンス・アクティビティがあります。これの詳細は、この文書の範囲外であり、[4]で指定されています。
When sending packets, if there is a ULID-pair context for the ULID pair, and if the ULID pair is no longer used as the locator pair, then the sender needs to transform the packet. Apart from replacing the IPv6 Source and Destination fields with a locator pair, an 8-octet header is added so that the receiver can find the context and inverse the transformation.
ULIDペアはもはやロケータペアとして使用されている場合ULIDペアのULIDペアコンテキストがある場合は、パケットを送信しない、とすると、送信者は、パケットを変換する必要があります。受信器はコンテキストを検索し、変換を反転することができるように離れて位置決め対とIPv6の送信元と送信先のフィールドを交換するから、8オクテットのヘッダが付加されます。
If there has been a failure causing a switch, and later the context switches back to sending things using the ULID pair as the locator pair, then there is no longer a need to do any packet transformation by the sender; hence, there is no need to include the 8-octet Extension header.
スイッチを引き起こして失敗がなかった、と後でコンテキストがバックロケータペアとしてULIDのペアを使用して物事を送信することに切り替え、その後、送信者によって任意のパケット変換を行う必要がなくなった場合。従って、8オクテット拡張ヘッダを含める必要はありません。
First, the IP address fields are replaced. The IPv6 Source Address field is set to Lp(local) and the Destination Address field is set to Lp(peer). Note that this MUST NOT cause any recalculation of the ULP checksums, since the ULP checksums are carried end-to-end and the ULP pseudo-header contains the ULIDs that are preserved end-to-end.
まず、IPアドレスフィールドが置き換えられます。 IPv6のソースアドレスフィールドは、（ローカル）と宛先アドレスフィールドはLpの（ピア）に設定されているのLpに設定されています。 ULPチェックサムは、エンドツーエンドを運ばれ、ULP疑似ヘッダは、エンドツーエンドの保存されULIDsを含むので、これは、ULPチェックサムの再計算を引き起こしてはならないことに留意されたいです。
The sender skips any "Routing Sublayer Extension headers" that the ULP might have included; thus, it skips any Hop-by-Hop Extension header, any Routing header, and any Destination Options header that is followed by a Routing header. After any such headers, the Shim6 Extension header will be added. This might be before a Fragment header, a Destination Options header, an ESP or AH header, or a ULP header.
送信者は、ULPが含まれている可能性のある「ルーティングサブレイヤ拡張ヘッダ」をスキップします。従って、これは、任意のホップバイホップ拡張ヘッダ、任意のルーティングヘッダ、ルーティングヘッダに続いて任意の宛先オプションヘッダをスキップします。このようなヘッダー後、SHIM6拡張ヘッダが追加されます。これは、フラグメントヘッダー、宛先オプションヘッダー、ESPまたはAHヘッダー、またはULPヘッダーの前にあるかもしれません。
The inserted Shim6 Payload Extension header includes the peer's Context Tag. It takes on the Next Header value from the preceding Extension header, since that Extension header will have a Next Header value of Shim6.
挿入SHIM6ペイロード拡張ヘッダは、ピアのコンテキストタグを含みます。その拡張ヘッダはSHIM6の次ヘッダ値を有することになるので、それは、先行する拡張ヘッダの次ヘッダ値をとります。
The receive side of the communication can receive packets associated to a Shim6 context, with or without the Shim6 Extension header. In case the ULID pair is being used as a locator pair, the packets received will not have the Shim6 Extension header and will be processed by the Shim6 layer as described below. If the received packet does carry the Shim6 Extension header, as in normal IPv6 receive-side packet processing, the receiver parses the (extension) headers in order. Should it find a Shim6 Extension header, it will look at the "P" field in that header. If this bit is zero, then the packet must be passed to the Shim6 payload handling for rewriting. Otherwise, the packet is passed to the Shim6 control handling.
通信の受信側は、またはSHIM6拡張ヘッダなしで、SHIM6コンテキストに関連するパケットを受信することができます。場合ULIDペアがロケータペアとして使用され、受信されたパケットはSHIM6拡張ヘッダを持たず、以下に説明するようにSHIM6層によって処理されます。受信したパケットが通常のIPv6受信側パケット処理と同様に、SHIM6拡張ヘッダを搬送した場合、受信機は、順番に（拡張）ヘッダを解析します。それはSHIM6拡張ヘッダを見つける必要があり、それはそのヘッダに「P」欄を見ていきます。このビットがゼロである場合、パケットは書き換えに取り扱いSHIM6ペイロードに渡す必要があります。そうでない場合、パケットはSHIM6制御処理に渡されます。
The receiver extracts the IPv6 Source and Destination fields and uses this to find a ULID-pair context, such that the IPv6 address fields match the ULID(local) and ULID(peer). If such a context is found, the context appears not to be quiescent; this should be remembered in order to avoid tearing down the context and for reachability detection purposes as described in [4]. The host continues with the normal processing of the IP packet.
受信機は、IPv6アドレスフィールドがULID（ローカル）とULID（ピア）と一致するように、IPv6の送信元と送信先のフィールドを抽出し、ULID対コンテキストを見つけるためにこれを使用します。こうした状況が見つかった場合、コンテキストが静止状態ではないと表示されます記載されているように、これはコンテキストを切断回避するために、および到達可能性検出のために忘れてはならない[4]。ホストは、IPパケットの通常の処理を続行します。
The receiver extracts the Context Tag from the Shim6 Payload Extension header and uses this to find a ULID-pair context. If no context is found, the receiver SHOULD generate an R1bis message (see Section 7.17).
受信機はSHIM6ペイロード拡張ヘッダからコンテキストタグを抽出し、ULID対コンテキストを見つけるためにこれを使用します。コンテキストが見つからない場合、受信機は、（セクション7.17を参照）R1bisメッセージを生成する必要があります。
Then, depending on the STATE of the context:
次に、コンテキストの状態に応じて：
o If ESTABLISHED, proceed to process message.
ESTABLISHED場合は、O、メッセージを処理するために進みます。
o If I1-SENT, discard the message and stay in I1-SENT.
O I1-SENT場合は、メッセージを破棄し、I1-SENTに滞在。
o If I2-SENT, send I2 and proceed to process the message.
O I2-SENT場合、I2を送信し、メッセージを処理するために進みます。
o If I2BIS-SENT, send I2bis and proceed to process the message.
O I2BIS-SENT場合は、I2bisを送信し、メッセージを処理するために進みます。
With the context in hand, the receiver can now replace the IP address fields with the ULIDs kept in the context. Finally, the Shim6 Payload Extension header is removed from the packet (so that the ULP doesn't get confused by it), and the Next Header value in the preceding header is set to be the actual protocol number for the payload. Then the packet can be passed to the protocol identified by the Next Header value (which might be some function associated with the IP endpoint sublayer or a ULP).
手のコンテキストでは、受信機は今ULIDsとIPアドレスフィールドがコンテキストに保持置き換えることができます。最後に、SHIM6ペイロード拡張ヘッダは、パケット（ULPそれによって混乱しないように）から除去され、そして前のヘッダの次のヘッダ値は、ペイロードの実際のプロトコル番号に設定されています。次いで、パケットは、次ヘッダ値によって識別プロトコル（IPエンドポイント副層またはULPに関連したいくつかの関数であるかもしれない）に渡すことができます。
If the host is using some heuristic for determining when to perform a deferred context establishment, then the host might need to do some accounting (count the number of packets sent and received) for packets that do not have a Shim6 Extension header and for which there is no context. But the need for this depends on what heuristics the implementation has chosen.
ホストが延期コンテキスト確立を実行するかを決定するために、いくつかのヒューリスティックを使用している場合は、ホストは、いくつかの会計処理を行うために必要がある場合がありますSHIM6拡張ヘッダを持たないパケットのために、そこにいる（送信されたパケットの数をカウントし、受信しました）何のコンテキストではありません。しかし、これの必要性は、実装が選択したものをヒューリスティックに依存します。
A shim control message has the Checksum field verified. The Shim Header Length field is also verified against the length of the IPv6 packet to make sure that the shim message doesn't claim to end past the end of the IPv6 packet. Finally, it checks that neither the IPv6 Destination field nor the IPv6 Source field is a multicast address or an unspecified address. If any of those checks fail, the packet is silently dropped.
シム制御メッセージは、検証チェックサムフィールドがあります。シムヘッダ長フィールドはまた、シムメッセージはIPv6パケットの最後を超えて終了と主張していないことを確認するために、IPv6パケットの長さに対して検証されます。最後に、IPv6宛先フィールドでもIPv6のソース]フィールドでもないが、マルチキャストアドレスまたは未指定のアドレスであることを確認します。これらのチェックのいずれかが失敗した場合、パケットは黙って落とされます。
The message is then dispatched based on the shim message type. Each message type is then processed as described elsewhere in this document. If the packet contains a shim message type that is unknown to the receiver, then a Shim6 Error message with Error Code=0 is generated and sent back. The Pointer field is set to point at the first octet of the shim message type.
メッセージは、シムのメッセージタイプに基づいて派遣されます。本文書の他の箇所で説明したように各メッセージタイプは、次に処理されます。パケットが受信機に知られていないシムメッセージタイプが含まれている場合は、エラーコード= 0とSHIM6エラーメッセージが生成され、返送されました。ポインタフィールドは、シムメッセージタイプの最初のオクテットを指すように設定されています。
All the control messages can contain any options with C=0. If there is any option in the message with C=1 that isn't known to the host, then the host MUST send a Shim6 Error message with Error Code=1 with the Pointer field referencing the first octet of the Option Type.
すべての制御メッセージは、C = 0と任意のオプションを含めることができます。ホストに知られていないC = 1のメッセージのいずれかのオプションがある場合、ホストはオプションタイプの最初のオクテットを参照するポインタフィールドとエラーコード= 1でSHIM6エラーメッセージを送らなければなりません。
We assume that each shim context has its own STATE machine. We assume that a dispatcher delivers incoming packets to the STATE machine that it belongs to. Here, we describe the rules used for the dispatcher to deliver packets to the correct shim context STATE machine.
私たちは、それぞれのシム・コンテキストは、独自のステートマシンを持っていることを前提としています。私たちは、ディスパッチャは、それが属するステートマシンへの着信パケットを提供することを想定しています。ここでは、我々は正しいシムコンテキスト状態マシンにパケットを配信するために、ディスパッチャのために使用される規則について説明します。
There is one STATE machine per identified context that is conceptually identified by the ULID pair and Forked Instance Identifier (which is zero by default) or identified by CT(local). However, the detailed lookup rules are more complex, especially during context establishment.
概念的ULID対と（デフォルトではゼロである）フォークトインスタンス識別子によって識別またはCT（ローカル）によって識別される識別されたコンテキストごとに状態マシンがあります。しかし、詳細な検索規則は、特にコンテキストが確立しているときに、より複雑です。
Clearly, if the required context is not established, it will be in IDLE STATE.
必要なコンテキストが確立されていない場合は、明らかに、それはアイドル状態になります。
During context establishment, the context is identified as follows:
次のようにコンテキストが確立しているときに、コンテキストが識別されます。
o I1 packets: Deliver to the context associated with the ULID pair and the Forked Instance Identifier.
入出力I1パケット：ULID対およびフォークトインスタンス識別子に関連付けられたコンテキストに配信します。
o I2 packets: Deliver to the context associated with the ULID pair and the Forked Instance Identifier.
入出力I2パケット：ULID対およびフォークトインスタンス識別子に関連付けられたコンテキストに配信します。
o R1 packets: Deliver to the context with the locator pair included in the packet and the Initiator Nonce included in the packet (R1 does not contain a ULID pair or the CT(local)). If no context exists with this locator pair and Initiator Nonce, then silently discard.
O R1パケット：パケットに含まれるロケータペアとイニシエータノンスとコンテキストへの配信は、（R1はULIDペア又はCT（ローカル）を含まない）のパケットに含まれます。何のコンテキストがこのロケータペアとイニシエータナンスで存在しない場合は、静かに捨てます。
o R2 packets: Deliver to the context with the locator pair included in the packet and the Initiator Nonce included in the packet (R2 does not contain a ULID pair or the CT(local)). If no context exists with this locator pair and Initiator Nonce, then silently discard.
O R2パケット：パケットに含まれるロケータペアとイニシエータノンスとコンテキストへの配信は、（R2がULIDペア又はCT（ローカル）を含まない）のパケットに含まれます。何のコンテキストがこのロケータペアとイニシエータナンスで存在しない場合は、静かに捨てます。
o R1bis packets: Deliver to the context that has the locator pair and the CT(peer) equal to the Packet Context Tag included in the R1bis packet.
R1bisパケットO：ロケータペアとR1bisパケットに含まれるパケットコンテキストタグに等しいCT（ピア）を有しているコンテキストに配信します。
o I2bis packets: Deliver to the context associated with the ULID pair and the Forked Instance Identifier.
I2bisパケットO：ULID対およびフォークトインスタンス識別子に関連付けられたコンテキストに配信します。
o Shim6 Payload Extension headers: Deliver to the context with CT(local) equal to the Receiver Context Tag included in the packet.
O SHIM6ペイロード拡張ヘッダ：パケットに含まれる受信コンテキストタグに等しい（ローカル）CTとのコンテキストに配信します。
o Other control messages (Update, Keepalive, Probe): Deliver to the context with CT(local) equal to the Receiver Context Tag included in the packet. Verify that the IPv6 Source Address field is part of Ls(peer) and that the IPv6 Destination Address field is part of Ls(local). If not, send an R1bis message.
O他の制御メッセージ（更新、キープアライブプローブ）：パケットに含まれる受信コンテキストタグに等しい（ローカル）CTとのコンテキストに配信します。 IPv6のソースアドレスフィールドはLsの（ピア）の一部とIPv6宛先アドレスフィールドはLsの（ローカル）の一部であるということであることを確認します。ない場合は、R1bisメッセージを送信します。
o Shim6 Error messages and ICMP errors that contain a Shim6 Payload Extension header or other shim control packet in the "packet in error": Use the "packet in error" for dispatching as follows. Deliver to the context with CT(peer) equal to the Receiver Context Tag -- Lp(local) being the IPv6 source address and Lp(peer) being the IPv6 destination address.
o「のエラーでパケット」でSHIM6ペイロード拡張ヘッダまたは他のシム制御パケットが含まれているSHIM6エラーメッセージとICMPエラーは次のように派遣するための「誤ったパケット」を使用します。 Lpの（ローカル）IPv6ソースアドレスとLP（ピア）であるIPv6宛先アドレスである - レシーバコンテキストタグに等しいCT（ピア）でコンテキストに届けます。
In addition, the shim on the sending side needs to be able to find the context state when a ULP packet is passed down from the ULP. In that case, the lookup key is the pair of ULIDs and FII=0. If we have a ULP API that allows the ULP to do context forking, then presumably the ULP would pass down the Forked Instance Identifier.
また、送信側のシムは、ULPパケットがULPから受け継がれるコンテキスト状態を見つけることができるようにする必要があります。この場合、検索キーはULIDsとFII = 0のペアです。我々はULPはフォークコンテキストを行うことができますULPのAPIを持っている場合は、おそらくULPはフォークトインスタンス識別子を下に渡します。
The initial contact is some non-shim communication between two ULIDs, as described in Section 2. At that point in time, there is no activity in the shim.
最初の接触は、その時点でセクション2で説明したように、シムにアクティビティがない、2 ULIDsの間にいくつかの非シム通信です。
Whether or not the shim ends up being used (e.g., the peer might not support Shim6), it is highly desirable that the initial contact can be established even if there is a failure for one or more IP addresses.
シムは、（例えば、ピアはSHIM6をサポートしていない可能性があります）を使用してしまうかどうかは、1つ以上のIPアドレスの障害があっても最初の接触を確立することができることが非常に望ましいです。
The approach taken is to rely on the applications and the transport protocols to retry with different source and destination addresses, consistent with what is already specified in "Default Address Selection for IPv6" [7] as well as with some fixes to that specification [9], to make it try different source addresses and not only different destination addresses.
撮影したアプローチは、[7]はすでに「IPv6のデフォルトのアドレス選択」で指定されているものと一致し、異なる送信元アドレスと宛先アドレスを再試行するアプリケーションやトランスポートプロトコルに依存しているだけでなく、その仕様にはいくつかの修正と[9 ]、それは異なる送信元アドレスだけでなく、異なる宛先アドレスを試すようにします。
The implementation of such an approach can potentially result in long timeouts. For instance, consider a naive implementation at the socket API that uses getaddrinfo() to retrieve all destination addresses and then tries to bind() and connect() to try all source and destination address combinations and waits for TCP to time out for each combination before trying the next one.
そのようなアプローチの実装は、潜在的に長いタイムアウトをもたらすことができます。例えば、組み合わせごとにタイムアウトするために、すべての宛先アドレスを取得するためのgetaddrinfo（）を使用して、（バインド）と、すべての送信元と送信先アドレスの組み合わせを試してみる）（接続しようとすると、TCPを待ちソケットAPIでナイーブな実装を検討次のいずれかをしようとする前に。
However, if implementations encapsulate this in some new connect-by-name() API and use non-blocking connect calls, it is possible to cycle through the available combinations in a more rapid manner until a working source and destination pair is found. Thus, the issues in this domain are issues of implementations and the current socket API, and not issues of protocol specification. In all honesty, while providing an easy to use connect-by-name() API for TCP and other connection-oriented transports is easy, providing a similar capability at the API for UDP is hard due to the protocol itself not providing any "success" feedback. Yet, even the UDP issue is one of APIs and implementation.
実装は、これはいくつかの新しい接続ごとの名前（）APIにカプセル化して、通話を接続する非ブロックを使用する場合の作業送信元と宛先のペアが見つかるまでしかし、それはより迅速な方法で利用可能な組み合わせを循環することが可能です。したがって、この領域での問題は、実装の問題や現在のソケットAPI、およびプロトコル仕様のない問題があります。正直なところでは、TCPおよびその他のコネクション型トランスポート用の接続ごとの名前（）APIを使用して簡単に提供しながらすることはUDPはどんな「成功を提供していないため、プロトコル自体にハードさのためにAPIで同様の機能を提供する、簡単です「フィードバック。しかし、でもUDPの問題は、APIと実装の一つです。
The protocol uses the following constants:
プロトコルは、以下の定数を使用しています：
I1_RETRIES_MAX = 4
I1_RETRIES_MAX = 4
I1_TIMEOUT = 4 seconds
I1_TIMEOUT = 4秒
NO_R1_HOLDDOWN_TIME = 1 min
NO_R1_HOLDDOWN_TIME = 1分
ICMP_HOLDDOWN_TIME = 10 min
ICMP_HOLDDOWN_TIME = 10分
I2_TIMEOUT = 4 seconds
I2_TIMEOUT = 4秒
I2_RETRIES_MAX = 2
I2_RETRIES_MAX = 2
I2bis_TIMEOUT = 4 seconds
I2bis_TIMEOUT = 4秒
I2bis_RETRIES_MAX = 2
I2bis_RETRIES_MAX = 2
VALIDATOR_MIN_LIFETIME = 30 seconds
VALIDATOR_MIN_LIFETIME = 30秒
UPDATE_TIMEOUT = 4 seconds
UPDATE_TIMEOUT = 4秒
MAX_UPDATE_TIMEOUT = 120 seconds
MAX_UPDATE_TIMEOUT = 120秒
The retransmit timers (I1_TIMEOUT, I2_TIMEOUT, UPDATE_TIMEOUT) are subject to binary exponential backoff as well as to randomization across a range of 0.5 and 1.5 times the nominal (backed off) value. This removes any risk of synchronization between lots of hosts performing independent shim operations at the same time.
再送タイマー（I1_TIMEOUT、I2_TIMEOUT、UPDATE_TIMEOUT）は2進指数バックオフの対象ならびに0.5および1.5倍の名目（バックオフ）値の範囲にわたってランダムになっています。これは同時に、独立したシム操作を実行するホストのロット間の同期のいずれかの危険性を除去します。
The randomization is applied after the binary exponential backoff. Thus, the first retransmission would happen based on a uniformly distributed random number in the range of [0.5*4, 1.5*4] seconds; the second retransmission, [0.5*8, 1.5*8] seconds after the first one, etc.
ランダム化は、バイナリ指数バックオフの後に適用されます。したがって、最初の再送は[* 4 0.5、1.5 * 4]秒の範囲で均一に分布した乱数に基づいて起こります。第二の再送、[0.5 * 8、1.5 * 8]最初の秒後、等
When the locator pair currently used for exchanging packets in a Shim6 context becomes unreachable, the Shim6 layer will divert the communication through an alternative locator pair, which in most cases will result in redirecting the packet flow through an alternative network path. In this case, it is recommended that the Shim6 follows the recommendation defined in [21] and informs the upper layers about the path change, in order to allow the congestion control mechanisms of the upper layers to react accordingly.
現在SHIM6コンテキストでパケットを交換するために使用されるロケータペアが到達不能になった場合、SHIM6層は、ほとんどの場合、代替ネットワークパスを介してパケットフローをリダイレクトをもたらすであろう、別の位置決め対を介して通信を迂回します。この場合、SHIM6が[21]で定義された勧告に従うと上部層の輻輳制御メカニズムが応じて反応することを可能にするために、経路変更について上位レイヤに通知することをお勧めします。
Data packets belonging to a Shim6 context carrying the Shim6 Payload header contain alternative locators other than the ULIDs in the Source and Destination Address fields of the IPv6 header. On the other hand, the upper layers of the peers involved in the communication operate on the ULID pair presented to them by the Shim6 layer, rather than on the locator pair contained in the IPv6 header of the actual packets. It should be noted that the Shim6 layer does not modify the data packets but, because a constant ULID pair is presented to upper layers irrespective of the locator pair changes, the relation between the upper-layer header (such as TCP, UDP, ICMP, ESP, etc) and the IPv6 header is modified. In particular, when the Shim6 Extension header is present in the packet, if those data packets are TCP, UDP, or ICMP packets, the pseudo-header used for the checksum calculation will contain the ULID pair, rather than the locator pair contained in the data packet.
SHIM6ペイロードヘッダを運ぶSHIM6コンテキストに属するデータパケットは、IPv6ヘッダの送信元アドレスと宛先アドレスフィールドに、ULIDs以外の代替ロケータが含まれています。一方、通信に関与するピアの上層はSHIM6層によってそれらに提示ULID対ではなく、実際のパケットのIPv6ヘッダーに含まれるロケータペアで動作します。それは一定のULIDペアにかかわらずロケータ対変化の上位層に提示されるのでSHIM6層は、データパケットを変更しなくていないことに留意すべきである、そのようなTCP、UDP、ICMPなどの上位層ヘッダとの間の関係（ ESPなど）とIPv6ヘッダが修正されます。 SHIM6拡張ヘッダがパケットに存在する場合、それらのデータパケットがTCP、UDP、またはICMPパケットである場合、特に、チェックサムの計算に使用される疑似ヘッダはむしろに含まロケータペアよりも、ULID対を含むであろうデータパケット。
It is possible that some firewalls or other middle-boxes will try to verify the validity of upper-layer sanity checks of the packet on the fly. If they do that based on the actual source and destination addresses contained in the IPv6 header without considering the Shim6 context information (in particular, without replacing the locator pair by the ULID pair used by the Shim6 context), such verifications may fail. Those middle-boxes need to be updated in order to be able to parse the Shim6 Payload header and find the next header. It is recommended that firewalls and other middle-boxes do not drop packets that carry the Shim6 Payload header with apparently incorrect upper-layer validity checks that involve the addresses in the IPv6 header for their computation, unless they are able to determine the ULID pair of the Shim6 context associated to the data packet and use the ULID pair for the verification of the validity check.
一部のファイアウォールやその他のミドルボックスは、オンザフライでのパケットの上位レイヤの健全性チェックの有効性を確認しようとすることも可能です。彼らは実際のソースおよび宛先アドレスに基づいて（SHIM6の文脈で使用されるULID対によってロケータペアを交換することなく、具体的に）SHIM6コンテキスト情報を考慮せずにIPv6ヘッダーに含まれることがなければ、そのような検証は失敗する可能性があります。これらの中間ボックスはSHIM6ペイロードヘッダを解析し、次のヘッダを見つけることができるようにするために更新する必要があります。ファイアウォールやその他のミドルボックスは、彼らがのULIDペアを決定することができる場合を除き、その計算のためのIPv6ヘッダーのアドレスを含んで明らかに間違った上位レイヤの妥当性をチェックしてSHIM6ペイロードヘッダを運ぶパケットを破棄しないことをお勧めしますSHIM6コンテキストは、データパケットに関連すると妥当性チェックの検証のためのULIDのペアを使用します。
In the particular case of TCP, UDP, and ICMP checksums, it is recommended that firewalls and other middle-boxes do not drop TCP, UDP, and ICMP packets that carry the Shim6 Payload header with apparently incorrect checksums when using the addresses in the IPv6 header for the pseudo-header computation, unless they are able to determine the ULID pair of the Shim6 context associated to the data packet and use the ULID pair to determine the checksum that must be present in a packet with addresses rewritten by Shim6.
TCP、UDP、およびICMPチェックサムの特定のケースでは、ファイアウォールやその他のミドルボックスは、IPv6のアドレスを使用するときに明らかに間違ったチェックサムとSHIM6ペイロードヘッダを運ぶTCP、UDP、およびICMPパケットを廃棄しないことをお勧めします彼らは、データパケットに関連SHIM6コンテキストのULIDペアを決定しSHIM6によって書き換えアドレスを持つパケットに存在しなければならないチェックサムを決定するために、ULIDペアを使用することができない限り、疑似ヘッダの計算にヘッダ。
In addition, firewalls that today pass limited traffic, e.g., outbound TCP connections, would presumably block the Shim6 protocol. This means that even when Shim6-capable hosts are communicating, the I1 messages would be dropped; hence, the hosts would not discover that their peer is Shim6-capable. This is, in fact, a benefit since, if the hosts managed to establish a ULID-pair context, the firewall would probably drop the "different" packets that are sent after a failure (those using the Shim6 Payload Extension header with a TCP packet inside it). Thus, stateful firewalls that are modified to pass Shim6 messages should also be modified to pass the Shim6 Payload Extension header so that the shim can use the alternate locators to recover from failures. This presumably implies that the firewall needs to track the set of locators in use by looking at the Shim6 control exchanges. Such firewalls might even want to verify the locators using the HBA/CGA verification themselves, which they can do without modifying any of the Shim6 packets through which they pass.
また、今日それをファイアウォールは、おそらくSHIM6プロトコルをブロックする、例えば、アウトバウンドTCPコネクション、限定されたトラフィックを渡します。これはSHIM6対応ホストが通信している場合であっても、I1メッセージが廃棄されることを意味します。したがって、ホストは、そのピアがSHIM6-可能であることを発見しないであろう。これは、実際には、利点があるため、ホストがULIDペアコンテキストを確立するために管理している場合、ファイアウォールはおそらくTCPパケットで障害が発生した後に送られ、「異なる」パケット（SHIM6ペイロード拡張ヘッダを使用して、それらをドロップしますその中）。したがって、SHIM6メッセージを渡すように変更され、ステートフルファイアウォールはまた、シムは、障害から回復するために代替のロケータを使用できるようにSHIM6ペイロード拡張ヘッダを通過するように変更されなければなりません。これはおそらくファイアウォールがSHIM6制御やりとりを見て、使用中のロケータのセットを追跡する必要があることを意味します。このようなファイアウォールも、彼らは、彼らが通過するSHIM6パケットのいずれかを変更することなく行うことができますHBA / CGA検証そのものを、使用してロケータを確認したい場合があります。
This section considers some aspects related to the operations and management of the Shim6 protocol.
このセクションでは、SHIM6プロトコルの運用と管理に関連するいくつかの側面を検討します。
Deployment of the Shim6 protocol: The Shim6 protocol is a host-based solution. So, in order to be deployed, the stacks of the hosts using the Shim6 protocol need to be updated to support it. This enables an incremental deployment of the protocol since it does not require a flag day for the deployment -- just single host updates. If the Shim6 solution will be deployed in a site, the host can be gradually updated to support the solution. Moreover, for supporting the Shim6 protocol, only end hosts need to be updated and no router changes are required. However, it should be noted that, in order to benefit from the Shim6 protocol, both ends of a communication should support the protocol, meaning that both hosts must be updated to be able to use the Shim6 protocol. Nevertheless, the Shim6 protocol uses a deferred context-setup capability that allows end hosts to establish normal IPv6 communications and, later on, if both endpoints are Shim6- capable, establish the Shim6 context using the Shim6 protocol. This has an important deployment benefit, since Shim6-enabled nodes can talk perfectly to non-Shim6-capable nodes without introducing any problem into the communication.
SHIM6プロトコルの配備：SHIM6プロトコルは、ホストベースのソリューションです。だから、デプロイするためには、SHIM6プロトコルを使用するホストのスタックは、それをサポートするように更新する必要があります。ちょうど単一のホストの更新を - それは展開のためのフラグの日を必要としないので、これはプロトコルの増分の展開を可能にします。 SHIM6ソリューションは、サイト内に展開される場合は、ホストが徐々にソリューションをサポートするように更新することができます。また、SHIM6プロトコルをサポートするために、唯一のエンドホストを更新するとNOルータの変更が必要とされない必要があります。しかし、SHIM6プロトコルから利益を得るために、通信の両端が共にホストがSHIM6プロトコルを使用することができるように更新されなければならないことを意味し、プロトコルをサポートしなければならないことに留意すべきです。それにもかかわらず、SHIM6プロトコルはエンドホストは、通常のIPv6通信を確立し、後に、両方のエンドポイントができるShim6-ある場合、SHIM6プロトコルを使用SHIM6コンテキストを確立することを可能にする遅延コンテキストセットアップ機能を使用します。 SHIM6対応のノードが通信に支障を導入することなく非SHIM6可能なノードに完璧に話すことができるので、これは、重要な展開の利点を持っています。
Configuration of Shim6-capable nodes: The Shim6 protocol itself does not require any specific configuration to provide its basic features. The Shim6 protocol is designed to provide a default service to upper layers that should satisfy general applications. The Shim6 layer would automatically attempt to protect long-lived communications by triggering the establishment of the Shim6 context using some predefined heuristics. Of course, if some special tunning is required by some applications, this may require additional configuration. Similar considerations apply to a site attempting to perform some forms of traffic engineering by using different preferences for different locators.
SHIM6可能なノードの構成：SHIM6プロトコル自体は、その基本的な機能を提供するために、任意の具体的な設定は必要ありません。 SHIM6プロトコルは、一般的なアプリケーションを満足させなければならない上位層にデフォルト・サービスを提供するように設計されています。 SHIM6層は自動的にいくつかの事前定義されたヒューリスティックを使用してSHIM6コンテキストの確立をトリガすることにより、長寿命の通信を保護しようとしていました。いくつかの特別な細くは、いくつかのアプリケーションで必要とされる場合はもちろん、これは追加の設定が必要な場合があります。同様の考察は異なるロケータに異なる嗜好を使用してトラフィックエンジニアリングのいくつかの形態を実行しようとするサイトに適用されます。
Address and prefix configuration: The Shim6 protocol assumes that, in a multihomed site, multiple prefixes will be available. Such configuration can increase the operation work in a network. However, it should be noted that the capability of having multiple prefixes in a site and multiple addresses assigned to an interface is an IPv6 capability that goes beyond the Shim6 case, and it is expected to be widely used. So, even though this is the case for Shim6, we consider that the implications of such a configuration is beyond the particular case of Shim6 and must be addressed for the generic IPv6 case. Nevertheless, Shim6 also assumes the usage of CGA/HBA addresses by Shim6 hosts. This implies that Shim6-capable hosts should configure addresses using HBA/CGA generation mechanisms. Additional consideration about this issue can be found at [19].
アドレスとプレフィックス設定：SHIM6プロトコルマルチホームのサイトでは、複数のプレフィックスが使用可能になる、ということを前提としています。このような構成は、ネットワークの運用作業を増やすことができます。しかし、サイト内の複数のプレフィックスとインタフェースに割り当てられた複数のアドレスを持つの能力はSHIM6ケースを超えてのIPv6機能であることに留意すべきで、それが広く使用されることが期待されます。だから、これはSHIM6のためのケースであっても、我々はこのような構成の意味合いがSHIM6の特定の場合を超えていると、一般的なIPv6のケースのために取り組まなければならないと考えています。それにもかかわらず、SHIM6もSHIM6ホストによってCGA / HBAアドレスの使用を前提としています。これはSHIM6可能なホストはHBA / CGA生成機構を使用してアドレスを設定する必要があることを意味します。この問題に関する追加の考慮事項は、[19]で見つけることができます。
The general Shim6 approach as well as the specifics of this proposed solution have implications elsewhere, including:
一般SHIM6アプローチならびにこの提案された解決策の詳細は、他の場所を含む意味を有します。
o Applications that perform referrals or callbacks using IP addresses as the 'identifiers' can still function in limited ways, as described in [18]. But, in order for such applications to be able to take advantage of the multiple locators for redundancy, the applications need to be modified to either use Fully Qualified Domain Names as the 'identifiers' or they need to pass all the locators as the 'identifiers', i.e., the 'identifier' from the application's perspective becomes a set of IP addresses instead of a single IP address.
「識別子」は、まだ限られた方法で機能することができるように[18]に記載されているように、IPアドレスを使用して照会またはコールバックを実行Oアプリケーション。しかし、そのようなアプリケーションは、冗長性のために複数のロケータを利用することができるようにするために、アプリケーションは、「識別子」として完全修飾ドメイン名を使用するか変更する必要があるか、彼らは「識別子として、すべてのロケータを渡す必要があります」、すなわち、 『アプリケーションの視点からの識別子は、』 IPのセットではなく、単一のIPアドレスのアドレスになります。
o Signaling protocols for QoS or for other things that involve having devices in the network path look at IP addresses and port numbers (or at IP addresses and Flow Labels) need to be invoked on the hosts when the locator pair changes due to a failure. At that point in time, those protocols need to inform the devices that a new pair of IP addresses will be used for the flow. Note that this is the case even though this protocol, unlike some earlier proposals, does not overload the Flow Label as a Context Tag; the in-path devices need to know about the use of the new locators even though the Flow Label stays the same.
QoSのか、IPアドレスとポート番号でネットワークパスルックで持つデバイスを必要とする他のもののためのシグナリングプロトコルをO（またはIPアドレスとフローラベルで）ホスト上で起動する必要がある場合に故障によるロケータ対の変化。その時点で、これらのプロトコルは、IPアドレスの新しいペアが流れのために使用されるデバイスに通知する必要があります。これは、このプロトコルは、いくつかの以前の提案とは異なり、コンテキストタグとしてフローラベルをオーバーロードしていなくてもそうであることに注意してください。パス内のデバイスは、フローラベルが同じままにもかかわらず、新しいロケータの使用について知っておく必要があります。
o MTU implications. By computing a minimum over the recently observed path MTUs, the path MTU mechanisms we use are robust against different packets taking different paths through the Internet. When Shim6 fails over from using one locator pair to another, this means that packets might travel over a different path through the Internet; hence, the path MTU might be quite different. In order to deal with this change in the MTU, the usage of Packetization Layer Path MTU Discovery as defined in [24] is recommended.
MTUの影響O。最近観測され、パスMTUを超える最小を計算することによって、私たちが使用するパスMTUのメカニズムは、インターネットを介して異なるパスを取って異なるパケットに対して頑健です。 SHIM6を別のロケータペアを使用してからフェイルオーバーするときに、これは、パケットがインターネット経由で別のパス上を移動可能性があることを意味します。したがって、パスMTUはかなり異なる場合があります。 MTUの変化に対応するために、[24]で定義されているパケット化レイヤのパスMTUディスカバリの使用が推奨されます。
The fact that the shim will add an 8-octet Shim6 Payload Extension header to the ULP packets after a locator switch can also affect the usable path MTU for the ULPs. In this case, the MTU change is local to the sending host; thus, conveying the change to the ULPs is an implementation matter. By conveying the information to the transport layer, it can adapt and reduce the Maximum Segment Size (MSS) accordingly.
シムは、ロケータスイッチの後ULPパケットに8オクテットSHIM6ペイロード拡張ヘッダを追加するという事実ものULPに使用可能なパスMTUに影響を与えることができます。この場合、MTUの変更は、送信側ホストにローカルです。このように、のULPへの変更を伝達することは、実装の問題です。トランスポート層に情報を伝達することによって、それに応じて最大セグメントサイズ（MSS）を適応し、減少させることができます。
This document satisfies the concerns specified in [15] as follows:
この文書では、次のように[15]で指定された懸念を満たします：
o The HBA [3] and CGA [2] techniques for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else, prevent threats described in Sections 4.1.1, 4.1.2, 4.1.3, and 4.2 of [15]. These two techniques provide a similar level of protection but also provide different functionality with different computational costs.
HBA O [3]及びCGA [2]のセクション4.1.1、4.1.2で説明した脅威を防ぐため、どこか別の場所にパケットストリームをリダイレクトからの攻撃を防ぐためにロケータを検証するための技法、4.1.3及び4.2の[ 15]。これら2つの技術が保護の同様のレベルを提供するだけでなく、さまざまな計算コストで異なる機能を提供します。
The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, addresses incorporate a cryptographic one-way hash of the prefix set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using the shim protocol node can efficiently verify that the alternative addresses proposed for continuing the communication are bound to the initial address through a simple hash calculation.
HBAのメカニズムは、HBAのセットとして知られている本質的にバインドされたIPv6アドレスの変更不可能なセットとしてマルチホームホストのすべてのアドレスを生成する機能に依存しています。このアプローチでは、アドレスは、インタフェース識別子部分の中に使用可能に設定プレフィックスの暗号一方向ハッシュを組み込みます。その結果、すべての利用可能なアドレスの間の結合は、ハイジャックの保護を提供し、アドレス自体の内にコードされていることです。シムプロトコルノードを使用して、任意のピアは、効率的に通信を継続するために提案された代替アドレスが簡単なハッシュ演算により初期アドレスにバインドされていることを確認することができます。
In a CGA-based approach, the address used as the ULID is a CGA that contains a hash of a public key in its interface identifier. The result is a secure binding between the ULID and the associated key pair. This allows each peer to use the corresponding private key to sign the shim messages that convey locator set information. The trust chain in this case is the following: the ULID used for the communication is securely bound to the key pair because it contains the hash of the public key, and the locator set is bound to the public key through the signature.
CGAベースのアプローチでは、ULIDとして使用されるアドレスは、そのインターフェース識別子における公開鍵のハッシュが含まCGAです。結果はULIDと関連する鍵ペア間の安全な結合です。これは、各ロケータ情報を設定伝えるシムメッセージに署名するために対応する秘密鍵を使用するピアことができます。この場合の信頼チェーンは、以下である：ULIDは、通信が確実に鍵ペアにバインドされているため、それは公開鍵のハッシュを含み、ロケータセットは署名を介して公開鍵にバインドされているため使用しました。
Either of these two mechanisms, HBA and CGA, provides time-shifted attack protection (as described in Section 4.1.2 of [15]), since the ULID is securely bound to a locator set that can only be defined by the owner of the ULID. The minimum acceptable key length for RSA keys used in the generation of CGAs MUST be at least 1024 bits. Any implementation should follow prudent cryptographic practice in determining the appropriate key lengths.
これら二つのメカニズム、HBA及びCGAのいずれか、ULIDのみの所有者によって定義することができるロケータセットに確実に結合しているため、（[15]のセクション4.1.2に記載したように）時間シフト攻撃からの保護を提供しますULID。 CGAsの生成に使用されるRSAキーの最小許容されるキーの長さは、少なくとも1024ビットでなければなりません。任意の実装では、適切なキーの長さを決定する際に慎重な暗号練習に従ってください。
o 3rd party flooding attacks, described in Section 4.3 of [15], are prevented by requiring a Shim6 peer to perform a successful Reachability probe + reply exchange before accepting a new locator for use as a packet destination.
O [15]のセクション4.3に記載のサードパーティのフラッディング攻撃は、パケットの宛先として使用するための新たなロケータを受け入れる前に交換が成功した到達可能性プローブを実行するSHIM6ピアを必要+返信することによって防止されます。
o The first message does not create any state on the responder. Essentially, a 3-way exchange is required before the responder creates any state. This means that a state-based DoS attack (trying to use up all memory on the responder) at least requires the attacker to create state, consuming his own resources; it also provides an IPv6 address that the attacker was using.
O最初のメッセージは、レスポンダ上の任意の状態を作成しません。応答者がどのような状態を作成する前に、基本的に、3ウェイの交換が必要です。これは、（レスポンダー上のすべてのメモリを使用しようとしている）状態ベースのDoS攻撃は、少なくとも自分のリソースを消費し、状態を作成するには、攻撃者が必要であることを意味します。それはまた、攻撃者が使用していたIPv6アドレスを提供します。
o The context-establishment messages use nonces to prevent replay attacks, which are described in Section 4.1.4 of [15], and to prevent off-path attackers from interfering with the establishment.
oをコンテキスト確立メッセージは、[15]のセクション4.1.4に記載されているリプレイ攻撃を防ぐためにノンスを使用し、確立を妨害からオフパス攻撃を防止します。
o Every control message of the Shim6 protocol, past the context establishment, carry the Context Tag assigned to the particular context. This implies that an attacker needs to discover that Context Tag before being able to spoof any Shim6 control message as described in Section 4.4 of [15]. Such discovery probably requires an attacker to be along the path in order to sniff the Context Tag value. The result is that, through this technique, the Shim6 protocol is protected against off-path attackers.
O SHIM6プロトコルのすべての制御メッセージは、コンテキスト確立を過ぎて、特定のコンテキストに割り当てられたコンテキストタグを運びます。これにより、攻撃者は、[15]のセクション4.4で説明したように任意SHIM6制御メッセージをスプーフィングすることができる前に、そのコンテキストタグを発見する必要があることを意味します。このような発見は、おそらくコンテキストタグ値を盗聴するために、パスに沿うように、攻撃者が必要です。その結果、この技術によって、SHIM6プロトコルがオフパス攻撃から保護される、ということです。
Shim6 has two modes of processing data packets. If the ULID pair is also the locator pair being used, then the data packet is not modified by Shim6. In this case, the interaction with IPSec is exactly the same as if the Shim6 layer was not present in the host.
SHIM6は、データパケットを処理する2つのモードを有しています。 ULID対はまた、ロケータペアが使用されている場合、データパケットはSHIM6によって変更されません。 SHIM6層がホストに存在していなかったかのように、この場合にはIPSecとの相互作用は全く同じです。
If the ULID pair differs from the current locator pair for that Shim6 context, then Shim6 will take the data packet, replace the ULIDs contained in the IP Source and Destination Address fields with the current locator pair, and add the Shim6 extension with the corresponding Context Tag. In this case, as is mentioned in Section 1.6, Shim6 conceptually works as a tunnel mechanism, where the inner header contains the ULID and the outer header contains the locators. The main difference is that the inner header is "compressed" and a compression tag, namely the Context Tag, is added to decompress the inner header at the receiving end.
ULIDのペアは、そのSHIM6コンテキストの現在のロケータペアと異なる場合は、SHIM6は、現在のロケータペアとIPソースに含まれるULIDsとDestination Addressフィールドを置き換え、データパケットを取り、対応するコンテキストでSHIM6拡張子を追加します鬼ごっこ。 1.6節に記載されているように、この場合には、SHIM6概念的インナーヘッダはULIDを含み、外部ヘッダは、ロケータが含まれているトンネル機構として働きます。主な違いは、内部ヘッダが「圧縮」され、圧縮タグ、すなわちコンテキストタグは、受信側で内部ヘッダを解凍するために添加されることです。
In this case, the interaction between IPSec and Shim6 is then similar to the interaction between IPSec and a tunnel mechanism. When the packet is generated by the upper-layer protocol, it is passed to the IP layer containing the ULIDs in the IP Source and Destination field. IPSec is then applied to this packet. Then the packet is passed to the Shim6 sublayer, which "encapsulates" the received packet and includes a new IP header containing the locator pair in the IP Source and Destination field. This new IP packet is in turn passed to IPSec for processing, just as in the case of a tunnel. This can be viewed as if IPSec is located both above and below the Shim6 sublayer and as if IPSec policies apply both to ULIDs and locators.
この場合には、IPSecとSHIM6との間の相互作用は、その後のIPSecトンネル機構との間の相互作用と同様です。パケットは上位層プロトコルによって生成されると、それはIP送信元と送信先のフィールドにULIDsを含むIP層に渡されます。 IPSecは、このパケットに適用されます。パケットは、受信したパケットを「カプセル化」とIP送信元および宛先フィールド内のロケータの対を含む新しいIPヘッダを含むSHIM6サブレイヤに渡されます。この新しいIPパケットは、ちょうどトンネルの場合のように、処理のためのIPSecに渡された順番にあります。 IPSecポリシーがULIDsとロケーターの両方に適用した場合、IPSecが上方と下方SHIM6サブレイヤとの両方に位置しているかのようにこれは見ることができます。
When IPSec processed the packet after the Shim6 sublayer has processed it (i.e., the packet carrying the locators in the IP Source and Destination Address field), the Shim6 sublayer may have added the Shim6 Extension header. In that case, IPSec needs to skip the Shim6 Extension header to find the selectors for the next layer's protocols (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)).
SHIM6サブレイヤがそれを処理した後のIPSecパケットを処理したとき（すなわち、IP送信元および宛先アドレスフィールドにロケータを運ぶパケット）は、SHIM6サブレイヤはSHIM6拡張ヘッダを追加してもよいです。その場合、IPSecは、次の層のプロトコル（例えば、TCP、UDP、ストリーム制御伝送プロトコル（SCTP））のためのセレクタを見つけるためSHIM6拡張ヘッダをスキップする必要があります。
When a packet is received at the other end, it is processed based on the order of the extension headers. Thus, if an ESP or AH header precedes a Shim6 header, that determines the order. Shim6 introduces the need to do policy checks, analogous to how they are done for tunnels, when Shim6 receives a packet and the ULID pair for that packet is not identical to the locator pair in the packet.
パケットがもう一方の端で受信される場合には、拡張ヘッダの順序に基づいて処理されます。 ESPまたはAHヘッダーがSHIM6ヘッダを前にある場合したがって、それは順序を決定します。 SHIM6はSHIM6がパケットを受信し、そのパケットのULIDのペアは、パケット内のロケータペアと一致しないときには、トンネルのために行われる方法に類似し、ポリシーチェックを行う必要が導入されました。
Some of the residual threats in this proposal are:
この提案中の残留脅威のいくつかは以下のとおりです。
o An attacker that arrives late on the path (after the context has been established) can use the R1bis message to cause one peer to re-create the context and, at that point in time, can observe all of the exchange. But this doesn't seem to open any new doors for the attacker since such an attacker can observe the Context Tags that are being used and, once known, can use those to send bogus messages.
O（コンテキストが確立された後に）パスに遅れて到着した攻撃者は、為替のすべてを観察することができ、その時点で、コンテキストを再作成するために、一方のピアを引き起こすことがR1bisメッセージを使用してすることができます。そのような攻撃者が使用して、一度知られているコンテキストタグを観察することができますので、しかし、これは偽のメッセージを送信するために、これらを使用することができ、攻撃者のための新たな扉を開くようには見えません。
o An attacker present on the path in order to find out the Context Tags can generate an R1bis message after it has moved off the path. For this packet to be effective, it needs to have a source locator that belongs to the context; thus, there cannot be "too much" ingress filtering between the attacker's new location and the communicating peers. But this doesn't seem to be that severe because, once the R1bis causes the context to be re-established, a new pair of Context Tags will be used, which will not be known to the attacker. If this is still a concern, we could require a 2-way handshake, "did you really lose the state?", in response to the error message.
O R1bisメッセージを生成することができますコンテキストタグを見つけるためにパス上に存在し、攻撃者は、それがパスをオフに移動した後。このパケットが有効であるためには、コンテキストに属するソースロケータを持っている必要があります。このように、攻撃者の新しい場所との通信ピア間の「あまり」イングレスフィルタリングがあることはできません。しかし、これは、攻撃者に知られることはありませんこれは、R1bisが再確立されるコンテキストを起こしたら、コンテキストタグの新しいペアが使用され、そのため、深刻ではないようです。これはまだ懸念される場合は、我々は2ウェイハンドシェイクが必要になる場合があり、「あなたは本当に状態を失ったのか？」、エラーメッセージに応答して。
o It might be possible for an attacker to try random 47-bit Context Tags and see if they can cause disruption for communication between two hosts. In particular, in the case of payload packets, the effects of such an attack would be similar to those of an attacker sending packets with a spoofed source address. In the case of control packets, it is not enough to find the correct Context Tag -- additional information is required (e.g., nonces, proper source addresses; see previous bullet for the case of R1bis). If a 47-bit tag, which is the largest that fits in an 8-octet Extension header, isn't sufficient, one could use an even larger tag in the Shim6 control messages and use the low-order 47 bits in the Shim6 Payload Extension header.
Oそれは、ランダムな47ビットのコンテキストタグを試してみて、彼らは2つのホスト間の通信に混乱を引き起こすことができるかどうかを確認するために、攻撃者は可能かもしれません。具体的には、ペイロードパケットの場合には、このような攻撃の効果は、スプーフィングされた送信元アドレスを持つパケットを送信する攻撃者のものと同様です。制御パケットの場合には、正しいコンテキストタグを見つけることは十分ではありません - 追加情報が必要である（例えば、ナンス、適切な送信元アドレス、R1bisの場合の前の項目を参照します）。 8オクテットの拡張ヘッダに収まる最大で47ビットのタグは、十分でない場合、一方がSHIM6制御メッセージにも大きなタグを使用しSHIM6ペイロード内の下位47ビットを使用することができ拡張ヘッダ。
o When the Shim6 Payload Extension header is used, an attacker that can guess the 47-bit random Context Tag can inject packets into the context with any source locator. Thus, if there is ingress filtering between the attacker and its target, this could potentially allow the attacker to bypass the ingress filtering. However, in addition to guessing the 47-bit Context Tag, the attacker also needs to find a context where, after the receiver's replacement of the locators with the ULIDs, the ULP checksum is correct. But even this wouldn't be sufficient with ULPs like TCP, since the TCP port numbers and sequence numbers must match an existing connection. Thus, even though the issues for off-path attackers injecting packets are different than today with ingress filtering, it is still very hard for an off-path attacker to guess. If IPsec is applied, then the issue goes away completely.
SHIM6ペイロード拡張ヘッダを使用する場合、O、47ビットランダムコンテキストタグを推測することができ、攻撃者は、任意のソースロケータとコンテキストにパケットを注入することができます。攻撃者とその標的との間のイングレスフィルタリングがある場合したがって、これは潜在的に、攻撃者がイングレス・フィルタリングを回避する可能性があります。しかし、47ビットのコンテキストタグを推測することに加えて、攻撃者はまた、ULIDsとロケータの受信機の交換後、ULPチェックサムが正しいか、コンテキストを見つける必要があります。 TCPポート番号やシーケンス番号が既存の接続と一致しなければなりませんので、しかし、たとえこれは、TCPのようなのULPと十分ではありません。このように、パケットを注入し、オフパス攻撃者のための課題は、入力フィルタリングと、今日よりも異なっていても、それは非常に難しいオフパス攻撃者が推測するまだです。 IPsecが適用された場合、問題は完全に消えます。
o The validator included in the R1 and R1bis packets is generated as a hash of several input parameters. While most of the inputs are actually determined by the sender, and only the secret value S is unknown to the sender, the resulting protection is deemed to be enough since it would be easier for the attacker to just obtain a new validator by sending an I1 packet than to perform all the computations required to determine the secret S. Nevertheless, it is recommended that the host change the secret S periodically.
O R1及びR1bisパケットに含まれるバリは、いくつかの入力パラメータのハッシュとして生成されます。入力のほとんどは、実際には送信者によって決定され、そして唯一の秘密値Sは、送信者に知られていない攻撃者がちょうどI1を送信することによって、新しいバリデータを取得することが容易になるだろうから、結果の保護が十分であると考えられますがそれでも秘密Sを決定するために必要なすべての計算を実行するよりもパケットが、ホストが定期的に秘密Sを変更することをお勧めします。
IANA allocated a new IP Protocol Number value (140) for the Shim6 Protocol.
IANAはSHIM6プロトコルのための新しいIPプロトコル番号の値（140）に割り当てられました。
IANA recorded a CGA message type for the Shim6 protocol in the CGA Extension Type Tags registry with the value 0x4A30 5662 4858 574B 3655 416F 506A 6D48.
IANAは値0x4A30 5662 4858 574B 3655 416F 506A 6D48とCGA拡張型タグレジストリにSHIM6プロトコルのCGAメッセージタイプを記録しました。
IANA established a Shim6 Parameter Registry with four components: Shim6 Type registrations, Shim6 Options registrations, Shim6 Error Code registrations, and Shim6 Verification Method registrations.
SHIM6タイプの登録、SHIM6オプション登録、SHIM6エラーコードの登録、およびSHIM6検証方法登録：IANAは、四つの成分でSHIM6パラメータレジストリを設立しました。
The initial contents of the Shim6 Type registry are as follows:
次のようにSHIM6タイプレジストリの初期の内容は以下のとおりです。
+------------+-----------------------------------------------------+
| Type Value | Message |
+------------+-----------------------------------------------------+
| 0 | RESERVED |
| 1 | I1 (first establishment message from the initiator) |
| 2 | R1 (first establishment message from the responder) |
| 3 | I2 (2nd establishment message from the initiator) |
| 4 | R2 (2nd establishment message from the responder) |
| 5 | R1bis (Reply to reference to non-existent context) |
| 6 | I2bis (Reply to a R1bis message) |
| 7-59 | Allocated using Standards action |
| 60-63 | For Experimental use |
| 64 | Update Request |
| 65 | Update Acknowledgement |
| 66 | Keepalive |
| 67 | Probe Message |
| 68 | Error Message |
| 69-123 | Allocated using Standards action |
| 124-127 | For Experimental use |
+------------+-----------------------------------------------------+
The initial contents of the Shim6 Options registry are as follows:
次のようにSHIM6オプションレジストリの初期の内容は以下のとおりです。
+-------------+----------------------------------+
| Type | Option Name |
+-------------+----------------------------------+
| 0 | RESERVED |
| 1 | Responder Validator |
| 2 | Locator List |
| 3 | Locator Preferences |
| 4 | CGA Parameter Data Structure |
| 5 | CGA Signature |
| 6 | ULID Pair |
| 7 | Forked Instance Identifier |
| 8-9 | Allocated using Standards action |
| 10 | Keepalive Timeout Option |
| 11-16383 | Allocated using Standards action |
| 16384-32767 | For Experimental use |
+-------------+----------------------------------+
The initial contents of the Shim6 Error Code registry are as follows:
次のようにSHIM6エラーコードレジストリの初期の内容は以下のとおりです。
+------------+--------------------------------------------+
| Code Value | Description |
+------------+--------------------------------------------+
| 0 | Unknown Shim6 message type |
| 1 | Critical Option not recognized |
| 2 | Locator verification method failed |
| 3 | Locator List Generation number out of sync |
| 4 | Error in the number of locators |
| 5-19 | Allocated using Standards action |
| 120-127 | Reserved for debugging purposes |
+------------+--------------------------------------------+
The initial contents of the Shim6 Verification Method registry are as follows:
次のようにSHIM6検証方法レジストリの初期の内容は以下のとおりです。
+---------+----------------------------------+
| Value | Verification Method |
+---------+----------------------------------+
| 0 | RESERVED |
| 1 | CGA |
| 2 | HBA |
| 3-200 | Allocated using Standards action |
| 201-254 | For Experimental use |
| 255 | RESERVED |
+---------+----------------------------------+
Over the years, many people active in the multi6 and shim6 WGs have contributed ideas and suggestions that are reflected in this specification. Special thanks to the careful comments from Sam Hartman, Cullen Jennings, Magnus Nystrom, Stephen Kent, Geoff Huston, Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le, Jari Arkko, Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Sebastien Barre, Matthijs Mekking, Dave Thaler, Bob Braden, Wesley Eddy, Pasi Eronen, and Tom Henderson on earlier versions of this document.
長年にわたり、multi6とSHIM6のWGで活躍、多くの人々は、この仕様書に反映されているアイデアや提案を貢献してきました。サム・ハートマン、カレン・ジェニングス、マグナスNystrom、スティーブン・ケント、ジェフ・ヒューストン、信太杉本、ペッカSavola、デイブ・マイヤー、Deguangル、ヤリArkko、IljitschバンBeijnum、ジム・バウンド、ブライアン・カーペンター、セバスチャン・バールから慎重なコメントに感謝します、このドキュメントの以前のバージョンにMatthijs Mekking、デーブターラー、ボブブレーデン、ウェズリーエディ、パシEronen、そしてトム・ヘンダーソン。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2]オーラ、T.、 "暗号化生成アドレス（CGA）"、RFC 3972、2005年3月。
[3] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[3] Bagnulo、M.、 "ハッシュベースアドレス（HBA）"、RFC 5535、2009年6月。
[4] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[4] Arkko、J.及びI.バンBeijnum、 "障害検出およびIPv6マルチホーミングのためのロケータペア探索プロトコル"、RFC 5534、2009年6月。
[5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[6]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス拒否攻撃を破り"、BCP 38、RFC 2827、2000年5月。
[7] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[7] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[8] Nordmark, E., "Multihoming without IP Identifiers", Work in Progress, July 2004.
[8] Nordmarkと、E.、 "IP識別子なしマルチホーミング"、進歩、2004年7月の作業。
[9] Bagnulo, M., "Updating RFC 3484 for multihoming support", Work in Progress, November 2007.
[9] Bagnulo、M.、 "支援をマルチホーミングについては、RFC 3484の更新"、進歩、2007年11月に作業を。
[10] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[10] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[11] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[11] Abley、J.、ブラック、B.、およびV.ギル、 "IPv6のサイトマルチホーミングアーキテクチャの目標"、RFC 3582、2003年8月。
[12] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[12] Rajahalme、J.、コンタ、A.、大工、B.、およびS.デアリング、 "IPv6のフローラベル仕様"、RFC 3697、2004年3月。
[13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[13]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[14] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[15] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[15] Nordmarkと、E.およびT.李、 "IPv6のマルチホーミングソリューションに関連脅威"、RFC 4218、2005年10月。
[16] Huitema, C., "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, September 2005.
[16]のHuitema、C.、進歩、2005年9月の作業を "IPv6のためのイングレスフィルタリングの互換性は、サイトをマルチホーム"。
[17] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", Work in Progress, July 2005.
[17] Bagnulo、M.およびE. Nordmarkと、 "SHIM - MIPv6の相互作用"、進歩、2005年7月ワーク。
[18] Nordmark, E., "Shim6-Application Referral Issues", Work in Progress, July 2005.
[18] Nordmarkと、E.、 "SHIM6・アプリケーションの紹介の問題"、進歩、2005年7月に作業。
[19] Bagnulo, M. and J. Abley, "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", Work in Progress, July 2007.
[19] Bagnulo、M.及びJ. Abley、 "レベル3マルチホーミングシムプロトコル（SHIM6）のための適用に関する声明"、進歩、2007年7月ワーク。
[20] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[20]モスコウィッツ、R.、Nikander、P.、Jokela、P.、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[21] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., and K. Le, "TCP Response to Lower-Layer Connectivity-Change Indications", Work in Progress, February 2008.
[21] Schuetz、S.、Koutsianas、N.、エッゲルト、L.、エディ、W.、スワミ、Y.、およびK.ル、 "下層接続-変更効能にTCP応答" が進行中で働いて、 2008年2月。
[22] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[22]ウィリアムズ、N.およびM.リチャードソン、 "ベター・ザン・ナッシングセキュリティ：IPsecのの非認証モード"、RFC 5386、2008年11月。
[23] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket Application Program Interface (API) for Multihoming Shim", Work in Progress, November 2008.
[23]こむ、M.、Bagnulo、M.、Slavov、K.、およびS.杉本、 "マルチホーミングシム用ソケットアプリケーション・プログラム・インターフェース（API）"、進歩、2008年11月ワーク。
[24] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[24]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[25] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[25] Bonica、R.、ガン、D.、タッパン、D.、およびC. Pignataro、RFC 4884、2007年4月 "拡張ICMPマルチパートメッセージをサポートするために"。
Appendix A. Possible Protocol Extensions
付録A.可能なプロトコルの拡張機能
During the development of this protocol, several issues have been brought up that are important to address but that do not need to be in the base protocol itself; instead, these can be done as extensions to the protocol. The key ones are:
このプロトコルの開発中に、いくつかの問題がアドレスに重要であること育ってきたが、それは基本プロトコル自体である必要はありません。その代わり、これらはプロトコルの拡張として行うことができます。主要なものは以下のとおりです。
o As stated in the assumptions in Section 3, in order for the Shim6 protocol to be able to recover from a wide range of failures (for instance, when one of the communicating hosts is single-homed) and to cope with a site's ISPs that do ingress filtering based on the source IPv6 address, there is a need for the host to be able to influence the egress selection from its site. Further discussion of this issue is captured in [16].
そのSHIM6プロトコル（通信ホストの1つがシングルホームである場合、例えば）障害の広い範囲から回復できるようにすると、サイトのISPと対処するために、第3の前提条件で述べたように、O送信元IPv6アドレスに基づいて、入力フィルタリングを行うため、ホストはそのサイトからの出口の選択に影響を与えることができるようにするための必要性があります。この問題のさらなる議論は[16]で捕獲されています。
o Is there need for keeping the list of locators private between the two communicating endpoints? We can potentially accomplish that when using CGA (not when using HBA), but only at the cost of doing some public key encryption and decryption operations as part of the context establishment. The suggestion is to leave this for a future extension to the protocol.
oは2つの通信エンドポイント間のプライベートロケータのリストを維持するためにそこに必要ですか？私たちは、潜在的にだけコンテキスト確立の一環として、いくつかの公開鍵暗号化と復号化の操作を行うための費用で、CGAを使用しているときは（HBAを使用しない場合）ことを達成することができます。提案は、プロトコルへの将来の拡張のためにこれを残すことです。
o Defining some form of end-to-end "compression" mechanism that removes the need to include the Shim6 Payload Extension header when the locator pair is not the ULID pair.
OロケータペアがULIDペアでない場合SHIM6ペイロード拡張ヘッダを含める必要がなくなり、エンドツーエンドの「圧縮」機構のいくつかのフォームを定義します。
o Supporting the dynamic setting of locator preferences on a site-wide basis and using the Locator Preference option in the Shim6 protocol to convey these preferences to remote communicating hosts. This could mirror the DNS SRV record's notion of priority and weight.
サイト全体に基づいて、ロケータの好みの動的設定をサポートし、これらの設定を伝えるためSHIM6プロトコルでロケータ優先オプションを使用してoをリモートホストと通信します。これは、優先度と重みのDNS SRVレコードの概念を反映することができます。
o Specifying APIs in order for the ULPs to be aware of the locators that the shim is using and to be able to influence the choice of locators (controlling preferences as well as triggering a locator-pair switch). This includes providing APIs that the ULPs can use to fork a shim context.
ULPは、シムが使用しているロケータを認識するとロケータ（優先制御、並びにロケータ対のスイッチをトリガー）の選択に影響を与えることができるようにするためにAPIを指定O。これは、のULPは、シムコンテキストをフォークに使用できるAPIを提供することを含みます。
o Determining whether it is feasible to relax the suggestions for when context state is removed so that one can end up with an asymmetric distribution of the context state and still get (most of) the shim benefits. For example, the busy server would go through the context setup but would quickly remove the context state after this (in order to save memory); however, the not-so-busy client would retain the context state. The context-recovery mechanism presented in Section 7.5 would then re-create the state should the client send either a shim control message (e.g., Probe message because it sees a problem) or a ULP packet in a Shim6
1が、（ほとんどの）シムの利点をコンテキスト状態の非対称分布で終わるとまだ得ることができるようにコンテキスト状態が削除されたときのための提案を緩和することが可能であるかどうかを決定するO。例えば、ビジー状態のサーバは、コンテキストセットアップを行くだろうが、すぐに（メモリを節約するために）この後、コンテキストの状態を削除します。しかし、それほど忙しくないクライアントは、コンテキストの状態を維持するだろう。 7.5節で提示コンテキスト回復メカニズムはその後の状態を再作成します（それが問題を見ているので、例えば、Probeメッセージ）クライアントは、シム制御メッセージのいずれかを送信する必要がありますかSHIM6でULPパケット
Payload Extension header (because it had earlier failed over to an alternative locator pair but had been silent for a while). This seems to provide the benefits of the shim as long as the client can detect the failure. If the client doesn't send anything and it is the server that tries to send, then it will not be able to recover because the shim on the server has no context state and hence doesn't know any alternate locator pairs.
ペイロード拡張ヘッダ（それが以前別のロケータペアにフェイルオーバーしたが、しばらくの間、沈黙していたため）。これは、限り、クライアントが障害を検出することができますよう、シムの利点を提供するようです。クライアントが何を送信しませんし、それが送信しようとするサーバーである場合、サーバー上のシムは何のコンテキスト状態を持っていないので、任意の代替ロケータペアを知らないために回復することはできません。
o Study what it would take to make the Shim6 control protocol not rely at all on a stable source locator in the packets. This can probably be accomplished by having all the shim control messages include the ULID-pair option.
OそれはSHIM6制御プロトコルは、パケット内の安定したソースロケータに全く依存しない作るために取るものを研究しています。これはおそらく、すべてのシム制御メッセージはULIDペアオプションを含めることによって達成することができます。
o If each host might have lots of locators, then the current requirement to include essentially all of them in the I2 and R2 messages might be constraining. If this is the case, we can look into using the CGA Parameter Data Structure for the comparison, instead of the prefix sets, to be able to detect context confusion. This would place some constraint on a (logical) only using, for example, one CGA public key; it would also require some carefully crafted rules on how two PDSs are compared for "being the same host". But if we don't expect more than a handful of locators per host, then we don't need this added complexity.
各ホストは、ロケータをたくさん持っている可能性がある場合は、O、その後、現在の要件は、I2で、本質的にそれらのすべてを含むようにしてR2メッセージが制約される可能性があります。この場合、我々はコンテキストの混乱を検出できるようにするには、代わりに接頭辞セットで、比較のためにCGAパラメータデータ構造を使用してに見ることができます。これは、例えば、1つのCGA公開鍵を使用して（論理的）に、いくつかの制約を置きます。それは、2つのPDSは、「同じホストであること」について比較する方法についていくつかの巧妙に作成されたルールが必要になります。私たちはホストあたりのロケータの一握り以上のものを期待していない場合でも、我々は、この追加の複雑さを必要としません。
o ULP-specified timers for the reachability detection mechanism (which can be particularly useful when there are forked contexts).
（二股コンテキストがある場合に特に有用であり得る）到達可能性検出機構のためのO ULP指定タイマー。
o Pre-verify some "backup" locator pair, so that the failover time can be shorter.
フェイルオーバー時間を短くすることができるように、O、いくつかの「バックアップ」ロケータペアを事前に確認してください。
o Study how Shim6 and Mobile IPv6 might interact [17].
O SHIM6とモバイルIPv6は、[17]をやり取りする方法を研究しています。
Appendix B. Simplified STATE Machine
付録B.簡体ステートマシン
The STATEs are defined in Section 6.2. The intent is for the stylized description below to be consistent with the textual description in the specification; however, should they conflict, the textual description is normative.
状態はセクション6.2で定義されています。目的は、以下の様式化された説明は、明細書中のテキスト記述と一致するようにするためのものです。しかし、彼らは競合しなければならない、テキスト記述は規範的です。
The following table describes the possible actions in STATE IDLE and their respective triggers:
次の表は、状態IDLEと、それぞれのトリガで実行可能なアクションについて説明します。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay in IDLE |
| | |
| Heuristics trigger | Send I1 and move to I1-SENT |
| a new context | |
| establishment | |
| | |
| Receive I2, verify | If successful, send R2 and move to |
| validator and | ESTABLISHED |
| RESP Nonce | |
| | If fail, stay in IDLE |
| | |
| Receive I2bis, | If successful, send R2 and move to |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | If fail, stay in IDLE |
| | |
| R1, R1bis, R2 | N/A (This context lacks the required info |
| | for the dispatcher to deliver them) |
| | |
| Receive Payload | Send R1bis and stay in IDLE |
| Extension header | |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE I1-SENT and their respective triggers:
次の表は、STATE I1-SENTと、それぞれのトリガで実行可能なアクションについて説明します。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R1, verify | If successful, send I2 and move to I2-SENT |
| INIT Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I1 | Send R2 and stay in I1-SENT |
| | |
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I2, verify | If successful, send R2 and move to |
| validator and RESP | ESTABLISHED |
| Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I2bis, | If successful, send R2 and move to |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Timeout, increment | If counter =< I1_RETRIES_MAX, send I1 and |
| timeout counter | stay in I1-SENT |
| | |
| | If counter > I1_RETRIES_MAX, go to E-FAILED |
| | |
| Receive ICMP payload| Move to E-FAILED |
| unknown error | |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Discard and stay in I1-SENT |
| Extension header | |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE I2-SENT and their respective triggers:
次の表は、STATE I2-SENTと、それぞれのトリガで実行可能なアクションについて説明します。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, stay in I2-SENT |
| | |
| Receive I1 | Send R2 and stay in I2-SENT |
| | |
| Receive I2, | Send R2 and stay in I2-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive I2bis, | Send R2 and stay in I2-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive R1 | Discard and stay in I2-SENT |
| | |
| Timeout, increment | If counter =< I2_RETRIES_MAX, send I2 and |
| timeout counter | stay in I2-SENT |
| | |
| | If counter > I2_RETRIES_MAX, send I1 and go |
| | to I1-SENT |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Accept and send I2 (probably R2 was sent |
| Extension header | by peer and lost) |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE I2BIS-SENT and their respective triggers:
次の表は、STATE I2BIS-SENTと、それぞれのトリガで実行可能なアクションについて説明します。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, stay in I2BIS-SENT |
| | |
| Receive I1 | Send R2 and stay in I2BIS-SENT |
| | |
| Receive I2, | Send R2 and stay in I2BIS-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive I2bis, | Send R2 and stay in I2BIS-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive R1 | Discard and stay in I2BIS-SENT |
| | |
| Timeout, increment | If counter =< I2_RETRIES_MAX, send I2bis |
| timeout counter | and stay in I2BIS-SENT |
| | |
| | If counter > I2_RETRIES_MAX, send I1 and |
| | go to I1-SENT |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Accept and send I2bis (probably R2 was |
| Extension header | sent by peer and lost) |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE ESTABLISHED and their respective triggers:
次の表は、ESTABLISHED状態で可能なアクションと、それぞれのトリガーを説明します。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1, compare | If no match, send R1 and stay in ESTABLISHED|
| CT(peer) with | |
| received CT | If match, send R2 and stay in ESTABLISHED |
| | |
| | |
| Receive I2, verify | If successful, send R2 and stay in |
| validator and RESP | ESTABLISHED |
| Nonce | |
| | Otherwise, discard and stay in ESTABLISHED |
| | |
| Receive I2bis, | If successful, send R2 and stay in |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | Otherwise, discard and stay in ESTABLISHED |
| | |
| Receive R2 | Discard and stay in ESTABLISHED |
| | |
| Receive R1 | Discard and stay in ESTABLISHED |
| | |
| Receive R1bis | Send I2bis and move to I2BIS-SENT |
| | |
| | |
| Receive Payload | Process and stay in ESTABLISHED |
| Extension header | |
| or other control | |
| packet | |
| | |
| Implementation- | Discard state and go to IDLE |
| specific heuristic | |
| (e.g., No open ULP | |
| sockets and idle | |
| for some time ) | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE E-FAILED and their respective triggers:
次の表は、E-が障害状態に可能なアクションと、それぞれのトリガーを説明します。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Wait for | Go to IDLE |
| NO_R1_HOLDDOWN_TIME | |
| | |
| Any packet | Process as in IDLE |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE NO-SUPPORT and their respective triggers:
次の表は、STATE NO-SUPPORTと、それぞれのトリガで実行可能なアクションについて説明します。
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Wait for | Go to IDLE |
| ICMP_HOLDDOWN_TIME | |
| | |
| Any packet | Process as in IDLE |
+---------------------+---------------------------------------------+
B.1. Simplified STATE Machine Diagram
B.1。簡素化されたステートマシン図
Timeout/Null +------------+
I1/R1 +------------------| NO SUPPORT |
Payload or Control/R1bis | +------------+
+---------+ | ^
| | | ICMP Error/Null|
| V V |
+-----------------+ Timeout/Null +----------+ |
| |<---------------| E-FAILED | |
+-| IDLE | +----------+ |
I2 or I2bis/R2 | | | ^ |
| +-----------------+ (Tiemout#>MAX)/Null| |
| ^ | | |
| | +------+ | |
I2 or I2bis/R2 | | Heuristic/I1| I1/R2 | |
Payload/Null | | | Control/Null | |
I1/R1 or R2 | +--+ | Payload/Null | |
R1 or R2/Null | |Heuristic/Null | (Tiemout#<MAX)/I1 | |
+----------+ | | | +--------+ | |
| V V | | | V | |
+-------------------+ R2/Null | +----------------+
| | I2 or I2bis/R2 +------->| |
| ESTABLISHED |<----------------------------| I1-SENT |
| | | |
+-------------------+ +----------------+
| ^ ^ | ^ ^
| | |R2/Null +-------------+ | |
| | +----------+ |R1/I2 | |
| | | V | |
| | +------------------+ | |
| | | |-------------+ |
| | | I2-SENT | (Timeout#>Max)/I1 |
| | | | |
| | +------------------+ |
| | | ^ |
| | +--------------+ |
| | I1 or I2bis or I2/R2 |
| | (Timeout#<Max) or Payload/I2 |
| | R1 or R1bis/Null |
| +-------+ (Timeout#>Max)/I1 |
| R2/Null| +------------------------------------------+
| V |
| +-------------------+
| | |<-+ (Timeout#<Max)/I2bis
+-------->| I2bis-SENT | | I1 or I2 or I2bis/R2
R1bis/I2bis | |--+ R1 or R1bis/Null
+-------------------+ Payload/I2bis
Appendix C. Context Tag Reuse
付録C.コンテキストタグの再利用
The Shim6 protocol doesn't have a mechanism for coordinated state removal between the peers because such state removal doesn't seem to help, given that a host can crash and reboot at any time. A result of this is that the protocol needs to be robust against a Context Tag being reused for some other context. This section summarizes the different cases in which a Tag can be reused, and how the recovery works.
このような状態の除去を助けていないようですので、SHIM6プロトコルは、ホストが任意の時点でクラッシュして再起動することができますことを考えると、ピア間の協調状態を除去するためのメカニズムを持っていません。この結果は、プロトコルは、いくつかの他のコンテキストのために再利用されるコンテキストタグに対して堅牢にする必要があるということです。このセクションでは、タグを再利用することができる別の例を要約し、そして回復がどのように働きますか。
The different cases are exemplified by the following case. Assume hosts A and B were communicating using a context with the ULID pair <A1, B2>, and that B had assigned Context Tag X to this context. We assume that B uses only the Context Tag to demultiplex the received Shim6 Payload Extension headers, since this is the more general case. Further, we assume that B removes this context state, while A retains it. B might then at a later time assign CT(local)=X to some other context, at which time, we have several possible cases:
異なる場合は、以下の場合が例示されます。ホストA及びBは、ULID対<A1、B2>とコンテキストを使用して通信、及びBは、このコンテキストへのコンテキストタグXが割り当てられたことを想定しました。これは、より一般的なケースであるため、Bは、受信SHIM6ペイロード拡張ヘッダを分離するためにのみコンテキストタグを使用していることを前提としています。 Aはそれを保持しながら、さらに、我々は、Bは、このコンテキストの状態を削除することを想定しています。 Bは、後の時点で、その時点で、我々はいくつかの可能な例を持っている、いくつかの他のコンテキストにCT（ローカル）= Xを割り当てることができます：
o The Context Tag is reassigned to a context for the same ULID pair <A1, B2>. We've called this "context recovery" in this document.
Oコンテキストタグは<A1、B2>同じULID対のコンテキストに再割り当てされます。私たちは、この文書では、この「文脈の回復」と呼ばれてきました。
o The Context Tag is reassigned to a context for a different ULID pair between the same two hosts, e.g., <A3, B3>. We've called this "context confusion" in this document.
Oコンテキストタグは<A3、B3>、例えば同じ2つのホスト間で異なるULID対のコンテキストに再割り当てされます。私たちは、この文書では、この「文脈の混乱」と呼ばれてきました。
o The Context Tag is reassigned to a context between B and another host C, for instance, for the ULID pair <C3, B2>. That is a form of three-party context confusion.
Oコンテキストタグは<C3、B2> ULIDペアに対して、例えば、Bおよび他のホストCとの間のコンテキストに再割り当てされます。それは三者のコンテキストの混乱の形です。
C.1. Context Recovery
C.1。コンテキスト回復
This case is relatively simple and is discussed in Section 7.5. The observation is that since the ULID pair is the same, when either A or B tries to establish the new context, A can keep the old context while B re-creates the context with the same Context Tag CT(B) = X.
この場合は、比較的単純であり、セクション7.5で議論されています。観察は、AまたはBのどちらかが新たなコンテキストを確立しようとしたときにULIDのペアは、同じであるため、Bの同じコンテキストタグCT（B）とのコンテキストを再作成しながら、AはX. =古いコンテキストを保つことができるということです
C.2. Context Confusion
C.2。コンテキスト混乱
This case is a bit more complex and is discussed in Section 7.6. When the new context is created, whether A or B initiates it, host A can detect when it receives B's locator set (in the I2 or R2 message) in that it ends up with two contexts to the same peer host (overlapping Ls(peer) locator sets) that have the same Context Tag: CT(peer) = X. At this point in time, host A can clear up any possibility of causing confusion by not using the old context to send any more packets. It either just discards the old context (it might not be used by any ULP traffic, since B had discarded it) or it re- creates a different context for the old ULID pair (<A1, B2>), for which B will assign a unique CT(B) as part of the normal context-establishment mechanism.
この場合は、もう少し複雑であり、セクション7.6で議論されています。新しいコンテキストが作成されると、それは同じピア・ホストに二つのコンテキスト（LSオーバーラップ（ピアで終わるという点で、それは（I2またはR2メッセージで）Bのロケータセットを受信した場合、AまたはBは、それを開始するかどうかを、ホストAを検出することができます。 ）ロケータ同じコンテキストタグを持つセット）：この時点でCT（ピア）= X.は、ホストAは、任意のより多くのパケットを送信するために、古いコンテキストを使用していないことで混乱を引き起こす可能性を解消することができます。それはどちらかだけでBが割り当てられますそのため、古いULIDペア（<A1、B2>）のために別のコンテキストを作成し、再古いコンテキスト（Bがそれを捨てていたので、それは、任意のULPトラフィックが使用されない場合があります）、またはそれを捨てます通常コンテキスト確立機構の一部としてユニークなCT（B）。
C.3. Three-Party Context Confusion
C.3。三者のコンテキスト混乱
The third case does not have a place where the old state on A can be verified since the new context is established between B and C. Thus, when B receives Shim6 Payload Extension headers with X as the Context Tag, it will find the context for <C3, B2> and, hence, will rewrite the packets to have C3 in the Source Address field and B2 in the Destination Address field before passing them up to the ULP. This rewriting is correct when the packets are in fact sent by host C, but if host A ever happens to send a packet using the old context, then the ULP on A sends a packet with ULIDs <A1, B2> and the packet arrives at the ULP on B with ULIDs <C3, B2>.
第三の場合は、Bは、コンテキストタグとしてXとSHIM6ペイロード拡張ヘッダを受信した場合、それはのためのコンテキストを見つける、新しいコンテキストがこのようにBとCとの間に確立されるので、A上の古い状態を検証することができる場所を持っていません<C3、B2>と、それゆえ、ULPにそれらを渡す前に、宛先アドレスフィールドに、送信元アドレスフィールドとB2にC3を持っているパケットを書き換えます。パケットが実際にホストCから送信されたときに、この書き換えは正しいのですが、ホストAは、これまでの古いコンテキストを使用してパケットを送信するために発生した場合、その後、AのULPはULIDs <A1、B2>でパケットを送信し、パケットが到着しますULIDs <C3、B2>とBにULP。
This is clearly an error, and the packet will most likely be rejected by the ULP on B due to a bad pseudo-header checksum. Even if the checksum is okay (probability 2^-16), the ULP isn't likely to have a connection for those ULIDs and port numbers. And if the ULP is connection-less, processing the packet is most likely harmless; such a ULP must be able to copy with random packets being sent by random peers in any case.
これは明らかに誤りであり、パケット不良の可能性が高い疑似ヘッダチェックサムによるBにULPによって拒否されます。チェックサムは、（確率は2 ^ -16）大丈夫であったとしても、ULPは、それらのULIDsとポート番号への接続を持っていそうではありません。 ULPは、コネクションレスである場合や、パケットを処理することは、最も可能性の高い無害です。このようULPは、どのような場合には、ランダムなピアによって送信されるランダムなパケットをコピーすることができなければなりません。
This broken state, where packets are sent from A to B using the old context on host A, might persist for some time but will not remain for very long. The unreachability detection on host A will kick in because it does not see any return traffic (payload or Keepalive messages) for the context. This will result in host A sending Probe messages to host B to find a working locator pair. The effect of this is that host B will notice that it does not have a context for the ULID pair <A1, B2> and CT(B) = X, which will make host B send an R1bis packet to re-establish that context. The re-established context, just like in the previous section, will get a unique CT(B) assigned by host B; thus, there will no longer be any confusion.
パケットがホストA上の古いコンテキストを使用してAからBに送られ、この壊れた状態は、しばらくの間、存続するかもしれませんが、非常に長いために残りません。それはコンテキストのすべてのリターントラフィック（ペイロードまたはキープアライブメッセージ）を参照してくださいしないため、ホストA上の到達不能検出がでキックします。これは、作業ロケータペアを見つけるためにBをホストするためにプローブメッセージを送信するホストAになります。この効果は、ホストBは、ホストBは、そのコンテキストを再確立するR1bisパケットを送信するであろうULID対<A1、B2>及びCT（B）= X、のコンテキストを持っていないことに気づくであろうということです。再確立されたコンテキストは、前のセクションのように、ホストBによって割り当てられた固有のCT（B）を取得します。このように、もはや混乱はありません。
C.4. Summary
C.4。概要
In summary, there are cases where a Context Tag might be reused while some peer retains the state, but the protocol can recover from it. The probability of these events is low, given the 47-bit Context Tag size. However, it is important that these recovery mechanisms be tested. Thus, during development and testing, it is recommended that implementations not use the full 47-bit space but instead keep, for example, the top 40 bits as zero, only leaving the host with 128 unique Context Tags. This will help test the recovery mechanisms.
要約すると、いくつかのピアは状態を保持しながら、コンテキストタグが再利用される可能性があるケースがありますが、プロトコルはそれから回復することができます。これらの事象の確率は、47ビットのコンテキストタグのサイズを考えると、低いです。しかし、これらの回復メカニズムをテストすることが重要です。したがって、開発およびテスト中には、実装が完全な47ビットの空間を使用する代わりに、唯一128個の固有のコンテキストタグを持つホストを残して、ゼロとして、例えば、上位40ビットを保持していないことをお勧めします。これは、回復メカニズムをテストするのに役立ちます。
Appendix D. Design Alternatives
付録D.デザイン代替
This document has picked a certain set of design choices in order to try to work out a bunch of the details and to stimulate discussion. But, as has been discussed on the mailing list, there are other choices that make sense. This appendix tries to enumerate some alternatives.
この文書では、細部の束をうまくしようとすると議論を刺激するために設計上の選択の特定のセットを選びました。しかし、メーリングリストで議論されているように、意味をなす他の選択肢があります。この付録では、いくつかの選択肢を列挙しようとします。
D.1. Context Granularity
D.1。コンテキスト粒度
Over the years, various suggestions have been made whether the shim should, even if it operates at the IP layer, be aware of ULP connections and sessions and, as a result, be able to make separate shim contexts for separate ULP connections and sessions. A few different options have been discussed:
長年にわたり、様々な提案がシムは、それがIP層で動作していても、ULPの接続とセッションを認識する必要があるかどうか行われていると、結果として、別のULPの接続とセッション用に別のシムコンテキストを作ることができます。いくつかの異なるオプションが議論されてきました。
o Each ULP connection maps to its own shim context.
O各ULP接続は、独自のシムコンテキストにマッピングします。
o The shim is unaware of the ULP notion of connections and just operates on a host-to-host (IP address) granularity.
シムO接続のULPの概念を知らないで、ちょうどホスト間（IPアドレス）の粒度で動作します。
o Hybrids in which the shim is aware of some ULPs (such as TCP) and handles other ULPs on a host-to-host basis.
Oハイブリッドとは、シム（TCPなど）いくつかのULPを認識し、ホストツーホスト基づいて他のULPを処理します。
Having shim state for every ULP connection potentially means higher overhead since the state-setup overhead might become significant; there is utility in being able to amortize this over multiple connections.
すべてのULP接続が潜在的に状態のセットアップのオーバーヘッドが重要になるかもしれないので、高いオーバーヘッドを意味するためにシム状態を有します。ユーティリティは、複数の接続を介してこれを償却することができることにあります。
But being completely unaware of the ULP connections might hamper ULPs that want different communication to use different locator pairs, for instance, for quality or cost reasons.
しかし、ULP接続を全く知らないということは、品質やコスト的な理由のために、例えば、異なるロケータペアを使用するには、異なる通信をしたいのULPを妨げる可能性があります。
The protocol has a shim that operates with host-level granularity (strictly speaking, with ULID-pair granularity) to be able to amortize the context establishment over multiple ULP connections. This is combined with the ability for Shim6-aware ULPs to request context forking so that different ULP traffic can use different locator pairs.
プロトコルは、複数のULP接続を介してコンテキスト確立を償却することができるようにホストレベルの粒度（厳密ULID対の粒度で、話す）で動作シムを有しています。これは、異なるULPトラフィックが別のロケータのペアを使用できるように、フォークコンテキストを要求するSHIM6認識のULPのための能力と組み合わされます。
D.2. Demultiplexing of Data Packets in Shim6 Communications
D.2。 SHIM6通信におけるデータパケットの多重分離
Once a ULID-pair context is established between two hosts, packets may carry locators that differ from the ULIDs presented to the ULPs using the established context. One of the main functions of the Shim6 layer is to perform the mapping between the locators used to forward packets through the network and the ULIDs presented to the ULP. In order to perform that translation for incoming packets, the
ULID対コンテキストが2つのホスト間で確立されると、パケットは、確立されたコンテキストを使用してのULPに提示ULIDs異なるロケータを運ぶことができます。 SHIM6層の主な機能の一つは、ネットワークを介してパケットを転送するために使用されるロケータとULPに提示ULIDsとの間のマッピングを行うことです。着信パケットのためにその翻訳を行うためには、
Shim6 layer needs to first identify which of the incoming packets need to be translated and then perform the mapping between locators and ULIDs using the associated context. Such operation is called "demultiplexing". It should be noted that, because any address can be used both as a locator and as a ULID, additional information, other than the addresses carried in packets, needs to be taken into account for this operation.
SHIM6層は、第1の変換され、関連するコンテキストを使用してロケータとULIDsの間のマッピングを実行する必要が着信パケットのかを識別する必要があります。このような動作は、「分離」と呼ばれています。この操作の際に考慮する必要があり、パケットで運ばれたアドレス以外の、任意のアドレスがロケータとしてやULID、付加情報としての両方で使用することができるので、ことに留意すべきです。
For example, if a host has addresses A1 and A2 and starts communicating with a peer with addresses B1 and B2, then some communication (connections) might use the pair <A1, B1> as ULID and others might use, for example, <A2, B2>. Initially there are no failures, so these address pairs are used as locators, i.e., in the IP address fields in the packets on the wire. But when there is a failure, the Shim6 layer on A might decide to send packets that used <A1, B1> as ULIDs using <A2, B2> as the locators. In this case, B needs to be able to rewrite the IP address field for some packets and not others, but the packets all have the same locator pair.
ホストがアドレスA1およびA2を有しており、開始した場合、例えば、アドレスB1とB2とのピアと通信し、いくつかの通信（接続）対<A1、B1> ULIDと他の人が使用する可能性があるように、例えば、<A2を使用するかもしれません、B2>。最初にそこには障害ではないので、これらのアドレスのペアは、ワイヤ上のパケット内のIPアドレスフィールドに、すなわちロケータとして使用されます。障害が発生したときには、上のSHIM6層がロケータとして<A2、B2>を使用してULIDsとして<A1、B1>を使用してパケットを送信することを決定するかもしれません。この場合、Bは、いくつかのパケットではなく、他人のためにIPアドレスのフィールドを書き換えることができる必要がありますが、パケットはすべて同じロケータペアを持っています。
In order to accomplish the demultiplexing operation successfully, data packets carry a Context Tag that allows the receiver of the packet to determine the shim context to be used to perform the operation.
正常に分離操作を達成するために、データパケットは、パケットの受信機が動作を実行するために使用されるシムのコンテキストを決定することを可能にするコンテキストタグを運びます。
Two mechanisms for carrying the Context Tag information have been considered in depth during the shim protocol design: those carrying the Context Tag in the Flow Label field of the IPv6 header and those using a new Extension header to carry the Context Tag. In this appendix, we will describe the pros and cons of each mechanism and justify the selected option.
IPv6ヘッダのフローラベルフィールドにコンテキストタグを有するものとコンテキストタグを運ぶために、新たな拡張ヘッダを使用して、それら：コンテキストタグの情報を運ぶための2つのメカニズムがシムプロトコル設計時に徹底的に検討されています。この付録では、我々は、各機構の長所と短所を説明し、選択されたオプションを正当化します。
D.2.1. Flow Label
D.2.1。フローラベル
A possible approach is to carry the Context Tag in the Flow Label field of the IPv6 header. This means that when a Shim6 context is established, a Flow Label value is associated with this context (and perhaps a separate Flow Label for each direction).
可能なアプローチは、IPv6ヘッダのフローラベルフィールドにコンテキストタグを運ぶことです。これはSHIM6コンテキストが確立されると、フローラベル値が（おそらく、各方向のための別個のフローラベル）このコンテキストに関連付けられていることを意味します。
The simplest way to do this is to have the triple <Flow Label, Source Locator, Destination Locator> identify the context at the receiver.
これを実行する最も簡単な方法は、トリプル<フローラベル、ソースロケータ、宛先ロケータを>持っている受信機でコンテキストを識別することです。
The problem with this approach is that, because the locator sets are dynamic, it is not possible at any given moment to be sure that two contexts for which the same Context Tag is allocated will have disjoint locator sets during the lifetime of the contexts.
このアプローチの問題は、ロケータセットは動的であるので、それは同じコンテキストタグが割り当てられているために2つのコンテキストがコンテキストの存続期間中にばらばらロケータセットを持っていることを確認するために任意の時点では不可能である、ということです。
Suppose that Node A has addresses IPA1, IPA2, IPA3, and IPA4 and that Host B has addresses IPB1 and IPB2.
ノードAはアドレスIPA1、IPA2、IPA3、およびIPA4を持ち、そのホストBは、アドレスIPB1とIPB2を持っていると仮定します。
Suppose that two different contexts are established between Host A and Host B.
二つの異なるコンテキストがホストAとホストBとの間に確立されていると仮定
Context #1 is using IPA1 and IPB1 as ULIDs. The locator set associated to IPA1 is IPA1 and IPA2, while the locator set associated to IPB1 is just IPB1.
コンテキスト＃1はULIDsとしてIPA1とIPB1を使用しています。 IPB1に関連するロケータ・セットがちょうどIPB1いる間IPA1に関連するロケータ・セットは、IPA1とIPA2あります。
Context #2 uses IPA3 and IPB2 as ULIDs. The locator set associated to IPA3 is IPA3 and IPA4, while the locator set associated to IPB2 is just IPB2.
コンテキスト＃2がULIDsとしてIPA3とIPB2を使用しています。 IPB2に関連するロケータ・セットがちょうどIPB2いる間IPA3に関連するロケータ・セットは、IPA3とIPA4あります。
Because the locator sets of Context #1 and Context #2 are disjoint, hosts could think that the same Context Tag value can be assigned to both of them. The problem arrives when, later on, IPA3 is added as a valid locator for IPA1 in Context #2 and IPB2 is added as a valid locator for IPB1 in Context #1. In this case, the triple <Flow Label, Source Locator, Destination Locator> would not identify a unique context anymore, and correct demultiplexing is no longer possible.
コンテキスト＃1とコンテキスト＃2のロケータセットがばらばらなので、ホストは同じコンテキストタグの値は、それらの両方に割り当てることができることを考えることができます。問題は、後に、IPA3は、コンテキスト＃2でIPA1のための有効なロケータとして追加され、IPB2は、コンテキスト＃1でIPB1のための有効なロケータとして追加された場合、到着しました。この場合、トリプル<フローラベル、ソースロケータ、宛先ロケータ>はもはや独自のコンテキストを識別しないだろう、と正しい分離はもはや不可能です。
A possible approach to overcome this limitation is to simply not repeat the Flow Label values for any communication established in a host. This basically means that each time a new communication that is using different ULIDs is established, a new Flow Label value is assigned to it. By these means, each communication that is using different ULIDs can be differentiated because each has a different Flow Label value.
この制限を克服するための可能なアプローチは、単にホストに設立された任意の通信のためのフローラベル値を繰り返さないことです。これは基本的に異なるULIDsを使用している新しい通信が確立されるたびに、新しいフローラベル値が割り当てられていることを意味しています。それぞれ異なるフローラベル値を有するので、これらの手段によって、異なるULIDsを使用している各通信を区別することができます。
The problem with such an approach is that it requires the receiver of the communication to allocate the Flow Label value used for incoming packets, in order to assign them uniquely. For this, a shim negotiation of the Flow Label value to use in the communication is needed before exchanging data packets. This poses problems with non-Shim6-capable hosts, since they would not be able to negotiate an acceptable value for the Flow Label. This limitation can be lifted by marking the packets that belong to shim sessions from those that do not. These markings would require at least a bit in the IPv6 header that is not currently available, so more creative options would be required, for instance, using new Next Header values to indicate that the packet belongs to a Shim6-enabled communication and that the Flow Label carries context information as proposed in [8]. However, even if new Next Header values are used in this way, such an approach is incompatible with the deferred-establishment capability of the shim protocol, which is a preferred function since it suppresses delay due to shim context establishment prior to the initiation of communication. Such capability also allows nodes to define at which stage of the communication they decide, based on their own policies, that a given communication requires protection by the shim.
そのようなアプローチに伴う問題は、それが一意に割り当てるために、着信パケットのために使用されるフローラベル値を割り当てる通信の受信機を必要とすることです。このため、通信に使用するためのフローラベル値のシム交渉は、データパケットを交換する前に必要とされています。彼らはフローラベルの許容値を交渉することはできませんので、これは、非SHIM6対応のホストとの問題があります。この制限は、そうでないものからセッションをシムに属するパケットをマークすることで持ち上げることができます。これらのマーキングは、パケットがフローSHIM6有効通信し、その属していることを示すために、新たな次のヘッダー値を使用して、例えば、ので、より多くのクリエイティブなオプションが必要となるであろう、現在利用できないIPv6ヘッダーの少なくともビットを必要とするであろう[8]で提案されたラベルは、コンテキスト情報を搬送します。新しい次のヘッダ値をこのように使用されている場合でも、それは前に通信の開始に伴うシムコンテキストの確立に遅延を抑制するので、そのようなアプローチは、好ましい機能であるシムプロトコルの遅延確立機能と互換性がありません。このような機能は、所定の通信はシムによって保護を必要とすることが、自分のポリシーに基づいて、ノードは彼らが決める通信のどの段階で定義することができます。
In order to cope with the identified limitations, an alternative approach that does not constrain the Flow Label values that are used by communications using ULIDs equal to the locators (i.e., no shim translation) is to only require that different Flow Label values are assigned to different shim contexts. In such an approach, communications start with unmodified Flow Label usage (could be zero or as suggested in [12]). The packets sent after a failure when a different locator pair is used would use a completely different Flow Label, and this Flow Label could be allocated by the receiver as part of the shim context establishment. Since it is allocated during the context establishment, the receiver of the "failed over" packets can pick a Flow Label of its choosing (that is unique in the sense that no other context is using it as a Context Tag), without any performance impact, respecting that, for each locator pair, the Flow Label value used for a given locator pair doesn't change due to the operation of the multihoming shim.
識別された制約に対応するために、ロケータに等しいULIDsを用いた通信によって使用されるフローラベル値（すなわち、シム翻訳）を拘束しない別のアプローチは、異なるフローラベル値が割り当てられていることのみが必要です別のシムコンテキスト。そのようなアプローチでは、通信は、未修飾フローラベルの使用（ゼロ又は[12]に示唆されるようにすることができる）で始まります。異なるロケータペアが使用される場合、障害後に送信されるパケットは全く異なるフローラベルを使用し、このフローラベルシムコンテキスト確立の一部として、受信機によって割り当てられることができます。それはコンテキスト確立中に割り当てられているので、の受信機は、パケットがその選択したフローラベルを選ぶことができ、「フェイルオーバー」は、任意のパフォーマンスに影響することなく、（すなわち、他のコンテキストがコンテキストタグとして使用されていないという意味で独特です） 、各ロケータペアのために、与えられたロケータペアに使用フローラベル値が原因マルチホーミングシムの動作に変更されない、ということ尊重します。
In this approach, the constraint is that Flow Label values being used as context identifiers cannot be used by other communications that use non-disjoint locator sets. This means that once a given Flow Label value has been assigned to a shim context that has a certain locator sets associated, the same value cannot be used for other communications that use an address pair that is contained in the locator sets of the context. This is a constraint in the potential Flow Label allocation strategies.
この手法では、制約は、コンテクスト識別子が非互いに素ロケータセットを使用する他の通信で使用することができないようにフローラベル値が使用されていることです。これは、所与のフローラベルの値は、関連する特定のロケータセットを有するシムコンテキストに割り当てられた後、同一の値がコンテキストのロケータセットに含まれるアドレスのペアを使用する他の通信のために使用することができないことを意味します。これは、潜在的なフローラベル割り当て戦略の制約です。
A possible workaround to this constraint is to mark shim packets that require translation, in order to differentiate them from regular IPv6 packets, using the artificial Next Header values described above. In this case, the Flow Label values constrained are only those of the packets that are being translated by the shim. This last approach would be the preferred approach if the Context Tag is to be carried in the Flow Label field. This is the case not only because it imposes the minimum constraints to the Flow Label allocation strategies, limiting the restrictions only to those packets that need to be translated by the shim, but also because context-loss detection mechanisms greatly benefit from the fact that shim data packets are identified as such, allowing the receiving end to identify if a shim context associated to a received packet is supposed to exist, as will be discussed in the context-loss detection appendix below.
この制約への可能な回避策は、上記の人工次ヘッダ値を使用して、通常のIPv6パケットと区別するためには、翻訳を必要とシムパケットをマークすることです。この場合、制約フローラベル値はシムによって翻訳されたパケットのものです。コンテキストタグは、フローラベルフィールドで運ばれるのであれば、この最後のアプローチが好ましいアプローチになります。それが唯一のシムによって翻訳される必要があり、これらのパケットに制限を制限し、フローラベルの割り当て戦略に最低限の制約を課すので、これはそうではないだけでなく、コンテキスト・ロス検出メカニズムが大幅に事実そのシムの恩恵を受けるためにデータパケットが受信されたパケットに関連するシムコンテキストが存在することになっている場合は、以下のコンテキスト損失検出付録に説明するように受信端は、識別することができ、そのように識別されます。
D.2.2. Extension Header
D.2.2。拡張ヘッダ
Another approach, which is the one selected for this protocol, is to carry the Context Tag in a new Extension header. These Context Tags are allocated by the receiving end during the Shim6 protocol initial negotiation, implying that each context will have two Context Tags, one for each direction. Data packets will be demultiplexed using the Context Tag carried in the Extension header. This seems a clean approach since it does not overload existing fields. However, it introduces additional overhead in the packet due to the additional header. The additional overhead introduced is 8 octets. However, it should be noted that the Context Tag is only required when a locator other than the one used as ULID is contained in the packet. Packets where both the Source and Destination Address fields contain the ULIDs do not require a Context Tag, since no rewriting is necessary at the receiver. This approach would reduce the overhead because the additional header is only required after a failure. On the other hand, this approach would cause changes in the available MTU for some packets, since packets that include the Extension header will have an MTU that is 8 octets shorter. However, path changes through the network can result in a different MTU in any case; thus, having a locator change, which implies a path change, affect the MTU doesn't introduce any new issues.
このプロトコルのために選択された一つである別のアプローチは、新たな拡張ヘッダのコンテキストタグを運ぶことです。これらのコンテキストタグは、各コンテキストは、各方向に対して1つの2個のコンテキストタグを持つであろうことを意味する、SHIM6プロトコル初期ネゴシエーション中に受信側によって割り当てられます。データパケットは、拡張ヘッダで運ばれたコンテキスト・タグを使用して逆多重化します。それは既存のフィールドに過負荷をかけていないので、これはクリーンなアプローチです。しかし、それは、追加ヘッダをパケットに追加のオーバーヘッドを導入します。導入された追加のオーバーヘッドは8つのオクテットです。しかし、ULIDとして使用されるもの以外のロケータがパケットに含まれている場合、コンテキストタグのみが必要とされることに留意すべきです。何の書き換えが受信機に必要ではありませんので、送信元と宛先の両方のアドレスフィールドがULIDsが含まれているパケットは、コンテキストタグを必要としません。追加のヘッダだけ失敗した後必要とされるため、このアプローチは、オーバーヘッドを減少させるであろう。拡張ヘッダが含まれたパケットは、8つのオクテット短いMTUを持つことになりますので、一方で、このアプローチは、いくつかのパケットに利用可能なMTUの変化を引き起こします。しかし、パスがいずれの場合に異なるMTUをもたらすことができるネットワークを介して変更します。このように、パスの変更を意味ロケータの変化を有する、MTUは、任意の新たな問題を導入しない影響を与えます。
D.3. Context-Loss Detection
D.3。コンテキスト・ロス検出
In this appendix, we will present different approaches considered to detect context loss and potential context-recovery strategies. The scenario being considered is the following: Node A and Node B are communicating using IPA1 and IPB1. Sometime later, a shim context is established between them, with IPA1 and IPB1 as ULIDs and with IPA1,...,IPAn and IPB1,...,IPBm as locator sets, respectively.
この付録では、我々はコンテキスト損失及び潜在的な文脈回復ストラテジを検出するために考えられ異なるアプローチを提示します。ノードAとノードBは、IPA1とIPB1を使用して通信している：検討されたシナリオは、以下です。いつか後に、シムコンテキストはIPA1とULIDsなどIPB1とし、IPA1、...、IPAnとIPB1、...、ロケータセットなどIPBM、それぞれで、それらの間に確立されます。
It may happen that, later on, one of the hosts (e.g., Host A) loses the shim context. The reason for this can be that Host A has a more aggressive garbage collection policy than Host B or that an error occurred in the shim layer at Host A and resulted in the loss of the context state.
それは後に、それが起こることがあり、ホスト（例えば、ホストA）の一方がシムコンテキストを失います。その理由は、ホストAはホストBよりもまたはエラーがホストAでシム層で発生したとコンテキスト状態の損失をもたらしたことをより積極的なガベージコレクションのポリシーを持っていることができます。
The mechanisms considered in this appendix are aimed at dealing with this problem. There are essentially two tasks that need to be performed in order to cope with this problem: first, the context loss must be detected and, second, the context needs to be recovered/ re-established.
この付録では考慮メカニズムは、この問題に対処することを目的としています。そして、第二、コンテキストは/回復再確立する必要がある最初の、コンテキスト損失が検出されなければならない。この問題に対処するために実行する必要のある2つのタスクが基本的にあります。
Mechanisms for detecting context loss.
コンテキストの損失を検出するためのメカニズム。
These mechanisms basically consist in each end of the context that periodically sends a packet containing context-specific information to the other end. Upon reception of such packets, the receiver verifies that the required context exists. In the case that the context does not exist, it sends a packet notifying the sender of the problem.
これらのメカニズムは、基本的には定期的に他端にコンテキスト固有の情報を含むパケットを送信するコンテキストの各端部に構成されています。そのようなパケットを受信すると、受信機は、必要なコンテキストが存在することを検証します。コンテキストが存在しない場合には、それは問題の送信者に通知パケットを送信します。
An obvious alternative for this would be to create a specific context keepalive exchange, which consists in periodically sending packets with this purpose. This option was considered and discarded because it seemed an overkill to define a new packet exchange to deal with this issue.
このため明白な選択肢は、定期的にこの目的のためにパケットを送信することにある特定のコンテキストキープアライブ交換を、作成することです。それは、この問題に対処するため、新たなパケット交換を定義するためのやり過ぎに見えたため、このオプションを考慮し、廃棄しました。
Another alternative is to piggyback the context-loss detection function in other existent packet exchanges. In particular, both shim control and data packets can be used for this.
別の代替案は、他の既存のパケット交換のコンテキスト損失検出機能をピギーバックすることです。特に、シム制御およびデータパケットの両方が、このために使用することができます。
Shim control packets can be trivially used for this because they carry context-specific information. This way, when a node receives one such packet, it will verify if the context exists. However, shim control frequency may not be adequate for context-loss detection since control packet exchanges can be very limited for a session in certain scenarios.
彼らは、コンテキスト固有の情報を運ぶため、シム制御パケットは自明このために使用することができます。コンテキストが存在する場合、この方法は、ノードがそのようなパケットを受信すると、確認します。制御パケット交換は、特定のシナリオにおけるセッションのための非常に制限することができるので、シム制御周波数は、コンテキストの損失を検出するための適切ではないかもしれません。
Data packets, on the other hand, are expected to be exchanged with a higher frequency but do not necessarily carry context-specific information. In particular, packets flowing before a locator change (i.e., a packet carrying the ULIDs in the address fields) do not need context information since they do not need any shim processing. Packets that carry locators that differ from the ULIDs carry context information.
データパケットは、一方で、より高い頻度で交換されることが予想されるが、必ずしもコンテキスト固有の情報を運びません。それらは、任意のシム処理を必要としないので、特に、ロケータ変更前流れるパケット（アドレスフィールドにULIDsを運ぶすなわち、パケット）は、コンテキスト情報を必要としません。 ULIDs異なるロケータを運ぶパケットは、コンテキスト情報を運びます。
However, we need to make a distinction here between the different approaches considered to carry the Context Tag -- in particular, between those approaches where packets are explicitly marked as shim packets and those approaches where packets are not marked as such. For instance, in the case where the Context Tag is carried in the Flow Label and packets are not marked as shim packets (i.e., no new Next Header values are defined for shim), a receiver that has lost the associated context is not able to detect that the packet is associated with a missing context. The result is that the packet will be passed unchanged to the upper-layer protocol, which in turn will probably silently discard it due to a checksum error. The resulting behavior is that the context loss is undetected. This is one additional reason to discard an approach that carries the Context Tag in the Flow Label field and does not explicitly mark the shim packets as such. On the other hand, approaches that mark shim data packets (like those that use the Extension header or the Flow Label with new Next Header values) allow the receiver to detect if the context associated to the received packet is missing. In this case, data packets also perform the function of a context-loss detection exchange. However, it must be noted that only those packets that carry a locator that differs from the ULID are marked. This basically means that context loss will be detected after an outage has occurred, i.e., alternative locators are being used.
具体的には、パケットが明示的にシムパケットとパケットがそのようにマークされていないものをアプローチとしてマークされ、それらのアプローチの間 - しかし、我々はコンテキストタグを運ぶために考えられ異なるアプローチの間、ここで区別をする必要があります。例えば、コンテキストタグがフローラベルに運ばれ、パケットはシムパケットとしてマークされていない場合（つまり、新しい次のヘッダー値はシム用に定義されていない）で、関連するコンテキストを失った受信機は、することができませんパケットが欠落しているコンテキストに関連付けられていることを検出します。その結果、パケットが順番におそらく黙っによるチェックサムエラーにそれを破棄します上位層プロトコルにそのまま渡されるということです。結果の動作は、コンテキストの損失が検出されないということです。これは、フローラベルフィールドにコンテキストタグを運び、そのように明示的にシムパケットをマークしないアプローチを破棄する一つの追加的な理由です。一方、（新しいネクストヘッダ値と拡張ヘッダまたはフローラベルを使用するもののような）そのマークシムデータパケットが受信されたパケットに関連するコンテキストがない場合、受信機が検出することを可能に近づきます。この場合、データパケットは、コンテキスト損失検出交換の機能を実行します。しかし、ULID異なりロケータを運ぶパケットのみがマークされていることに注意しなければなりません。これは、基本的に障害が発生した後にそのコンテキストの損失、すなわち、別のロケータが使用されている、検出されることを意味します。
Summarizing, the proposed context-loss detection mechanisms use shim control packets and Shim6 Payload Extension headers to detect context loss. Shim control packets detect context loss during the whole lifetime of the context, but the expected frequency in some cases is very low. On the other hand, Shim6 Payload Extension headers have a higher expected frequency in general, but they only detect context loss after an outage. This behavior implies that it will be common that context loss is detected after a failure, i.e., once it is actually needed. Because of that, a mechanism for recovering from context loss is required if this approach is used.
要約すると、提案されたコンテキスト損失検出メカニズムは、コンテキストの損失を検出するために、シム制御パケットとSHIM6ペイロード拡張ヘッダを使用します。シム制御パケットは、コンテキストの全寿命期間中のコンテキストの損失を検出しますが、いくつかのケースで期待頻度は非常に低いです。一方、SHIM6ペイロード拡張ヘッダは、一般に、より高い期待周波数を有するが、それらは唯一の停止後コンテキストの損失を検出します。この動作は、それが実際に必要とされると、すなわち、コンテキスト損失が失敗した後に検出されることが普通になるであろうことを意味しています。このアプローチが使用される場合そのため、コンテキストの損失から回復するための機構が必要となります。
Overall, the mechanism for detecting lost context would work as follows: the end that still has the context available sends a message referring to the context. Upon the reception of such message, the end that has lost the context identifies the situation and notifies the other end of the context-loss event by sending a packet containing the lost context information extracted from the received packet.
まだ利用できるコンテキストを持って最後には、コンテキストを参照するメッセージを送信します。次のように全体的に、失われたコンテキストを検出するためのメカニズムが働くだろう。そのようなメッセージを受信すると、コンテキストを失った端部は、状況を識別し、受信パケットから抽出された失われたコンテキスト情報を含むパケットを送信することによってコンテキスト損失事象の他端に通知します。
One option is to simply send an error message containing the received packets (or at least as much of the received packet that the MTU allows to fit). One of the goals of this notification is to allow the other end that still retains context state to re-establish the lost context. The mechanism to re-establish the lost context consists in performing the 4-way initial handshake. This is a time-consuming exchange and, at this point, time may be critical since we are re-establishing a context that is currently needed (because context-loss detection may occur after a failure). So another option, which is the one used in this protocol, is to replace the error message with a modified R1 message so that the time required to perform the context-establishment exchange can be reduced. Upon the reception of this modified R1 message, the end that still has the context state can finish the context-establishment exchange and restore the lost context.
1つのオプションは、単に（MTUがフィットすることができ、受信したパケットのか、少なくとも同じくらい）受信したパケットを含むエラーメッセージを送信することです。この通知の目標の一つは、まだ再確立喪失コンテキストにコンテキスト状態を保持し、もう一方の端を可能にすることです。喪失コンテキストを再確立するためのメカニズムは、4ウェイの初期ハンドシェイクを実行することにあります。これは時間のかかる交換であると、私たちは（コンテキスト・ロス検出が失敗した後に発生する可能性があるため）、現在必要とされているコンテキストを再確立しているので、この時点では、時間が重要になることがあります。したがって、このプロトコルで使用されるものである別のオプションは、コンテキスト確立交換を実行するために必要な時間を短縮することができるように改変R1メッセージとエラー・メッセージを交換することです。この変形R1メッセージを受信すると、まだコンテキスト状態を有する端部は、コンテキスト確立交換を終了し、失われたコンテキストをリストアすることができます。
D.4. Securing Locator Sets
D.4。ロケータセットを確保
The adoption of a protocol like SHIM, which allows the binding of a given ULID with a set of locators, opens the door for different types of redirection attacks as described in [15]. The goal, in terms of
[15]に記載されているようにロケータのセットで、所与のULIDの結合を可能にSHIM、のようなプロトコルの採用は、リダイレクション攻撃の異なるタイプのドアを開けます。の面での目標、
security, for the design of the shim protocol is to not introduce any new vulnerability into the Internet architecture. It is a non-goal to provide additional protection other than what is currently available in the single-homed IPv6 Internet.
シムプロトコルの設計のためのセキュリティは、インターネットアーキテクチャに新たな脆弱性を導入しないことです。シングルホームのIPv6インターネットで現在利用可能なもの以外に追加の保護を提供するために、非目標です。
Multiple security mechanisms were considered to protect the shim protocol. In this appendix we will present some of them.
複数のセキュリティ・メカニズムは、シムプロトコルを保護するために考えられました。この付録では、それらのいくつかを紹介します。
The simplest option to protect the shim protocol is to use cookies, i.e., a randomly generated bit string that is negotiated during the context-establishment phase and then is included in subsequent signaling messages. By these means, it would be possible to verify that the party that was involved in the initial handshake is the same party that is introducing new locators. Moreover, before using a new locator, an exchange is performed through the new locator, verifying that the party located at the new locator knows the cookie, i.e., that it is the same party that performed the initial handshake.
シムプロトコルを保護するための最も簡単なオプションは、即ち、クッキーを使用するコンテキスト確立フェーズ中にネゴシエートされ、次いで、後続のシグナリングメッセージに含まれるランダムに生成されたビット列です。これらの手段によって、最初の握手に関与した当事者が新しいロケータを導入しているのと同じパーティであることを確認することが可能であろう。また、新しいロケータを使用する前に、交換が新しいロケータに所在する者は、それが最初のハンドシェイクを行っ同じ党であること、すなわち、クッキーを知っていることを確認し、新しいロケータを介して行われます。
While this security mechanism does indeed provide a fair amount of protection, it leaves the door open for so-called time-shifted attacks. In these attacks, an attacker on the path discovers the cookie by sniffing any signaling message. After that, the attacker can leave the path and still perform a redirection attack since, as he is in possession of the cookie, he can introduce a new locator into the locator set and can also successfully perform the reachability exchange if he is able to receive packets at the new locator. The difference with the current single-homed IPv6 situation is that in the current situation the attacker needs to be on-path during the whole lifetime of the attack, while in this new situation (where only cookie protection is provided), an attacker that was once on the path can perform attacks after he has left the on-path location.
このセキュリティメカニズムが実際に保護のかなりの量を提供しませんが、それはいわゆるタイムシフト攻撃のためのオープンドアを残します。これらの攻撃では、経路上の攻撃者は、任意のシグナリングメッセージをスニッフィングすることによりクッキーを発見します。その後、攻撃者は、パスを残して、まだ以来、リダイレクション攻撃を実行し、彼はクッキーを所有しているように、彼はロケータセットに新しいロケータを導入することができ、彼が受け取ることができる場合も成功到達可能性交換を行うことができ新しいロケータでパケット。現在のシングルホームのIPv6状況との違いは、現在の状況では、攻撃者がこの新しい状況（のみクッキーの保護が提供される場合）、だった攻撃にいる間、攻撃の一生の間にパスする必要があるということです彼は上のパスの場所を離れた後に一度パスへの攻撃を行うことができます。
Moreover, because the cookie is included in signaling messages, the attacker can discover the cookie by sniffing any of them, making the protocol vulnerable during the whole lifetime of the shim context. A possible approach to increase security is to use a shared secret, i.e., a bit string that is negotiated during the initial handshake but that is used as a key to protect following messages. With this technique, the attacker must be present on the path and sniffing packets during the initial handshake, since this is the only moment when the shared secret is exchanged. Though it imposes that the attacker must be on path at a very specific moment (the establishment phase), and though it improves security, this approach is still vulnerable to time-shifted attacks. It should be noted that, depending on protocol details, an attacker may be able to force the re-creation of the initial handshake (for instance, by blocking messages and making the parties think that the context has been lost); thus, the resulting situation may not differ that much from the cookie-based approach.
クッキーは、シグナリングメッセージに含まれているため、また、攻撃者が、それらのいずれかをスニッフィングシムコンテキストの全寿命の間、脆弱なプロトコルを行うことで、クッキーを発見することができます。セキュリティを高めるための可能なアプローチは、すなわち、初期ハンドシェイク中にネゴシエートされますが、それは次のメッセージを保護するためのキーとして使用されているビット列を共有秘密鍵を使用することです。これは、共有シークレットが交換された瞬間だけであるため、この手法では、攻撃者は、パス上に存在し、最初のハンドシェイク時にパケットを盗聴する必要があります。けれどもそれは、攻撃者が非常に特定の瞬間（確立フェーズ）でパス上になければならないことを課し、それはセキュリティを向上させても、このアプローチは、まだタイムシフト攻撃に対して脆弱です。 （例えば、メッセージの遮断とパーティーをすることによってコンテキストが失われていると思います）プロトコルの詳細に応じて、攻撃者は最初のハンドシェイクの再作成を強制することができるかもしれ、ことに留意すべきです。従って、得られた状況は、クッキーベースのアプローチからそれほど異なっていてもよいです。
Another option that was discussed during the design of this protocol was the possibility of using IPsec for protecting the shim protocol. Now, the problem under consideration in this scenario is how to securely bind an address that is being used as ULID with a locator set that can be used to exchange packets. The mechanism provided by IPsec to securely bind the address that is used with cryptographic keys is the usage of digital certificates. This implies that an IPsec-based solution would require a common and mutually trusted third party to generate digital certificates that bind the key and the ULID. Considering that the scope of application of the shim protocol is global, this would imply a global public key infrastructure (PKI). The major issues with this approach are the deployment difficulties associated with a global PKI. The other possibility would be to use some form of opportunistic IPSec, like Better-Than-Nothing-Security (BTNS) [22]. However, this would still present some issues. In particular, this approach requires a leap-of-faith in order to bind a given address to the public key that is being used, which would actually prevent the most critical security feature that a Shim6 security solution needs to achieve from being provided: proving identifier ownership. On top of that, using IPsec would require to turn on per-packet AH/ESP just for multihoming to occur.
このプロトコルの設計の際に議論された別のオプションは、シムプロトコルを保護するためにIPsecを使用する可能性でした。今、このシナリオでは、考慮中の問題を確実にパケットを交換するために使用することができるロケータセットにULIDとして使用されているアドレスをバインドする方法です。セキュア暗号鍵と一緒に使用されているアドレスをバインドするためにIPsecによって提供されるメカニズムは、デジタル証明書の使用です。これは、IPsecベースのソリューションは、キーとULIDをバインドするデジタル証明書を生成するために、共通して、相互に信頼できるサードパーティが必要になることを意味しています。シムプロトコルの適用範囲がグローバルであることを考えると、これはグローバルな公開鍵基盤（PKI）を暗示します。このアプローチの主要な問題は、グローバルPKIに関連した展開の難しさです。他の可能性はよりも良い何も-Securityのような日和見のIPSec、（BTNS）[22]のいくつかのフォームを使用することです。しかし、これはまだいくつかの問題を提示します。特に、このアプローチは、実際にSHIM6セキュリティソリューションが提供されることから達成するために必要であることが最も重要なセキュリティ機能を妨げることになる、飛躍の信仰使用されている公開鍵に与えられたアドレスをバインドするために必要です。証明します識別子の所有権。その上で、IPsecを使用すると、ちょうどマルチホーミングが発生するため、パケットごとのAH / ESPをオンにする必要になります。
In general, SHIM6 was expected to work between pairs of hosts that have no prior arrangement, security association, or common, trusted third party. It was also seen as undesirable to have to turn on per-packet AH/ESP just for the multihoming to occur. However, Shim6 should work and have an additional level of security where two hosts choose to use IPsec.
一般的には、SHIM6は事前配置、セキュリティアソシエーション、または一般的な、信頼できるサードパーティを持っていないホストのペア間で動作するように期待されました。また、マルチホーミングが発生するだけのためにパケットごとのAH / ESPオンにする必要が望ましくないと見られていました。しかし、SHIM6は仕事と2つのホストがIPsecを使用することを選択し、追加のセキュリティレベルを持つ必要があります。
Another design alternative would have employed some form of opportunistic or Better-Than-Nothing Security (BTNS) IPsec to perform these tasks with IPsec instead. Essentially, HIP in opportunistic mode is very similar to SHIM6, except that HIP uses IPsec, employs per-packet ESP, and introduces another set of identifiers.
別の設計の代替ではなく、IPsecのでこれらのタスクを実行するために日和見orベター・ザン・ナッシングセキュリティ（BTNS）のIPsecのいくつかのフォームを使用しているだろう。基本的に、そのHIPは、IPsecを使用する以外日和見モードでのHIPは、SHIM6に非常に似て、パケットごとのESPを採用し、識別子の別のセットを紹介します。
Finally, two different technologies were selected to protect the shim protocol: HBA [3] and CGA [2]. These two techniques provide a similar level of protection but also provide different functionality with different computational costs.
HBA [3]及びCGA [2]：最後に、二つの異なる技術がシムプロトコルを保護するために選択しました。これら2つの技術が保護の同様のレベルを提供するだけでなく、さまざまな計算コストで異なる機能を提供します。
The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, addresses incorporate a cryptographic one-way hash of the prefix set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using the shim protocol node can efficiently verify that the alternative addresses proposed for continuing the communication are bound to the initial address through a simple hash calculation. A limitation of the HBA technique is that, once generated, the address set is fixed and cannot be changed without also changing all the addresses of the HBA set. In other words, the HBA technique does not support dynamic addition of address to a previously generated HBA set. An advantage of this approach is that it requires only hash operations to verify a locator set, imposing very low computational cost to the protocol.
HBAのメカニズムは、HBAのセットとして知られている本質的にバインドされたIPv6アドレスの変更不可能なセットとしてマルチホームホストのすべてのアドレスを生成する機能に依存しています。このアプローチでは、アドレスは、インタフェース識別子部分の中に使用可能に設定プレフィックスの暗号一方向ハッシュを組み込みます。その結果、すべての利用可能なアドレスの間の結合は、ハイジャックの保護を提供し、アドレス自体の内にコードされていることです。シムプロトコルノードを使用して、任意のピアは、効率的に通信を継続するために提案された代替アドレスが簡単なハッシュ演算により初期アドレスにバインドされていることを確認することができます。 HBA技術の制限は、一旦、生成されたアドレスのセットが固定され、またHBAのセットのすべてのアドレスを変更することなく変更することができない、ということです。換言すれば、HBA技術は、以前に生成されたHBAのセットへのアドレスの動的な追加をサポートしていません。このアプローチの利点は、プロトコルに非常に低い計算コストを課し、ロケータセットを確認するためにのみハッシュ操作を必要とすることです。
In a CGA-based approach, the address used as ULID is a CGA that contains a hash of a public key in its interface identifier. The result is a secure binding between the ULID and the associated key pair. This allows each peer to use the corresponding private key to sign the shim messages that convey locator set information. The trust chain in this case is the following: the ULID used for the communication is securely bound to the key pair because it contains the hash of the public key, and the locator set is bound to the public key through the signature. The CGA approach then supports dynamic addition of new locators in the locator set, since in order to do that the node only needs to sign the new locator with the private key associated with the CGA used as ULID. A limitation of this approach is that it imposes systematic usage of public key cryptography with its associate computational cost.
CGAベースのアプローチでは、ULIDとして使用されるアドレスは、そのインターフェース識別子における公開鍵のハッシュが含まCGAです。結果はULIDと関連する鍵ペア間の安全な結合です。これは、各ロケータ情報を設定伝えるシムメッセージに署名するために対応する秘密鍵を使用するピアことができます。この場合の信頼チェーンは、以下である：ULIDは、通信が確実に鍵ペアにバインドされているため、それは公開鍵のハッシュを含み、ロケータセットは署名を介して公開鍵にバインドされているため使用しました。 CGAのアプローチは、ノードが唯一のULIDとして使用するCGAに関連した秘密鍵で新しいロケータに署名する必要があることを行うためであるため、ロケータセットの新しいロケータの動的な追加をサポートしています。このアプローチの限界は、その仲間計算コストで、公開鍵暗号方式の体系的な使用法を課していることです。
Either of these two mechanisms, HBA and CGA, provides time-shifted attack protection, since the ULID is securely bound to a locator set that can only be defined by the owner of the ULID.
ULIDが確実のみULIDの所有者によって定義することができるロケータセットに結合されているので、これら二つのメカニズム、HBA及びCGA、のいずれかが、タイムシフト攻撃防御を提供します。
So the design decision adopted was that both mechanisms, HBA and CGA, are supported. This way, when only stable address sets are required, the nodes can benefit from the low computational cost offered by HBA, while when dynamic locator sets are required, this can be achieved through CGAs with an additional cost. Moreover, because HBAs are defined as a CGA extension, the addresses available in a node can simultaneously be CGAs and HBAs, allowing the usage of the HBA and CGA functionality when needed, without requiring a change in the addresses used.
だから、採用デザインの決定は両方のメカニズム、HBAおよびCGAが、サポートされているということでした。唯一の安定したアドレスセットが必要な場合、動的ロケータセットが必要な場合、これは追加のコストでCGAsによって達成することができるが、この方法は、ノードは、HBAによって提供される低い計算コストから利益を得ることができます。 HBAがCGA拡張として定義されているので、また、ノードで使用可能なアドレスが同時に使用されるアドレスの変更を必要とせず、必要なときにHBAとCGA機能の使用を可能にする、CGAsおよびHBAとすることができます。
D.5. ULID-Pair Context-Establishment Exchange
D.5。 ULIDペアコンテキストの確立交換
Two options were considered for the ULID-pair context-establishment exchange: a 2-way handshake and a 4-way handshake.
2ウェイハンドシェイクおよび4ウェイハンドシェイク：二つのオプションがULID対コンテキスト確立交換のために考慮されました。
A key goal for the design of this exchange was protection against DoS attacks. The attack under consideration was basically a situation where an attacker launches a great amount of ULID-pair establishment-request packets, exhausting the victim's resources similarly to TCP SYN flooding attacks.
この交換の設計のための重要な目標は、DoS攻撃からの保護でした。検討中の攻撃は基本的に、攻撃者がTCP SYNフラッディング攻撃と同様に被害者のリソースを消耗、ULIDペアの確立要求パケットを大量に起動状況でした。
A 4-way handshake exchange protects against these attacks because the receiver does not create any state associated to a given context until the reception of the second packet, which contains prior-contact proof in the form of a token. At this point, the receiver can verify that at least the address used by the initiator is valid to some extent, since the initiator is able to receive packets at this address. In the worst case, the responder can track down the attacker using this address. The drawback of this approach is that it imposes a 4-packet exchange for any context establishment. This would be a great deal if the shim context needed to be established up front, before the communication can proceed. However, thanks to the deferred context-establishment capability of the shim protocol, this limitation has a reduced impact in the performance of the protocol. (However, it may have a greater impact in the situation of context recovery, as discussed earlier. However, in this case, it is possible to perform optimizations to reduce the number of packets as described above.)
受信機は、トークンの形で従来のコンタクトプルーフを含む第2のパケットを受信するまで、所与のコンテキストに関連する任意の状態を作成しないため、4ウェイハンドシェイク交換は、これらの攻撃から保護します。この時点で、受信機は、イニシエータが、このアドレスにパケットを受信することができるので、少なくともイニシエータによって使用されるアドレスは、ある程度有効であることを検証することができます。最悪の場合、応答者は、このアドレスを使用して、攻撃者を追跡することができます。このアプローチの欠点は、それが任意のコンテキストの確立のために4パケット交換を課すことです。シムコンテキストが通信を続行する前に、前もって確立するために必要な場合、これは非常に多くなります。しかし、シムプロトコルの遅延コンテキスト確立能力のおかげで、この制限は、プロトコルの性能の低下の影響を有しています。 （前述のようしかし、それは、コンテキスト回復の状況に大きな影響を有することができる。しかし、この場合には、上記のようにパケットの数を減少させるために最適化を行うことが可能です。）
The other option considered was a 2-way handshake with the possibility to fall back to a 4-way handshake in case of attack. In this approach, the ULID-pair establishment exchange normally consists of a 2-packet exchange and does not verify that the initiator has performed a prior contact before creating context state. In case a DoS attack is detected, the responder falls back to a 4-way handshake similar to the one described previously, in order to prevent the detected attack from proceeding. The main difficulty with this attack is how to detect that a responder is currently under attack. It should be noted that, because this is a 2-way exchange, it is not possible to use the number of half-open sessions (as in TCP) to detect an ongoing attack; different heuristics need to be considered.
考え、他のオプションは攻撃の場合にはバック4ウェイハンドシェイクにフォールする可能性を持つ2ウェイハンドシェイクました。このアプローチでは、ULID対確立交換は、通常、2パケット交換で構成され、イニシエータがコンテキスト状態を作成する前に、前の接触を行ったことを確認しません。 DoS攻撃が検出された場合には、応答は、バック進行から検出された攻撃を防止するために、先に記載したものと同様の4ウェイハンドシェイクに落ちます。この攻撃での主な問題は、応答者が攻撃を受け、現在であることを検出する方法です。 2ウェイの交換であるので、進行中の攻撃を検出するために、（TCPのように）ハーフオープンセッションの数を使用することはできないことに留意されたいです。異なるヒューリスティックを考慮する必要があります。
The design decision taken was that, considering the current impact of DoS attacks and the low impact of the 4-way exchange in the shim protocol (thanks to the deferred context-establishment capability), a 4-way exchange would be adopted for the base protocol.
採取設計上の決定は、DoS攻撃の現在の影響とシムプロトコルにおける4ウェイ交換の低い影響（遅延コンテキスト確立能力のおかげで）を考慮し、4ウェイ交換をベースに採用されるであろう、ということでしたプロトコル。
D.6. Updating Locator Sets
D.6。更新ロケータセット
There are two possible approaches to the addition and removal of locators: atomic and differential approaches. The atomic approach essentially sends the complete locator set each time a variation in the locator set occurs. The differential approach sends the differences between the existing locator set and the new one. The atomic approach imposes additional overhead since all of the locator set has to be exchanged each time, while the differential approach requires re-synchronization of both ends through changes (i.e., requires that both ends have the same idea about what the current locator set is).
原子・ディファレンシャルアプローチ：ロケータの追加と削除には2つの可能なアプローチがあります。原子アプローチは、本質的にロケータセットのばらつきが発生するたびに、完全なロケータセットを送信します。差動アプローチは、既存のロケータセットと新しいものとの違いを送信します。差分アプローチが変化する（すなわちを通じて再同期両端の必要とするロケータセットの全てが、毎回交換しなければならないため、原子のアプローチは、追加のオーバーヘッドを課す、両端が現在のロケータセットが何であるかについて同じ考えを持っている必要が）。
Because of the difficulties imposed by the synchronization requirement, the atomic approach was selected.
なぜなら同期要件によって課される困難のため、原子アプローチを選択しました。
D.7. State Cleanup
D.7。州のクリーンアップ
There are essentially two approaches for discarding an existing state about locators, keys, and identifiers of a correspondent node: a coordinated approach and an unilateral approach.
協調的なアプローチと一方的なアプローチ：ロケータ、キー、およびコレスポンデントノードの識別子に関する既存の状態を廃棄するための2つのアプローチが基本的にあります。
In the unilateral approach, each node discards information about the other node without coordination with the other node, based on some local timers and heuristics. No packet exchange is required for this. In this case, it would be possible that one of the nodes has discarded the state while the other node still hasn't. In this case, a No Context Error message may be required to inform the other node about the situation; possibly a recovery mechanism is also needed.
一方的なアプローチでは、各ノードは、いくつかのローカルタイマーとヒューリスティックに基づいて、他のノードと協調することなく、他のノードに関する情報を破棄する。いいえ、パケット交換は、このために必要とされません。この場合には、他のノードがまだいないがいずれかのノードが状態を破棄している可能性があろう。この場合、コンテキストエラーメッセージは状況について他のノードに通知するために必要とされ得ます。おそらく回復メカニズムも必要とされています。
A coordinated approach would use an explicit CLOSE mechanism, akin to the one specified in HIP [20]. If an explicit CLOSE handshake and associated timer is used, then there would no longer be a need for the No Context Error message due to a peer having garbage collected at its end of the context. However, there is still potentially a need to have a No Context Error message in the case of a complete state loss of the peer (also known as a crash followed by a reboot). Only if we assume that the reboot takes at least the time of the CLOSE timer, or that it is okay to not provide complete service until CLOSE-timer minutes after the crash, can we completely do away with the No Context Error message.
協調アプローチは、[20] HIPで指定されたものに類似し、明示的なCLOSE機構を使用します。明示的なCLOSEハンドシェイクと関連するタイマが使用されている場合には、もはやによるコンテキストのその端部に集めピアたごみにはありませんコンテキストエラーメッセージの必要性はないだろう。しかし、（また、再起動が続くクラッシュとして知られている）ピアの完全な状態の損失の場合ではありませんコンテキストエラーメッセージを持っている必要がありますが、潜在的にまだあります。我々は、再起動が少なくともCLOSEタイマーの時間がかかる、または、クラッシュ後CLOSE-タイマー分まで、完全なサービスを提供し、我々は完全に離れないコンテキストエラーメッセージを表示して行うことができないように、それは大丈夫であることと仮定した場合のみ。
In addition, another aspect that is relevant for this design choice is the context confusion issue. In particular, using a unilateral approach to discard context state clearly opens up the possibility of context confusion, where one of the ends unilaterally discards the context state, while the other does not. In this case, the end that has discarded the state can re-use the Context Tag value used for the discarded state for another context, creating potential context confusion. In order to illustrate the cases where problems would arise, consider the following scenario:
また、この設計上の選択に関連する別の態様は、コンテキストの混乱の問題です。特に、明らかに文脈状態を破棄する一方的アプローチを使用して、他にはないながら、端部の一方が一方的に、コンテキスト状態を破棄コンテキスト混乱の可能性を開きます。この場合には、状態を破棄した端部は、潜在的なコンテキストの混乱を作成し、別のコンテキストの廃棄状態に使用されるコンテキスト・タグ値を再使用することができます。問題が生じるであろう例を説明するために、次のシナリオを検討してください。
o Hosts A and B establish context 1 using CTA and CTB as Context Tags.
OホストA及びBは、コンテキストタグとしてCTA及びCTBを使用してコンテキスト1を確立します。
o Later on, A discards context 1 and the Context Tag value CTA becomes available for reuse.
Oその後、Aは、コンテキスト1およびCTAは、再利用のために利用可能になるコンテキストタグ値を破棄します。
o However, B still keeps context 1.
Oただし、Bは、まだコンテキスト1を保持します。
This would create context confusion in the following two cases:
これは、次の2つの場合にコンテキストの混乱を作成します。
o A new context 2 is established between A and B with a different ULID pair (or Forked Instance Identifier), and A uses CTA as the Context Tag. If the locator sets used for both contexts are not disjoint, we have context confusion.
新しいコンテキスト2 O異なるULID対（又はフォークトインスタンス識別子）を用いてAとBとの間に確立され、そしてAは、コンテキストタグとしてCTAを使用します。両方のコンテキストに使用するロケータセットが互いに素でない場合、我々はコンテキストの混乱を持っています。
o A new context is established between A and C, and A uses CTA as the Context Tag value for this new context. Later on, B sends Payload Extension header and/or control messages containing CTA, which could be interpreted by A as belonging to context 2 (if no proper care is taken). Again we have context confusion.
O新しいコンテキストは、AとCとの間で確立され、そしてAは、この新しいコンテキストのコンテキストタグ値としてCTAを使用しています。後に、Bは（何も適切なケアが取られていない場合）、コンテキスト2に属するとAによって解釈することができたCTAを含むペイロード拡張ヘッダ及び/又は制御メッセージを送信します。再び、我々はコンテキストの混乱を持っています。
One could think that using a coordinated approach would eliminate such context confusion, making the protocol much simpler. However, this is not the case, because even in the case of a coordinated approach using a CLOSE/CLOSE ACK exchange, there is still the possibility of a host rebooting without having the time to perform the CLOSE exchange. So, it is true that the coordinated approach eliminates the possibility of context confusion due to premature garbage collection, but it does not prevent the same situations due to a crash and reboot of one of the involved hosts. The result is that, even if we went for a coordinated approach, we would still need to deal with context confusion and provide the means to detect and recover from these situations.
一つは、調整されたアプローチを使用すると、プロトコルがはるかに簡単になって、そのような状況の混乱を避けるだろうと考えることができます。 CLOSE / CLOSE ACK交換を使用して調整されたアプローチの場合には、依然としてCLOSE交換を実行するための時間を持つことなく再起動ホストする可能性があるためしかし、これは、そうではありません。だから、協調的なアプローチが原因時期尚早、ガベージコレクションにコンテキスト混乱の可能性を排除ことは事実ですが、それは関係するホストの一つのクラッシュと再起動のために同じような状況を防ぐことはできません。結果は、我々が調整されたアプローチのために行った場合でも、我々はまだコンテキストの混乱に対処し、検出し、このような状況から回復するための手段を提供する必要があるだろう、ということです。
Authors' Addresses
著者のアドレス
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA
エリックNordmarkとSun Microsystemsの17ネットワークサークルメンロパーク、CA 94025 USA
Phone: +1 650 786 2921 EMail: erik.nordmark@sun.com
電話：+1 650 786 2921 Eメール：erik.nordmark@sun.com
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
マドリードのマルセロBagnuloチャールズIII大学のAv。大学30レガネス、マドリード28911スペイン
Phone: +34 91 6248814 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es
電話：+34 91 6248814 Eメール：marcelo@it.uc3m.es URI：http://www.it.uc3m.es