[要約] RFC 7219は、SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)のための仕様です。その目的は、IPv6ネットワークでの送信元アドレスの検証を強化し、ネットワークへの攻撃を防ぐことです。
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 7219 A. Garcia-Martinez
Category: Standards Track UC3M
ISSN: 2070-1721 May 2014
SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)
SEcureネイバー探索（SEND）送信元アドレス検証の改善（SAVI）
Abstract
概要
This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.
このメモは、SENDプロトコルを使用してソースアドレス検証を提供するメカニズムである、SEcureネイバー探索（SEND）ソースアドレス検証改善（SAVI）を指定します。提案されたメカニズムは、IPv6送信元アドレスの制御をより細かくするために、入力フィルタリング技術を補完します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7219.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7219で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Background on SEND SAVI . . . . . . . . . . . . . . . . . . . 4
2.1. Address Validation Scope . . . . . . . . . . . . . . . . 4
2.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . 4
2.3. SEND SAVI Protection Perimeter . . . . . . . . . . . . . 7
2.4. Special Cases . . . . . . . . . . . . . . . . . . . . . . 9
3. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 11
3.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 11
3.2. SEND SAVI Device Configuration . . . . . . . . . . . . . 12
3.3. Traffic Processing . . . . . . . . . . . . . . . . . . . 13
3.3.1. Transit Traffic Processing . . . . . . . . . . . . . 13
3.3.2. Local Traffic Processing . . . . . . . . . . . . . . 13
3.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 27
3.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . 28
3.6. Protocol Constants . . . . . . . . . . . . . . . . . . . 28
4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 29
4.1. Change of the Attachment Point of a Host . . . . . . . . 29
4.1.1. Moving to a Port of the Same Switch . . . . . . . . . 29
4.1.2. Moving to a Port of a Different Switch . . . . . . . 30
4.2. Attack of a Malicious Host . . . . . . . . . . . . . . . 31
4.2.1. M Attaches to the Same Switch as the Victim's Switch 31
4.2.2. M Attaches to a Different Switch to the Victim's
Switch . . . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
5.1. Protection against Replay Attacks . . . . . . . . . . . . 33
5.2. Protection against Denial-of-Service Attacks . . . . . . 34
5.3. Considerations on the Deployment Model for Trust Anchors 36
5.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 36
5.5. Privacy Considerations . . . . . . . . . . . . . . . . . 37
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1. Normative References . . . . . . . . . . . . . . . . . . 37
7.2. Informative References . . . . . . . . . . . . . . . . . 38
This memo specifies SEND SAVI, a mechanism to provide source address validation for IPv6 networks using the SEND protocol [RFC3971]. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of the source addresses used.
このメモは、SENDプロトコル[RFC3971]を使用してIPv6ネットワークのソースアドレス検証を提供するメカニズムであるSEND SAVIを指定します。提案されたメカニズムは、入力フィルタリング技術を補完して、使用される送信元アドレスの制御をより細かく提供します。
SEND SAVI uses the DAD_NSOL (Duplicate Address Detection Neighbor SOLicitation) and the DAD_NADV (DAD Neighbor ADVertisement) messages defined in [RFC4862] and the NUD_NSOL (Neighbor Unreachability Detection Neighbor SOLicitation) and NUD_NADV (NUD Neighbor ADVertisement) messages defined in [RFC4861] to validate the address ownership claim of a node. Using the information contained in these messages, host IPv6 addresses are associated to switch ports, so that data packets will be validated by checking for consistency in this binding, as described in [RFC7039]. In addition, SEND SAVI prevents hosts from generating packets containing off-link IPv6 source addresses.
SEND SAVIは、[RFC4862]で定義されたDAD_NSOL（Duplicate Address Detection Neighbor SOLicitation）およびDAD_NADV（DAD Neighbor ADVertisement）メッセージと、NUD_NSOL（Neighbor Unreachability Detection Neighbor SOLicitation）およびNUD_NADV（NUD Neighbor ADVertisement）を使用します。ノードのアドレス所有権の主張を検証します。これらのメッセージに含まれる情報を使用して、ホストIPv6アドレスがスイッチポートに関連付けられ、[RFC7039]で説明されているように、このバインディングの整合性をチェックすることによってデータパケットが検証されます。さらに、SEND SAVIは、ホストがオフリンクIPv6送信元アドレスを含むパケットを生成しないようにします。
Scalability of a distributed SAVI system comprising multiple SEND SAVI devices is preserved by means of a deployment scenario in which SEND SAVI devices form a "protection perimeter". In this deployment scenario, the distributed SAVI system only validates the packets when they ingress to the protection perimeter, not in every SEND SAVI device traversed.
複数のSEND SAVIデバイスで構成される分散SAVIシステムのスケーラビリティは、SEND SAVIデバイスが「保護境界」を形成する配備シナリオによって維持されます。この展開シナリオでは、分散SAVIシステムは、パケットが保護境界に入るときにのみ検証し、通過するすべてのSEND SAVIデバイスでは検証しません。
The SEND SAVI specification, as defined in this document, is limited to links and prefixes in which every IPv6 host and every IPv6 router uses the SEND protocol [RFC3971] to protect the exchange of Neighbor Discovery information. If the SEND protocol is not used, we can deploy other SAVI solutions relying on monitoring different address configuration mechanisms to prove address ownership. For example, FCFS (First-Come, First-Served) SAVI [RFC6620] can be used by nodes locally configuring IPv6 addresses by means of the Stateless Address Autoconfiguration mechanism [RFC4862].
このドキュメントで定義されているSEND SAVI仕様は、すべてのIPv6ホストとすべてのIPv6ルーターがSENDプロトコル[RFC3971]を使用して近隣探索情報の交換を保護するリンクとプレフィックスに限定されています。 SENDプロトコルを使用しない場合は、さまざまなアドレス構成メカニズムの監視に依存する他のSAVIソリューションを展開して、アドレスの所有権を証明できます。たとえば、FCFS（先着順）SAVI [RFC6620]は、ステートレスアドレス自動構成メカニズム[RFC4862]を使用してIPv6アドレスをローカルに構成するノードで使用できます。
SEND SAVI is designed to be deployed in SEND networks with as few changes to the deployed implementations as possible. In particular, SEND SAVI does not require any changes in the nodes whose source address is to be verified. This is because verification solely relies in the usage of already available protocols. Therefore, SEND SAVI neither defines a new protocol nor defines any new message on existing protocols, nor does it require that a host or router use an existing protocol message in a different way.
SEND SAVIは、SENDネットワークに配備されるように設計されており、配備された実装への変更をできるだけ少なくします。特に、SEND SAVIは、送信元アドレスが検証されるノードの変更を必要としません。これは、検証がすでに利用可能なプロトコルの使用にのみ依存しているためです。したがって、SEND SAVIは新しいプロトコルを定義せず、既存のプロトコルの新しいメッセージも定義しません。また、ホストまたはルーターが既存のプロトコルメッセージを別の方法で使用する必要もありません。
An overview of the general framework about Source Address Validation Improvement is presented in [RFC7039].
送信元アドレス検証の改善に関する一般的なフレームワークの概要は、[RFC7039]に示されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The application scenario of SEND SAVI is limited to the local link. This means that the goal of SEND SAVI is to verify that the source addresses of the packets generated by the nodes attached to the local link have not been spoofed and that only legitimate routers generate packets with off-link IPv6 source addresses.
SEND SAVIのアプリケーションシナリオはローカルリンクに限定されます。つまり、SEND SAVIの目的は、ローカルリンクに接続されたノードによって生成されたパケットの送信元アドレスがスプーフィングされていないこと、および正当なルーターだけがオフリンクIPv6送信元アドレスを持つパケットを生成することを確認することです。
In a link, there usually are hosts and routers attached. Hosts generate packets with their own addresses as the source address. This is called "local traffic". Routers may send packets containing a source address other than their own, since they can forward packets generated by other hosts (usually located in a different link). This is the so-called transit traffic.
リンクには、通常、ホストとルーターが接続されています。ホストは、独自のアドレスを送信元アドレスとするパケットを生成します。これは「ローカルトラフィック」と呼ばれます。ルーターは、他のホスト（通常は別のリンクにある）によって生成されたパケットを転送できるため、ルーターは自分以外のソースアドレスを含むパケットを送信できます。これは、いわゆるトランジットトラフィックです。
SEND SAVI allows the validation of the source address of the local traffic, i.e., it allows verification that the source addresses of the packets generated by the nodes attached to the local link have not been spoofed. SEND SAVI also provides means to prevent hosts from generating packets with source addresses derived from off-link prefixes. However, SEND SAVI does not provide the means to verify if a given router is actually authorized to forward packets containing a particular off-link source address. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic.
SEND SAVIを使用すると、ローカルトラフィックの送信元アドレスを検証できます。つまり、ローカルリンクに接続されているノードによって生成されたパケットの送信元アドレスがスプーフィングされていないことを確認できます。また、SEND SAVIは、ホストがオフリンクプレフィックスから派生した送信元アドレスを持つパケットを生成しないようにする手段も提供します。ただし、SEND SAVIは、特定のルーターが特定のオフリンク送信元アドレスを含むパケットの転送を実際に許可されているかどうかを確認する手段を提供しません。通過トラフィックの検証には、イングレスフィルタリング[RFC2827]などの他の手法が推奨されます。
SEND SAVI devices filter packets according to bindings between a layer-2 anchor (the binding anchor) and an IPv6 address. These bindings should allow legitimate nodes to use the bounded IPv6 address as source address and prevent illegitimate nodes from doing so.
SEND SAVIデバイスは、レイヤー2アンカー（バインディングアンカー）とIPv6アドレスの間のバインディングに従ってパケットをフィルタリングします。これらのバインディングにより、正当なノードがバインドされたIPv6アドレスをソースアドレスとして使用できるようになり、不正なノードがそうすることを防ぐ必要があります。
Any SAVI solution is not stronger than the binding anchor it uses. If the binding anchor is easily spoofable (e.g., a Media Access Control (MAC) address), then the resulting solution will be weak. The treatment of non-compliant packets needs to be tuned accordingly. In particular, if the binding anchor is easily spoofable and the SEND SAVI device is configured to drop non-compliant packets, then the usage of SEND SAVI may open a new vector of Denial-of-Service (DoS) attacks, based on spoofed binding anchors. For that reason, implementations of this specification use switch ports as their binding anchors. Other forms of binding anchors are out of the scope of this specification, and proper analysis of the implications of using them should be performed before their usage.
SAVIソリューションは、使用するバインディングアンカーよりも強力ではありません。バインディングアンカーが簡単になりすまし可能（メディアアクセス制御（MAC）アドレスなど）である場合、結果のソリューションは脆弱になります。非準拠パケットの処理は、それに応じて調整する必要があります。特に、バインディングアンカーが簡単にスプーフィングされ、SEND SAVIデバイスが非準拠パケットをドロップするように構成されている場合、SEND SAVIを使用すると、スプーフィングされたバインディングに基づいて、サービス拒否（DoS）攻撃の新しいベクトルが開かれる可能性があります。アンカー。そのため、この仕様の実装では、バインディングアンカーとしてスイッチポートを使用します。他の形式のバインディングアンカーはこの仕様の範囲外であり、それらを使用することの影響の適切な分析は、それらを使用する前に実行する必要があります。
SEND [RFC3971] provides tools to assure that a Neighbor Discovery (ND) message containing a Cryptographically Generated Address (CGA) [RFC3972] option and signed by an RSA option has been generated by the legitimate owner of the CGA IPv6 address.
SEND [RFC3971]は、Cryptographically Generated Address（CGA）[RFC3972]オプションを含み、RSAオプションによって署名されたNeighbor Discovery（ND）メッセージが、CGA IPv6アドレスの正当な所有者によって生成されたことを保証するツールを提供します。
SEND SAVI uses SEND-validated messages to create bindings between the CGA and the port of the SEND SAVI device from which it is reasonable to receive packets with the CGA as the source address. The events that trigger the binding creation process in a SEND SAVI device are:
SEND SAVIは、SENDで検証されたメッセージを使用して、CGAとSEND SAVIデバイスのポートとの間にバインディングを作成します。そこから、CGAをソースアドレスとしてパケットを受信するのが妥当です。 SEND SAVIデバイスでバインディング作成プロセスをトリガーするイベントは次のとおりです。
o The reception of a DAD_NSOL message, indicating the attempt of a node to configure an address. This may occur when a node configures an address for the first time or after being idle for some time or when the node has changed the physical attachment point to the layer-2 infrastructure.
o ノードがアドレスを構成しようとしていることを示すDAD_NSOLメッセージの受信。これは、ノードが初めてアドレスを構成するとき、またはしばらくアイドル状態になった後、またはノードが物理接続ポイントをレイヤー2インフラストラクチャーに変更したときに発生する可能性があります。
o The reception of any other packet (including data packets) with a source address for which no binding exists. This may occur if DAD_NSOL messages were lost, a node has changed the physical attachment point to the layer-2 infrastructure without issuing a DAD_NSOL message, a SAVI device loses a binding (for example, due to a restart), or the link topology changed.
o バインディングが存在しない送信元アドレスを持つ他のパケット（データパケットを含む）の受信。これは、DAD_NSOLメッセージが失われた、ノードがDAD_NSOLメッセージを発行せずに物理接続ポイントをレイヤー2インフラストラクチャに変更した、SAVIデバイスがバインドを失った（再起動などにより）、またはリンクトポロジが変更された場合に発生する可能性があります。
When the binding creation process is triggered, the SEND SAVI device has to assure that the node for which the binding is to be created is the legitimate owner of the address. For the case in which the binding creation process is initiated by a DAD_NSOL exchange, the SEND SAVI device waits for the reception of a validated DAD_NADV message, indicating that the other node has configured the address before, or validated DAD_NSOL messages arriving from other locations, indicating that another node is trying to configure the same address at the same time. For the case in which packets other than a DAD_NSOL initiate the creation of the binding, the SEND SAVI device explicitly requires the node sending those packets to prove address ownership by issuing a secured NUD_NSOL, which has to be answered with a secured NUD_NADV by the probed node.
バインディング作成プロセスがトリガーされると、SEND SAVIデバイスは、バインディングが作成されるノードがアドレスの正当な所有者であることを確認する必要があります。バインディング作成プロセスがDAD_NSOL交換によって開始された場合、SEND SAVIデバイスは、検証済みのDAD_NADVメッセージの受信を待ちます。これは、他のノードが以前にアドレスを設定したこと、または検証済みのDAD_NSOLメッセージが他の場所から到着したことを示します。別のノードが同じアドレスを同時に設定しようとしていることを示しています。 DAD_NSOL以外のパケットがバインディングの作成を開始する場合、SEND SAVIデバイスは、プローブによって保護されたNUD_NADVで応答する必要がある保護されたNUD_NSOLを発行して、アドレスの所有権を証明するためにそれらのパケットを送信するノードに明示的に要求しますノード。
SEND SAVI devices issue secured NUD_NSOL messages periodically in order to refresh bindings, which have to be answered with a valid NUD_NADV message by the node for which the binding exists.
SEND SAVIデバイスは、バインディングをリフレッシュするために、保護されたNUD_NSOLメッセージを定期的に発行します。バインディングは、バインディングが存在するノードによって有効なNUD_NADVメッセージで応答される必要があります。
SEND SAVI devices only forward packets with off-link source addresses if they are received from a port manually configured to connect to a router.
SEND SAVIデバイスは、ルーターに接続するように手動で構成されたポートから受信した場合にのみ、オフリンクの送信元アドレスを持つパケットを転送します。
SEND SAVI needs to be protected against replay attacks, i.e., attacks in which a secured SEND message is replayed by another node. As discussed before, the SEND SAVI specification uses SEND messages to create a binding between the address contained in the message (that must be signed by a node possessing the private key associated to the address) and the port through which the message is received. If an attacker manages to obtain such a message from another node, for example, because the message was sent to the all-nodes multicast address or because the attacker has subscribed to the Solicited Node multicast address associated to a remote node, it could replay it preserving the original signature. This may create an illegitimate binding in the SEND SAVI device or could be used to abort address configuration at the other node. While SEND provides some means to limit the impact of the replay of ND messages, the emphasis for SEND anti-replay protection is to limit to a short period of time the validity of the ND information transmitted in the message, for example, the relationship between an IPv6 address and a layer-2 address. Note that the period must be long enough to assure that the information sent by the legitimate sender is considered valid despite the possible differences in clock synchronization between the sender and receiver(s). For example, with the values recommended by [RFC3971] for TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, a node receiving a DAD_NSOL message would not discard replays of this message being received within a period of approximately 2 seconds (more precisely, 2/0.99 seconds). The underlying assumption for SEND security is that even if the message is replayed by another node during this period of time, the information disseminated by ND is still the same. However, allowing a node to replay a SEND message does have an impact on the SEND SAVI operation, regardless of the time elapsed since it was generated, since the node can create a new binding in a SEND SAVI device for the port to which an illegitimate node attaches. As can be concluded, the protection provided by SEND is not enough in all cases for SEND SAVI.
SEND SAVIは、リプレイ攻撃、つまり保護されたSENDメッセージが別のノードによってリプレイされる攻撃から保護する必要があります。前に説明したように、SEND SAVI仕様はSENDメッセージを使用して、メッセージに含まれるアドレス（アドレスに関連付けられた秘密鍵を所有するノードによって署名される必要があります）とメッセージを受信するポートとの間のバインディングを作成します。たとえば、メッセージがすべてのノードのマルチキャストアドレスに送信されたため、または攻撃者がリモートノードに関連付けられた要請ノードマルチキャストアドレスにサブスクライブしたために、攻撃者が別のノードからそのようなメッセージを取得した場合、それを再生できます。元の署名を保持します。これにより、SEND SAVIデバイスに不正なバインディングが作成されるか、他のノードでアドレス構成を中止するために使用される可能性があります。 SENDはNDメッセージのリプレイの影響を制限する手段を提供しますが、SENDアンチリプレイ保護の重点は、メッセージで送信されるND情報の有効性、たとえば、 IPv6アドレスとレイヤー2アドレス。期間は、送信者と受信者の間でクロック同期が異なる可能性があるにもかかわらず、正当な送信者によって送信された情報が有効と見なされることを保証するのに十分な長さである必要があります。たとえば、[RFC3971]が推奨するTIMESTAMP_FUZZおよびTIMESTAMP_DRIFTの値では、DAD_NSOLメッセージを受信するノードは、約2秒（正確には2 / 0.99秒）の期間内に受信されたこのメッセージのリプレイを破棄しません。 SENDセキュリティーの基本的な前提は、この期間中にメッセージが別のノードによって再生されても、NDによって配布される情報は同じであるということです。ただし、ノードがSENDメッセージを再生できるようにすると、ノードは、不正なポートのSEND SAVIデバイスに新しいバインディングを作成できるため、生成されてからの経過時間に関係なく、SEND SAVI操作に影響を与えます。ノードが接続されます。結論として、SENDによって提供される保護は、SEND SAVIのすべての場合に十分ではありません。
SEND SAVI increases the protection against the replay attacks compared to SEND. First, each node is required to connect to the SEND SAVI topology through a different port to prevent eavesdropping before entering the SAVI protection perimeter. Then, SEND SAVI bindings are updated only according to messages whose dissemination can be restricted in the SEND SAVI topology without interfering with the normal SEND operation. The messages used by SEND SAVI to create bindings are DAD_NSOL messages, for which SEND SAVI limits its propagation to the ports through which a previous binding for the same IPv6 address existed (see Section 3.3.2), and NUD_NADV messages
SEND SAVIは、SENDと比較して、リプレイ攻撃に対する保護を強化します。まず、各ノードは、SAVI保護境界に入る前に盗聴を防ぐために、異なるポートを介してSEND SAVIトポロジに接続する必要があります。次に、SEND SAVIバインディングは、通常のSEND操作を妨げることなく、SEND SAVIトポロジーで配布を制限できるメッセージに従ってのみ更新されます。 SEND SAVIがバインディングを作成するために使用するメッセージは、DAD_NSOLメッセージです。SADSAVIは、同じIPv6アドレスの以前のバインディングが存在していたポート（セクション3.3.2を参照）への伝播を制限し、NUD_NADVメッセージを送信します。
in response to a secured NUD_NSOL sent by the SEND SAVI device only through the tested port. Finally, SEND SAVI filtering rules prevent nodes from replaying messages generated by the SEND SAVI devices themselves. Section 5.1 discusses in more detail the protection provided by SEND SAVI against replay attacks.
テストされたポートを介してのみSEND SAVIデバイスから送信された保護されたNUD_NSOLへの応答。最後に、SEND SAVIフィルタリングルールは、ノードがSEND SAVIデバイス自体によって生成されたメッセージを再生しないようにします。セクション5.1では、リプレイ攻撃に対してSEND SAVIによって提供される保護について詳しく説明します。
In order to reduce computing and state requirements in SEND SAVI devices, SEND SAVI devices can be deployed to form a "protection perimeter" [RFC7039]. With this deployment strategy, SEND SAVI devices perform source-address validation only when packets enter in the protected realm defined through the protection perimeter. The perimeter is defined by appropriate configuration of the roles of each port, which can be 'Validating' or 'Trusted':
SEND SAVIデバイスの計算と状態の要件を減らすために、SEND SAVIデバイスを配備して「保護境界」を形成することができます[RFC7039]。この展開戦略では、SEND SAVIデバイスは、パケットが保護境界を介して定義された保護されたレルムに入るときにのみ、送信元アドレスの検証を実行します。境界は、各ポートの役割の適切な構成によって定義され、「検証」または「信頼」できます。
o Validating ports (VPs) are ports in which SEND SAVI filtering and binding creation are performed.
o 検証ポート（VP）は、SEND SAVIフィルタリングおよびバインディング作成が実行されるポートです。
o Trusted ports (TPs) are ports in which limited processing is performed. Only SEND messages related with certificates, prefix information, and DAD operation are processed in order to update the state of the SEND SAVI device or the state related with any of the Validating ports of the switch.
o 信頼されたポート（TP）は、限られた処理が実行されるポートです。 SEND SAVIデバイスの状態またはスイッチのいずれかの検証ポートに関連する状態を更新するために、証明書、プレフィックス情報、およびDAD操作に関連するSENDメッセージのみが処理されます。
Figure 1 shows a typical topology involving trusted and untrusted infrastructure.
図1は、信頼できるインフラストラクチャと信頼できないインフラストラクチャを含む一般的なトポロジを示しています。
+--+ +--+ +--+ +--+
|H1| |H2| |H3| |R1|
+--+ +--+ +--+ +--+
| | | |
+------------SEND SAVI PROTECTION PERIMETER-----------+
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SEND- | | SEND- | |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3--4---+ |
| | | +--------------+ | | |
| | +----------| |--------+ | |
| | | SWITCH-A | | |
| | +----------| | | |
| | | +--------------+ | |
| +-1--2----+ +-----1---+ |
| | SEND- | | SEND- | |
| | SAVI3 | | SAVI4 | |
| +-3-----4-+ +----4----+ |
| | | | |
+------------SEND SAVI PROTECTION PERIMETER-----------+
| | |
+--+ +--+ +--+
|R2| |H4| |H5|
+--+ +--+ +--+
Figure 1: SAVI Protection Perimeter
図1：SAVI保護境界
Trusted ports are used for connections with trusted infrastructures, such as routers and other SEND SAVI devices. Port 2 of SEND-SAVI2 and port 3 of SEND-SAVI3 are Validating ports because they connect to routers. Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 as well as port 4 of SEND-SAVI2 and port 1 of SEND-SAVI4 are trusted because they connect two SAVI devices. Finally, port 4 of SEND-SAVI1, port 3 of SEND-SAVI2, and port 2 of SEND-SAVI3 are trusted because they connect to SWITCH-A to which only trusted nodes are connected.
信頼できるポートは、ルーターやその他のSEND SAVIデバイスなどの信頼できるインフラストラクチャとの接続に使用されます。 SEND-SAVI2のポート2およびSEND-SAVI3のポート3は、ルーターに接続しているため、検証ポートです。 SEND-SAVI1のポート3とSEND-SAVI3のポート1、およびSEND-SAVI2のポート4とSEND-SAVI4のポート1は、2つのSAVIデバイスを接続しているため信頼されています。最後に、SEND-SAVI1のポート4、SEND-SAVI2のポート3、SEND-SAVI3のポート2は、信頼されたノードのみが接続されているSWITCH-Aに接続しているため、信頼されています。
Validating ports are used for connection with non-trusted infrastructures; therefore, hosts connect normally to Validating ports. So, in Figure 1 above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND-SAVI2, and port 4 of SEND-SAVI3 are Validating ports because they connect to hosts. Port 4 of SEND-SAVI4 is also a Validating port because it is connected to host H5.
検証ポートは、信頼されていないインフラストラクチャとの接続に使用されます。したがって、ホストは通常、検証ポートに接続します。したがって、上記の図1では、SEND-SAVI1のポート1と2、SEND-SAVI2のポート1、およびSEND-SAVI3のポート4は、ホストに接続しているため検証ポートです。 SEND-SAVI4のポート4もホストH5に接続されているため、検証ポートです。
For a more detailed discussion on this, see Section 3.4.
この詳細については、セクション3.4を参照してください。
Multi-subnet links: In some cases, a given subnet may have several prefixes. This is supported by SEND SAVI as any port can support multiple prefixes.
マルチサブネットリンク：場合によっては、特定のサブネットに複数のプレフィックスが付いていることがあります。どのポートでも複数のプレフィックスをサポートできるため、これはSEND SAVIでサポートされています。
Multihomed hosts: A multihomed host is a host with multiple interfaces. The interaction between SEND SAVI and multihomed hosts is as follows. If the different interfaces of the host are assigned different IP addresses and packets sent from each interface and always carry the address assigned to that interface as the source address, then from the perspective of a SEND SAVI device, this is equivalent to two hosts with a single interface, each with an IP address. SEND SAVI supports this without additional considerations. If the different interfaces share the same IP address or if the interfaces have different addresses but the host sends packets using the address of one of the interfaces through any of the interfaces, then SEND SAVI does not directly support it. It would require either connecting at least one interface of the multihomed host to a Trusted port or manually configuring the SEND SAVI bindings to allow binding the address of the multihomed host to multiple anchors simultaneously.
マルチホームホスト：マルチホームホストは、複数のインターフェースを持つホストです。 SEND SAVIとマルチホームホスト間の相互作用は次のとおりです。ホストの異なるインターフェースに各IPアドレスと各インターフェースから送信されたパケットが割り当てられ、常にそのインターフェースに割り当てられたアドレスを送信元アドレスとして運ぶ場合、SEND SAVIデバイスの観点から、これはそれぞれがIPアドレスを持つ単一のインターフェース。 SEND SAVIは、追加の考慮事項なしでこれをサポートします。異なるインターフェースが同じIPアドレスを共有する場合、またはインターフェースに異なるアドレスがあるが、ホストがいずれかのインターフェースを介していずれかのインターフェースのアドレスを使用してパケットを送信する場合、SEND SAVIはそれを直接サポートしません。マルチホームホストの少なくとも1つのインターフェイスをトラステッドポートに接続するか、マルチホームホストのアドレスを複数のアンカーに同時にバインドできるようにSEND SAVIバインディングを手動で構成する必要があります。
Virtual switches: A hypervisor or a host operating system may perform bridging functions between virtual hosts running on the same machine. The hypervisor or host OS may in turn connect to a SEND SAVI system. This scenario is depicted in Figure 2, with two virtual machines, VM1 and VM2, connected through a virtual switch, VS1, to SEND SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and VM2 are configured as Validating.
仮想スイッチ：ハイパーバイザーまたはホストオペレーティングシステムは、同じマシン上で実行されている仮想ホスト間でブリッジ機能を実行できます。ハイパーバイザまたはホストOSがSEND SAVIシステムに接続する場合があります。このシナリオを図2に示します。2つの仮想マシンVM1とVM2が、仮想スイッチVS1を介してSEND SAVIデバイスSEND-SAVI1に接続されています。 VS1からVM1およびVM2への接続ポイントは、検証として構成されます。
Host1
+----------------+
| +---+ +---+ |
| |VM1| |VM2| |
| +---+ +---+ |
| | | |
| +-1-----2--+ |
| | VS1 | |
| +--3-------+ |
| | |
+----|-----------+
|
|
+--1-----2--+
| SEND- |
| SAVI1 |
+--3---4----+
| |
Figure 2: Virtual Switches Connected to the SEND SAVI Device
図2：SEND SAVIデバイスに接続された仮想スイッチ
In order to provide proper security against replay attacks, performing SEND SAVI filtering as close to untrusted hosts as possible (see Sections 3.4 and 5.1) is recommended. In this scenario, this objective can be achieved by enabling SEND SAVI validation in VS1. Ideally, VS1 could be integrated into the SEND SAVI protection perimeter if the hypervisor or host OS at Host1 can be trusted (even though VM1 and VM2 could not be trusted). To do so, both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, are configured as Trusted.
リプレイ攻撃に対して適切なセキュリティを提供するために、SEND SAVIフィルタリングを信頼できないホストのできるだけ近くで実行することをお勧めします（セクション3.4および5.1を参照）。このシナリオでは、VS1でSEND SAVI検証を有効にすることでこの目的を達成できます。理想的には、Host1のハイパーバイザーまたはホストOSを信頼できる場合（VM1とVM2を信頼できない場合でも）、VS1をSEND SAVI保護境界に統合できます。これを行うには、VS1でのSEND-SAVI1への接続と、SEND-SAVI1でのポート1の両方を信頼済みとして構成します。
If the administrator of the network does not trust VS1, port 1 of SEND-SAVI1 is configured as Validating, so that every address being used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The attachment point to the physical network at VS1 should be configured as Trusted if the host administrator knows that it is connected to a SEND SAVI device; in this case, VS1 relies on the infrastructure comprised by the physical SEND SAVI devices but not vice versa. Packets egressing from VM1 are validated twice: first at VS1 and then at SEND-SAVI1. Packets going in the reverse direction (from an external host to VM1) are validated once: when they first reach a SEND SAVI device. If the administrator of VS1 does not trust the physical switch to which it attaches, it can configure the attachment to SEND-SAVI1 as Validating. In Figure 2 above, this means that a packet going from another host to VM1 would be validated twice: once when entering the SEND SAVI perimeter formed by the physical devices and again when entering at VS1.
ネットワークの管理者がVS1を信頼しない場合、SEND-SAVI1のポート1はValidatingとして構成され、Host1で使用されているすべてのアドレスがSEND-SAVI1でSEND SAVIによって検証されます。ホスト管理者がSEND SAVIデバイスに接続されていることをホスト管理者が知っている場合は、VS1の物理ネットワークへの接続ポイントを信頼済みとして構成する必要があります。この場合、VS1は物理的なSEND SAVIデバイスで構成されるインフラストラクチャに依存しますが、その逆はありません。 VM1から出て行くパケットは2回検証されます：最初にVS1で、次にSEND-SAVI1で。逆方向（外部ホストからVM1へ）に送信されるパケットは、最初にSEND SAVIデバイスに到達したときに一度検証されます。 VS1の管理者が接続先の物理スイッチを信頼しない場合、SEND-SAVI1への接続を検証中として構成できます。上記の図2では、これは、別のホストからVM1に送信されるパケットが2回検証されることを意味します。物理デバイスによって形成されたSEND SAVI境界に入るときと、VS1に入るときです。
Untrusted routers: One can envision scenarios where routers are dynamically attached to a SEND SAVI network. A typical example would be a mobile phone connecting to a SEND SAVI switch where the mobile phone is acting as a router for other personal devices that are accessing the network through it. Regarding the validation of the source address performed in a SEND SAVI device, such an untrusted router does not seem to directly fall in the category of trusted infrastructure (if this was the case, it is likely that all devices would be trusted); hence, it cannot be connected to a Trusted port, and if it is connected to a Validating port, the SEND SAVI switch would discard all the packets containing an off-link source address coming from that device. Although the SEND SAVI device to which this router attaches could be configured to permit the transit of packets with source addresses belonging to the set of prefixes reachable through the untrusted router, such a mechanism is out of the scope of this document. As a result, the default mechanism described in this specification cannot be applied in such a scenario.
信頼されていないルーター：ルーターがSEND SAVIネットワークに動的に接続されているシナリオを想定できます。典型的な例は、携帯電話がSEND SAVIスイッチに接続し、携帯電話がそれを介してネットワークにアクセスしている他の個人用デバイスのルーターとして機能している場合です。 SEND SAVIデバイスで実行されるソースアドレスの検証に関して、このような信頼できないルーターは、信頼できるインフラストラクチャのカテゴリに直接該当しないようです（この場合、すべてのデバイスが信頼される可能性があります）。したがって、Trustedポートに接続することはできません。Validatingポートに接続されている場合、SEND SAVIスイッチは、そのデバイスからのオフリンクソースアドレスを含むすべてのパケットを破棄します。このルーターが接続するSEND SAVIデバイスは、信頼できないルーターを介して到達可能な一連のプレフィックスに属する送信元アドレスを持つパケットの通過を許可するように構成できますが、このようなメカニズムはこのドキュメントの範囲外です。その結果、この仕様で説明されているデフォルトのメカニズムは、このようなシナリオでは適用できません。
The following three data structures are defined for SEND SAVI operations.
次の3つのデータ構造は、SEND SAVI操作用に定義されています。
SEND SAVI Database: The SEND SAVI function relies on state information binding the source IPv6 address used in data packets to the port through which the legitimate node connects. Such information is stored in the SEND SAVI Database. The SEND SAVI Database is populated with the contents of validated SEND messages. Each entry contains the following information:
SEND SAVIデータベース：SEND SAVI機能は、データパケットで使用されるソースIPv6アドレスを、正当なノードが接続するポートにバインドする状態情報に依存しています。このような情報はSEND SAVIデータベースに保存されます。 SEND SAVIデータベースには、検証済みのSENDメッセージの内容が入力されます。各エントリには、次の情報が含まれています。
o IPv6 source address
o IPv6送信元アドレス
o Binding anchor: the port through which the packet was received
o バインディングアンカー：パケットが受信されたポート
o Lifetime
o 一生
o Status: TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, TESTING_VP'
o ステータス：TENTATIVE_DAD、TENTATIVE_NUD、VALID、TESTING_VP、TESTING_VP '
o Alternative binding anchor: the port from which a DAD_NSOL message or any data packet has been received while a different port was stored in the binding anchor for the address.
o 代替バインディングアンカー：別のポートがアドレスのバインディングアンカーに格納されているときに、DAD_NSOLメッセージまたはデータパケットが受信されたポート。
o Creation time: the value of the local clock when the entry was first created
o 作成時間：エントリが最初に作成されたときのローカルクロックの値
SEND SAVI Prefix List: SEND SAVI devices need to know which ones are the link prefixes in order to identify local and off-link traffic. A SEND SAVI device MUST support discovering this information from the Prefix Information option [RFC4861] with the L bit set of Router Advertisement (RADV) messages coming from Trusted ports, as described in Section 3.3.2. The list of prefixes MAY also be configured manually. This information is not specific to a given port. The SEND SAVI Prefix List contains one entry per prefix in use, as follows:
SEND SAVIプレフィックスリスト：SEND SAVIデバイスは、ローカルトラフィックとオフリンクトラフィックを識別するために、リンクプレフィックスがどれかを知る必要があります。 SEND SAVIデバイスは、セクション3.3.2で説明されているように、Trustedポートから送信されるルーターアドバタイズ（RADV）メッセージのLビットセットを使用して、プレフィックス情報オプション[RFC4861]からこの情報を検出する必要があります。プレフィックスのリストも手動で設定できます。この情報は、特定のポートに固有のものではありません。 SEND SAVIプレフィックスリストには、次のように、使用中のプレフィックスごとに1つのエントリが含まれています。
o Prefix: the prefix included in a Prefix Information option.
o プレフィックス：プレフィックス情報オプションに含まれるプレフィックス。
o Prefix lifetime: time in seconds that the prefix is valid. Initially set to the Valid Lifetime value of the Prefix Information option of a valid RADV message or set to a value of all 1 bits (0xffffffff), which represents infinity, if configured manually.
o プレフィックスの有効期間：プレフィックスが有効である時間（秒単位）。最初は、有効なRADVメッセージのPrefix InformationオプションのValid Lifetime値に設定するか、手動で設定した場合は、無限大を表すすべての1ビット（0xffffffff）の値に設定します。
When the SEND SAVI device boots, it MUST send a Router Solicitation (RSOL) message, which does not need to be secured if the unspecified address is used (see [RFC3971], Sections 5.1.1 and 5.2.1). The SAVI device SHOULD issue a RSOL message in case the prefix entry is about to expire.
SEND SAVIデバイスは起動時に、ルーター要請（RSOL）メッセージを送信する必要があります。これは、未指定アドレスが使用されている場合は保護する必要はありません（[RFC3971]、セクション5.1.1および5.2.1を参照）。 SAVIデバイスは、プレフィックスエントリがまもなく期限切れになる場合に備えて、RSOLメッセージを発行する必要があります（SHOULD）。
In order to perform the SEND SAVI operation, some basic parameters of the SEND SAVI device have to be configured. Since a SEND SAVI device operates as a SEND node to generate NUD_NSOL, RSOL, or Certification Path Solicitation (CPS) messages:
SEND SAVI操作を実行するには、SEND SAVIデバイスのいくつかの基本パラメーターを構成する必要があります。 SEND SAVIデバイスはSENDノードとして動作し、NUD_NSOL、RSOL、または証明書パス要請（CPS）メッセージを生成します。
o The SEND SAVI device MUST be configured with a valid CGA address. When the SEND SAVI device configures this address, it MUST behave as a regular SEND node, i.e., using secured NSOL messages to perform DAD, etc., in addition to fulfilling the requirements stated for regular IPv6 nodes [RFC6434].
o SEND SAVIデバイスは、有効なCGAアドレスで構成する必要があります。 SEND SAVIデバイスがこのアドレスを構成する場合、通常のSENDノードとして動作する必要があります。つまり、通常のIPv6ノード[RFC6434]に記載されている要件を満たすことに加えて、安全なNSOLメッセージを使用してDADなどを実行する必要があります。
o The SEND SAVI device MAY be configured with at least one trust anchor if it is configured to validate RADV messages (see Section 3.3.2). In this case, the SEND SAVI device MAY be configured with certification paths. The alternative is obtaining them by means of issuing Certification Path Solicitation messages, as detailed in the SEND specification [RFC3971].
o SEND SAVIデバイスは、RADVメッセージを検証するように構成されている場合（セクション3.3.2を参照）、少なくとも1つのトラストアンカーで構成できます（MAY）。この場合、SEND SAVIデバイスは認証パスを使用して構成できます。代替案は、SEND仕様[RFC3971]で詳述されているように、証明書パス要請メッセージを発行することによってそれらを取得することです。
In addition, the port role for each port of the SEND SAVI device MUST be configured. The guidelines for this configuration are specified in Section 3.4.
さらに、SEND SAVIデバイスの各ポートのポートロールを構成する必要があります。この構成のガイドラインは、セクション3.4で指定されています。
In this section, we describe how packets are processed by a SEND SAVI device. Behavior varies depending on if the packet belongs to local or transit traffic. This is determined by checking if the prefix of the source address is included in the SEND SAVI Prefix List or in the unspecified address (local traffic) or not included in the SEND SAVI Prefix List (transit traffic).
このセクションでは、SEND SAVIデバイスがパケットを処理する方法について説明します。動作は、パケットがローカルトラフィックに属するかトランジットトラフィックに属するかによって異なります。これは、送信元アドレスのプレフィックスがSEND SAVIプレフィックスリストまたは未指定アドレス（ローカルトラフィック）に含まれているか、SEND SAVIプレフィックスリスト（トランジットトラフィック）に含まれていないかを確認することによって決定されます。
Transit traffic processing occurs as follows:
トランジットトラフィック処理は次のように行われます。
o If the SEND SAVI device receives a transit traffic packet through a Trusted port, it forwards it without any SAVI processing.
o SEND SAVIデバイスがTrustedポート経由でトランジットトラフィックパケットを受信した場合、SAVI処理なしで転送します。
o If the SEND SAVI device receives a transit traffic packet through a Validating port, it discards the packet.
o SEND SAVIデバイスは、検証ポートを介してトランジットトラフィックパケットを受信すると、そのパケットを破棄します。
If the verification of the source address of a packet shows that it belongs to local traffic, this packet is processed using the state machine described in this section.
パケットの送信元アドレスの検証でローカルトラフィックに属していることが示されている場合、このパケットは、このセクションで説明するステートマシンを使用して処理されます。
For the rest of the section, the following assumptions hold:
このセクションの残りの部分では、次の仮定が当てはまります。
o When it is stated that a secured NUD_NSOL message is issued by a SEND SAVI device through a port P, it means that the SEND SAVI device generates a NUD_NSOL message, according to the Neighbor Unreachability Detection procedure described in [RFC4861], addressed to the IPv6 target address, which is the source address of the packet triggering the procedure. This message is secured by SEND as defined in [RFC3971]. The source address used for issuing the NUD_NSOL message is the source address of the SEND SAVI device. The message is sent only through port P.
o セキュリティで保護されたNUD_NSOLメッセージがポートPを介してSEND SAVIデバイスによって発行されると記載されている場合、[RFC4861]で説明されている近隣到達不能検出手順に従って、SEND SAVIデバイスがNUD_NSOLメッセージを生成することを意味します。ターゲットアドレス。これは、プロシージャをトリガーするパケットのソースアドレスです。このメッセージは、[RFC3971]で定義されているSENDによって保護されます。 NUD_NSOLメッセージの発行に使用されるソースアドレスは、SEND SAVIデバイスのソースアドレスです。メッセージはポートPを介してのみ送信されます。
o When it is stated that a validated NUD_NADV message is received by a SEND SAVI device, it means that a SEND secured NUD_NADV message has been received by the same port P through which the corresponding NUD_NSOL message was issued, and the NUD_NADV message has been validated according to [RFC3971] to prove ownership for the IPv6 address under consideration and to prove that it is a response for the previous NUD_NSOL message issued by the SEND SAVI device (containing the same nonce value as the NUD_NSOL message to which it answers).
o 検証済みのNUD_NADVメッセージがSEND SAVIデバイスによって受信されたと記載されている場合、SENDで保護されたNUD_NADVメッセージが、対応するNUD_NSOLメッセージが発行された同じポートPによって受信され、NUD_NADVメッセージが[RFC3971]に追加して、検討中のIPv6アドレスの所有権を証明し、それがSEND SAVIデバイスによって発行された以前のNUD_NSOLメッセージに対する応答であることを証明します（応答先のNUD_NSOLメッセージと同じナンス値を含みます）。
We use VP to refer to a Validating port and TP to refer to a Trusted port.
VPを使用して検証ポートを参照し、TPを使用して信頼ポートを参照します。
The state machine is defined for a binding of a given source IPv6 address in a given SEND SAVI device. In the transitions considered, packets described as inputs refer to the IPaddr IPv6 address associated to the state machine.
状態マシンは、特定のSEND SAVIデバイスの特定のソースIPv6アドレスのバインディングに対して定義されます。考慮される遷移では、入力として記述されたパケットは、状態マシンに関連付けられたIPaddr IPv6アドレスを参照します。
The possible states for a given IPaddr are NO_BIND, TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, and TESTING_VP'. The NO_BIND state represents that no binding exists for IPaddr; this is the state for all addresses unless a binding is explicitly created.
特定のIPaddrの可能な状態は、NO_BIND、TENTATIVE_DAD、TENTATIVE_NUD、VALID、TESTING_VP、およびTESTING_VP 'です。 NO_BIND状態は、IPaddrのバインディングが存在しないことを表します。これは、バインディングが明示的に作成されていない限り、すべてのアドレスの状態です。
The states can be classified into 'forwarding' states, i.e., states in which packets received from the port associated to the IPv6 address are forwarded, and 'non-forwarding' states, i.e., states in which packets different to the ones used for signaling are not forwarded. VALID, TENTATIVE_DAD, TESTING_VP, and TESTING_VP' are forwarding states, and NO_BIND and TENTATIVE_NUD are non-forwarding states.
状態は、「転送」状態、つまりIPv6アドレスに関連付けられたポートから受信したパケットが転送される状態と、「非転送」状態、つまりシグナリングに使用されるものとは異なるパケットが存在する状態に分類できます。転送されません。 VALID、TENTATIVE_DAD、TESTING_VP、およびTESTING_VP 'は転送状態であり、NO_BINDおよびTENTATIVE_NUDは非転送状態です。
The SEND SAVI device MUST join the Solicited Node Multicast group for all the addresses whose state is other than NO_BIND. This is needed to make sure that the SEND SAVI device receives DAD_NSOL messages issued for those addresses. Note that it may not be enough to relay on the Multicast Listener Discovery (MLD) messages being sent by the node attached to a Validating port for which a binding for the corresponding address exists, since the node may move and packets sent to that particular Solicited Node Multicast group may no longer be forwarded to the SEND SAVI device.
SEND SAVIデバイスは、状態がNO_BIND以外のすべてのアドレスの要請ノードマルチキャストグループに参加する必要があります。これは、SEND SAVIデバイスがそれらのアドレスに対して発行されたDAD_NSOLメッセージを確実に受信するために必要です。ノードは移動する可能性があり、パケットはその特定の要請に送信されるため、対応するアドレスのバインディングが存在する検証ポートに接続されたノードによって送信されるマルチキャストリスナーディスカバリ（MLD）メッセージをリレーするだけでは不十分な場合があります。ノードマルチキャストグループがSEND SAVIデバイスに転送されなくなった可能性があります。
In order to determine which traffic is on-link and off-link, the SEND SAVI device MUST support discovery of this information from the Prefix Information option with the L bit set of RADV messages. In this case, at least one router SHOULD be configured to advertise RADV messages containing a Prefix Information option with the prefixes that the untrusted nodes can use as source addresses, and the bit L set. An alternative to this is to manually configure the SEND SAVI Prefix List or restrict the use of link-local addresses.
オンリンクとオフリンクのトラフィックを判別するために、SEND SAVIデバイスは、RADVメッセージのLビットセットを使用して、プレフィックス情報オプションからのこの情報の検出をサポートする必要があります。この場合、少なくとも1つのルーターは、信頼できないノードが送信元アドレスとして使用できる接頭辞とビットLが設定された接頭辞情報オプションを含むRADVメッセージを通知するように構成する必要があります（SHOULD）。これに代わる方法は、SEND SAVIプレフィックスリストを手動で構成するか、リンクローカルアドレスの使用を制限することです。
SEND SAVI devices MUST discard RADV messages received from Validating ports. RADV messages are only accepted and processed when received through Trusted ports.
SEND SAVIデバイスは、検証ポートから受信したRADVメッセージを破棄する必要があります。 RADVメッセージは、信頼できるポートを介して受信された場合にのみ受け入れられ、処理されます。
SEND SAVI devices SHOULD NOT validate RADV messages to update the SEND SAVI Prefix List and forward them to other nodes. These messages can only be received from Trusted ports, and we assume that routers are trusted. Validating RADV messages would be required in any SEND SAVI device the node is traversing. Besides, hosts will validate this message before using the information it contains.
SEND SAVIデバイスは、RADVメッセージを検証してSEND SAVIプレフィックスリストを更新し、他のノードに転送するべきではありません（SHOULD NOT）。これらのメッセージはTrustedポートからのみ受信でき、ルーターは信頼されていると想定しています。 RADVメッセージの検証は、ノードがトラバースするすべてのSEND SAVIデバイスで必要になります。さらに、ホストは、含まれている情報を使用する前にこのメッセージを検証します。
In case SEND SAVI devices are configured to validate RADV messages, SEND SAVI devices SHOULD support the processing of validated Certification Path Advertisement (CPA) messages, sent in reply to CPS messages, to acquire certificates used to validate router messages; alternatively, it SHOULD be configured with a certification path.
SEND SAVIデバイスがRADVメッセージを検証するように構成されている場合、SEND SAVIデバイスは、ルーターメッセージの検証に使用される証明書を取得するために、CPSメッセージに応答して送信される検証済みの証明書パスアドバタイズ（CPA）メッセージの処理をサポートする必要があります。または、証明書パスを使用して構成する必要があります。
The state machine defined for the SEND SAVI operation adheres to the following design guidelines:
SEND SAVI操作用に定義されたステートマシンは、次の設計ガイドラインに準拠しています。
o The only events that trigger state changes from forwarding to non-forwarding states, and vice versa, are the reception of DAD_NSOL, DAD_NADV, and NUD_NADV or the expiration of a timer. The other possible input to consider is 'any other packet', which could generate changes to states belonging to the same forwarding or non-forwarding class as the original state. In other words, when 'any other packet' is received, the state cannot move from forwarding to non-forwarding, and vice versa. The reduced set of messages being able to trigger a change simplifies the processing at SEND SAVI devices.
o 状態を転送状態から非転送状態に、またはその逆にトリガーする唯一のイベントは、DAD_NSOL、DAD_NADV、およびNUD_NADVの受信、またはタイマーの期限切れです。考慮すべき他の可能な入力は「その他のパケット」であり、元の状態と同じ転送クラスまたは非転送クラスに属する状態への変更を生成する可能性があります。つまり、「その他のパケット」を受信すると、状態は転送から非転送に、またはその逆に移行できません。変更をトリガーできるメッセージの数が減るため、SEND SAVIデバイスでの処理が簡単になります。
o DAD_NADV and NUD_NADV are only processed when they are a response to a DAD_NSOL or a NUD_NSOL message.
o DAD_NADVとNUD_NADVは、DAD_NSOLまたはNUD_NSOLメッセージへの応答である場合にのみ処理されます。
o SEND SAVI devices MUST only use ND messages received through Validating ports if they are valid; otherwise, they discard them. SEND SAVI devices SHOULD assume that such messages received from Trusted ports have been validated by other SEND SAVI devices, or come from a trusted device such a router, so they SHOULD NOT attempt to validate them in order to reduce the processing load at the SEND SAVI device.
o SEND SAVIデバイスは、Validatingポートを介して受信したNDメッセージを、それらが有効な場合にのみ使用する必要があります。それ以外の場合は、それらを破棄します。 SEND SAVIデバイスは、Trustedポートから受信したそのようなメッセージが他のSEND SAVIデバイスによって検証されているか、ルーターなどの信頼できるデバイスから送信されていると想定する必要があるため、SEND SAVIでの処理負荷を軽減するために、それらを検証しようとしないでください。端末。
o The only messages the SEND SAVI device is required to generate specifically per each source IP address are MLD and NUD_NSOL messages. This also keeps the state machine simple.
o SEND SAVIデバイスが各ソースIPアドレスごとに具体的に生成する必要があるメッセージは、MLDおよびNUD_NSOLメッセージだけです。これにより、ステートマシンもシンプルになります。
o Well-behaved nodes are expected to initiate communication by sending secured DAD_NSOL messages. The SEND SAVI state machine is tailored to efficiently process these events. The reception of other packet types without receiving previously validated DAD_NSOL messages is assumed to be a consequence of bad-behaving nodes or infrequent events (such as packet loss, a change in the topology connecting the switches, etc.). While a binding will ultimately be created for nodes affected by such events, simplicity of the state machine is prioritized over any possible optimization for these cases.
o 正常に動作するノードは、保護されたDAD_NSOLメッセージを送信して通信を開始することが期待されています。 SEND SAVIステートマシンは、これらのイベントを効率的に処理するように調整されています。以前に検証されたDAD_NSOLメッセージを受信せずに他のパケットタイプを受信したのは、動作不良のノードまたはまれなイベント（パケット損失、スイッチを接続するトポロジーの変更など）の結果であると想定されます。バインディングは最終的にそのようなイベントの影響を受けるノードに対して作成されますが、これらの場合に可能なあらゆる最適化よりも状態マシンのシンプルさが優先されます。
o If a node has a configured address, and it can prove that it owns this address, the binding is preserved regardless of any indication that a binding for the same source address could be configured in other SEND SAVI devices. Bindings for the same source address in two or more SEND SAVI devices may occur due to several reasons, for example, when a host moves (the two bindings exist just for a short period of time) or when many nodes generate the same address and the DAD procedure has failed. In these infrequent cases, SEND SAVI preserves connectivity for the resulting bindings.
o ノードに構成済みのアドレスがあり、このアドレスを所有していることが証明できる場合、同じ送信元アドレスのバインディングが他のSEND SAVIデバイスで構成されている可能性があるという指示に関係なく、バインディングは保持されます。 2つ以上のSEND SAVIデバイスの同じソースアドレスのバインディングは、いくつかの理由で発生する可能性があります。たとえば、ホストが移動した（2つのバインディングが短期間しか存在しない）場合、または多くのノードが同じアドレスとDADプロシージャが失敗しました。これらのまれなケースでは、SEND SAVIは結果のバインディングの接続を保持します。
Next, we describe how different inputs are processed, depending on the state of the binding of the IP address 'IPaddr'. Note that every ND message is assumed to be validated according to the SEND specification.
次に、IPアドレス「IPaddr」のバインディングの状態に応じて、さまざまな入力がどのように処理されるかを説明します。すべてのNDメッセージは、SEND仕様に従って検証されると想定されていることに注意してください。
To facilitate the reader's understanding of the most relevant transitions of the SEND SAVI state machine, a simplified version, which does not contain every possible transition, is depicted in Figure 3:
SEND SAVIステートマシンの最も関連する遷移を読者が理解しやすいように、可能なすべての遷移を含まない簡略化されたバージョンを図3に示します。
+-------------+
| |
| TESTING_VP' |
| |
+-------------+
Timeout/VP=VP' | ^
| |
VP_NUD_NADV/- | | VP'_DAD_NSOL/
| | VP_NUD_NSOL
| |
v |
VP_DAD_NSOL/- +--------+
+------------- | |
| | VALID |< -------------------+
| +-------- >| | |
| | +--------+ |
| | ^ | |
| | VP_NUD_ | | Timeout, |
| | NADV/- | | TP_DAD_NSOL/VP_NUD_NSOL|
| | | v |
| | +------------+ |
| | | | |
| | | TESTING_VP | |
| | | | |
| | +------------+ |
| | | |
| | | Timeout/- |
| | VP*, | |
| | Timeout/- | VP_NUD_NADV/- |
v | | |
+---------------+ | +---------------+
| | | | |
| TENTATIVE_DAD | | | TENTATIVE_NUD |
| | | | |
+---------------+ | +---------------+
^ | | | ^
| | | Timeout/- | |
| | TP_DAD_NSOL, | | |
| | TP_DAD_NADV/- | | |
| | v | |
| | +---------+ | |
| +--------- >| |< -----+ |
| | NO_BIND | |
+--------------| |-----------------+
VP_DAD_NSOL/- +---------+ VP*/VP_NUD_NSOL
Figure 3: Simplified SEND SAVI State Machine
図3：簡略化されたSEND SAVIステートマシン
Each state transition is characterized by any of the events that may trigger the change and the message(s) generated as a result of this change. The meaning of some terms are referred next:
各状態遷移は、変更をトリガーする可能性のあるイベントと、この変更の結果として生成されたメッセージによって特徴付けられます。次に、いくつかの用語の意味について説明します。
o VP_DAD_NSOL as a triggering event means that a validated DAD_NSOL message has been received from the current BINDING_ANCHOR port VP.
o トリガーイベントとしてのVP_DAD_NSOLは、検証済みのDAD_NSOLメッセージが現在のBINDING_ANCHORポートVPから受信されたことを意味します。
o VP* means any packet (data packet) received from the current BINDING_ANCHOR port VP.
o VP *は、現在のBINDING_ANCHORポートVPから受信したパケット（データパケット）を意味します。
o TP_DAD_NSOL as a triggering event means that a DAD_NSOL message was received from a Trusted port.
o トリガーイベントとしてのTP_DAD_NSOLは、DAD_NSOLメッセージが信頼できるポートから受信されたことを意味します。
o - means that no message is sent. VP=VP' means that the BINDING_ANCHOR is set to VP'.
o -メッセージが送信されないことを意味します。 VP = VP 'は、BINDING_ANCHORがVP'に設定されていることを意味します。
The notation
表記
Timeout, TP_DAD_NSOL/VP_NUD_NSOL
タイムアウト、TP_DAD_NSOL / VP_NUD_NSOL
means that the transition is triggered by either a timeout expiration or the reception of a DAD_NSOL message from a Trusted port, and in addition to the transition, a NUD_NSOL message is sent through port VP.
これは、遷移がタイムアウトの期限切れか、信頼できるポートからのDAD_NSOLメッセージの受信によってトリガーされ、遷移に加えて、NUD_NSOLメッセージがポートVPを介して送信されることを意味します。
For the rest of the description, we assume the following:
以降の説明では、次のことを前提としています。
o When a validated message is required (i.e., a 'validated DAD_NSOL'), messages are check for validity in the considered switch according to [RFC3971], and messages not fulfilling these conditions are discarded.
o 検証されたメッセージが必要な場合（つまり、「検証されたDAD_NSOL」）、メッセージは、[RFC3971]に従って考慮されたスイッチで有効性がチェックされ、これらの条件を満たさないメッセージは破棄されます。
o When any SEND message is received from a validated port, the SEND SAVI SHOULD assume that the message has been validated by the SEND SAVI device through which the message accessed the SEND SAVI protection perimeter (unless the SEND SAVI perimeter has been breached), or the device generating it is trusted. In this case, the SAVI device does not perform any further validation. Performing validation for SEND messages received through a Trusted port may affect performance negatively.
o 検証済みのポートからSENDメッセージを受信した場合、SEND SAVIは、メッセージがSEND SAVI保護境界にアクセスしたSEND SAVIデバイスによって検証された（SEND SAVI境界に違反していない場合）、またはそれを生成するデバイスは信頼されています。この場合、SAVIデバイスはそれ以上の検証を行いません。 Trustedポートを介して受信したSENDメッセージの検証を実行すると、パフォーマンスに悪影響を及ぼす可能性があります。
NO_BIND
の＿びんＤ
When the node is in this state, there are no unresolved NUD_NSOL messages generated by SEND SAVI or DAD_NSOL propagated to any Validating port, so the only relevant inputs are DAD_NSOL messages coming either from a Validating port (VP) or Trusted port (TP), or any packet other than DAD_NSOL coming from a VP or TP. There are no timers configured for this state.
ノードがこの状態の場合、SEND SAVIまたはDAD_NSOLによって生成された未解決のNUD_NSOLメッセージは検証ポートに伝搬されないため、関連する入力は検証ポート（VP）または信頼ポート（TP）からのDAD_NSOLメッセージのみです。または、VPまたはTPからのDAD_NSOL以外のパケット。この状態に設定されたタイマーはありません。
Messages received from a Validating port:
検証ポートから受信したメッセージ：
o If a validated DAD_NSOL message is received from a Validating port VP, the SEND SAVI device forwards this message to all appropriate Trusted ports (the subset of Trusted ports that belong to the forwarding layer-2 topology, with the restrictions imposed by the MLD snooping mechanism, if applied). DAD_NSOL messages are not sent through any of the ports configured as Validating ports. The SEND SAVI device sets the LIFETIME to TENT_LT, stores all the information required for future validation of the corresponding DAD_NADV message (such as the nonce of the message), creates a new entry in the SEND SAVI Database for IPaddr, sets BINDING_ANCHOR to VP, and changes the state to TENTATIVE_DAD. Creation time is set to the current value of the local clock.
o 検証されたDAD_NSOLメッセージが検証ポートVPから受信された場合、SEND SAVIデバイスはこのメッセージをすべての適切な信頼ポート（転送レイヤー2トポロジに属する信頼ポートのサブセット、MLDスヌーピングメカニズムによる制限付き）に転送します（適用されている場合）。 DAD_NSOLメッセージは、検証ポートとして構成されたどのポートからも送信されません。 SEND SAVIデバイスは、LIFETIMEをTENT_LTに設定し、対応するDAD_NADVメッセージの今後の検証に必要なすべての情報（メッセージのナンスなど）を格納し、IPaddrのSEND SAVIデータベースに新しいエントリを作成し、BINDING_ANCHORをVPに設定します。状態をTENTATIVE_DADに変更します。作成時刻は、ローカルクロックの現在の値に設定されます。
Note that in this case, it is not possible to check address ownership by sending a NUD_NSOL because while the node is waiting for a possible DAD_NADV, its address is in tentative state and the node cannot respond to NSOL messages [RFC4862].
この場合、ノードが可能なDAD_NADVを待機している間、そのアドレスは一時的な状態にあり、ノードはNSOLメッセージ[RFC4862]に応答できないため、NUD_NSOLを送信してアドレスの所有権を確認することはできません。
o If any packet other than a DAD_NSOL is received through a Validating port VP, the SEND SAVI device issues a secured NUD_NSOL through port VP. The SEND SAVI device sets the LIFETIME to TENT_LT. The SEND SAVI device creates a new entry in the SEND SAVI Database for IPaddr, sets BINDING_ANCHOR to VP, and the state is changed to TENTATIVE_NUD. Creation time is set to the current value of the local clock. The SAVI device MAY discard the packet while the NUD procedure is being executed or MAY store it in order to send it if the next transitions are (strictly) TENTATIVE_NUD and then VALID.
o DAD_NSOL以外のパケットがValidatingポートVPを介して受信された場合、SEND SAVIデバイスはポートVPを介して保護されたNUD_NSOLを発行します。 SEND SAVIデバイスは、LIFETIMEをTENT_LTに設定します。 SEND SAVIデバイスは、IPaddrのSEND SAVIデータベースに新しいエントリを作成し、BINDING_ANCHORをVPに設定し、状態をTENTATIVE_NUDに変更します。作成時刻は、ローカルクロックの現在の値に設定されます。 SAVIデバイスは、NUDプロシージャの実行中にパケットを破棄するか、次の遷移が（厳密に）TENTATIVE_NUDで有効な場合に送信するためにパケットを保存する場合があります。
Messages received from a Trusted port:
Trustedポートから受信したメッセージ：
o If a DAD_NSOL message containing IPaddr as the target address is received through a Trusted port, it MUST NOT be forwarded through any of the Validating ports: it is sent through the proper Trusted ports. The state is not changed.
o ターゲットアドレスとしてIPaddrを含むDAD_NSOLメッセージが信頼できるポートを介して受信される場合、検証ポートのいずれかを介して転送してはなりません。適切な信頼できるポートを介して送信されます。状態は変化しません。
o Any packet other than a DAD_NSOL received from a Trusted port is forwarded to its destination. This packet is assumed to come from a SEND SAVI device that has securely validated the binding, according to the SEND SAVI rules (unless the SEND SAVI perimeter has been breached). The state is not changed.
o Trustedポートから受信したDAD_NSOL以外のパケットは、宛先に転送されます。このパケットは、SEND SAVIルールに従って（SEND SAVIの境界に違反していない限り）、バインディングを安全に検証したSEND SAVIデバイスから送信されたと想定されます。状態は変化しません。
TENTATIVE_DAD
TENTATIVE_DAD
To arrive at this state, the SEND SAVI device has received a validated DAD_NSOL coming from the BINDING_ANCHOR port, and it has forwarded it to the appropriate TPs. The relevant events occurring in this state are the reception of a DAD_NADV message from a TP, a DAD_NSOL message from the BINDING_ANCHOR port, other Validating port or TP, a data packet from the BINDING_ANCHOR port, and the expiration of the LIFETIME timer initiated when the DAD_NSOL was received at the BINDING_ANCHOR port.
この状態に到達するために、SEND SAVIデバイスは、BINDING_ANCHORポートからの有効なDAD_NSOLを受信し、適切なTPに転送しました。この状態で発生する関連イベントは、TPからのDAD_NADVメッセージの受信、BINDING_ANCHORポート、その他の検証ポートまたはTPからのDAD_NSOLメッセージ、BINDING_ANCHORポートからのデータパケット、およびLIFETIMEタイマーの期限切れです。 DAD_NSOLがBINDING_ANCHORポートで受信されました。
Messages received from a Trusted port:
Trustedポートから受信したメッセージ：
o The reception of a valid DAD_NADV message from a Trusted port indicates that the binding cannot be configured for the BINDING_ANCHOR port. The state is changed to NO_BIND, and the LIFETIME is cleared.
o Trustedポートからの有効なDAD_NADVメッセージの受信は、BINDING_ANCHORポートに対してバインディングを構成できないことを示しています。状態がNO_BINDに変更され、LIFETIMEがクリアされます。
o The reception of a valid DAD_NSOL from a Trusted port indicates that a node connected to another SEND SAVI device may be trying to configure the same address at the same time. The DAD_NSOL message is forwarded to the BINDING_ANCHOR port, so that the node at this port will not configure the address, as stated in [RFC4862]. The DAD_NSOL message is also forwarded to all appropriate Trusted ports. Then, the LIFETIME is cleared, and the state is changed to NO_BIND.
o Trustedポートからの有効なDAD_NSOLの受信は、別のSEND SAVIデバイスに接続されているノードが同時に同じアドレスを構成しようとしている可能性があることを示しています。 [RFC4862]で述べられているように、DAD_NSOLメッセージはBINDING_ANCHORポートに転送されるため、このポートのノードはアドレスを構成しません。 DAD_NSOLメッセージは、適切なすべての信頼できるポートにも転送されます。次に、LIFETIMEがクリアされ、状態がNO_BINDに変更されます。
o Any packet other than a validated DAD_NSOL or DAD_NADV received from a Trusted port is forwarded to its destination. This packet is assumed to come from a SEND SAVI device that has securely validated the binding, according to the SEND SAVI rules (unless the SEND SAVI perimeter has been breached). The state is not changed.
o Trustedポートから受信した、検証済みのDAD_NSOLまたはDAD_NADV以外のパケットは、宛先に転送されます。このパケットは、SEND SAVIルールに従って（SEND SAVIの境界に違反していない限り）、バインディングを安全に検証したSEND SAVIデバイスから送信されたと想定されます。状態は変化しません。
Messages received from a Validating port different from the BINDING_ANCHOR:
BINDING_ANCHORとは異なる検証ポートから受信したメッセージ：
o A validated DAD_NSOL is received from a Validating port VP' different from the BINDING_ANCHOR port. The reception of a valid DAD_NSOL from port VP' indicates that a node connected to VP' may be trying to configure the same address at the same time. The DAD_NSOL message is forwarded to the BINDING_ANCHOR port, so that the node at this port will not configure the address, as stated in [RFC4862]. The DAD_NSOL message is also forwarded to all appropriate Trusted ports. Then, the BINDING_ANCHOR is set to VP' (through which the DAD_NSOL message was received), the LIFETIME is set to TENT_LT, and the state remains in TENTATIVE_DAD.
o 検証されたDAD_NSOLは、BINDING_ANCHORポートとは異なる検証ポートVPから受信されます。ポートVP 'からの有効なDAD_NSOLの受信は、VP'に接続されているノードが同時に同じアドレスを構成しようとしている可能性があることを示しています。 [RFC4862]で述べられているように、DAD_NSOLメッセージはBINDING_ANCHORポートに転送されるため、このポートのノードはアドレスを構成しません。 DAD_NSOLメッセージは、適切なすべての信頼できるポートにも転送されます。次に、BINDING_ANCHORがVP '（DAD_NSOLメッセージの受信に使用）に設定され、LIFETIMEがTENT_LTに設定され、状態はTENTATIVE_DADのままになります。
o Any packet other than a validated DAD_NSOL received from a Validating port VP' different from the BINDING_ANCHOR port is discarded. The state is not changed.
o BINDING_ANCHORポートとは異なる検証ポートVPから受信した検証済みDAD_NSOL以外のパケットは破棄されます。状態は変化しません。
Messages received from the BINDING_ANCHOR port:
BINDING_ANCHORポートから受信したメッセージ：
o If a validated DAD_NSOL is received from the BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, and the state remains in TENTATIVE_DAD.
o 検証済みのDAD_NSOLがBINDING_ANCHORポートから受信されると、LIFETIMEはTENT_LTに設定され、状態はTENTATIVE_DADのままになります。
o If any packet other than a DAD_NSOL is received from the BINDING_ANCHOR port, it is assumed that the node has configured its address, although it has done it in less time than expected by the SEND SAVI device (less than TENT_LT). Since the node proved address ownership by means of the validated DAD_NSOL message, the LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o DAD_NSOL以外のパケットがBINDING_ANCHORポートから受信された場合、SEND SAVIデバイスの予想よりも短い時間（TENT_LT未満）でノードがアドレスを構成したと見なされます。検証されたDAD_NSOLメッセージによってノードがアドレスの所有権を証明したため、LIFETIMEはDEFAULT_LTに設定され、状態はVALIDに変更されます。
LIFETIME expires:
LIFETIMEの有効期限：
o If LIFETIME expires, it is assumed that no other node has configured this address. Therefore, the Validating port VP (currently stored in the BINDING_ANCHOR) could be bound to this IPv6 address. The LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o LIFETIMEが期限切れになると、他のノードがこのアドレスを構成していないと見なされます。したがって、（現在BINDING_ANCHORに格納されている）検証ポートVPをこのIPv6アドレスにバインドできます。 LIFETIMEはDEFAULT_LTに設定され、状態はVALIDに変更されます。
VALID
有効
To arrive at this state, the SEND SAVI device has successfully validated address ownership and has created a binding for IPaddr. Relevant transitions for this state are triggered by the reception of DAD_NSOL from the BINDING_ANCHOR port, other Validating port or a TP, and any packet other than DAD_NSOL from a Validating port other than the BINDING_ANCHOR or a TP. The expiration of LIFETIME is also relevant to trigger a check for address ownership for the node at the BINDING_ANCHOR port.
この状態に到達するために、SEND SAVIデバイスはアドレスの所有権を正常に検証し、IPaddrのバインディングを作成しました。この状態に関連する遷移は、BINDING_ANCHORポート、他の検証ポートまたはTPからのDAD_NSOLの受信、およびBINDING_ANCHORまたはTP以外の検証ポートからのDAD_NSOL以外のパケットの受信によってトリガーされます。 LIFETIMEの有効期限は、BINDING_ANCHORポートでノードのアドレス所有権のチェックをトリガーするためにも関係します。
Messages received from the BINDING_ANCHOR port:
BINDING_ANCHORポートから受信したメッセージ：
o If a validated DAD_NSOL with IPaddr as a source address is received through the BINDING_ANCHOR port, it is forwarded to the appropriate Trusted ports. The LIFETIME is set to TENT_LT, and the state is changed to TENTATIVE_DAD.
o 送信元アドレスとしてIPaddrを使用して検証されたDAD_NSOLがBINDING_ANCHORポートを介して受信されると、適切なTrustedポートに転送されます。 LIFETIMEはTENT_LTに設定され、状態はTENTATIVE_DADに変更されます。
o Any packet other than a DAD_NSOL containing IPaddr as a source address arriving from the BINDING_ANCHOR port is forwarded appropriately. The state is not changed.
o BINDING_ANCHORポートから到着する送信元アドレスとしてIPaddrを含むDAD_NSOL以外のパケットは、適切に転送されます。状態は変化しません。
Messages received from a Trusted port:
Trustedポートから受信したメッセージ：
o If a DAD_NSOL with IPaddr as a source address is received through a Trusted port, the message is forwarded to VP. The LIFETIME is set to TENT_LT, a secured NUD_NSOL message is sent to IPaddr through VP, and the state is changed to TESTING_VP.
o IPaddrを送信元アドレスとするDAD_NSOLがTrustedポートを介して受信されると、メッセージはVPに転送されます。 LIFETIMEがTENT_LTに設定され、保護されたNUD_NSOLメッセージがVPを介してIPaddrに送信され、状態がTESTING_VPに変更されます。
o If any packet other than a DAD_NSOL with IPaddr as a source address is received through a Trusted port, the packet is forwarded to VP and to other appropriate Trusted ports. A secured NUD_NSOL is sent to the BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP.
o 送信元アドレスとしてIPaddrを使用するDAD_NSOL以外のパケットがTrustedポートを介して受信されると、そのパケットはVPおよび他の適切なTrustedポートに転送されます。保護されたNUD_NSOLがBINDING_ANCHORポートに送信され、LIFETIMEがTENT_LTに設定され、状態がTESTING_VPに変更されます。
Messages received from a Validating port different from the BINDING_ANCHOR:
BINDING_ANCHORとは異なる検証ポートから受信したメッセージ：
o If a validated DAD_NSOL packet with IPaddr as a source address is received through a Validating port VP' (a VP' different from the current BINDING ANCHOR), the message is forwarded to the BINDING_ANCHOR port. In addition, a secured NUD_NSOL is sent to the BINDING_ANCHOR port, the ALTERNATIVE BINDING ANCHOR is set to port VP' (for future use if the node at VP' is finally selected), the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP'.
o IPaddrをソースアドレスとして持つ検証済みのDAD_NSOLパケットが検証ポートVP '（現在のBINDING ANCHORとは異なるVP'）を介して受信されると、メッセージはBINDING_ANCHORポートに転送されます。さらに、セキュリティで保護されたNUD_NSOLがBINDING_ANCHORポートに送信され、ALTERNATIVE BINDING ANCHORがポートVP 'に設定され（VPのノードが最終的に選択された場合の将来の使用のため）、LIFETIMEがTENT_LTに設定され、状態が変更されますTESTING_VP 'に。
o If any packet other than a DAD_NSOL with IPaddr as a source address is received from a Validating port VP', different from the current BINDING_ANCHOR for this binding, VP, the packet is discarded. The SEND SAVI device MAY issue a secured NUD_NSOL through the BINDING_ANCHOR port, store VP' in the ALTERNATIVE BINDING ANCHOR for possible future use, set the LIFETIME to TENT_LT, and change the state to TESTING_VP'. An alternative to this behavior is that the SEND SAVI device MAY not do anything (in this case, the state would eventually change after a maximum DEFAULT_LT time; if the node at VP does not respond to a NUD_NSOL at TESTING_VP, the state is moved to NO_BIND). Then, a packet arriving from VP' would trigger a process that may end up with binding for the node connecting to VP'.
o IPaddrをソースアドレスとするDAD_NSOL以外のパケットが検証ポートVPから受信された場合、このバインディングの現在のBINDING_ANCHOR、VPとは異なり、パケットは破棄されます。 SEND SAVIデバイスは、BINDING_ANCHORポートを介して保護されたNUD_NSOLを発行し、将来の使用のためにVP 'をALTERNATIVE BINDING ANCHORに格納し、LIFETIMEをTENT_LTに設定し、状態をTESTING_VP'に変更する場合があります。この動作の代わりに、SEND SAVIデバイスは何も実行しない場合があります（この場合、状態は最終的に最大DEFAULT_LT時間後に変化します。VPのノードがTESTING_VPのNUD_NSOLに応答しない場合、状態はNO_BIND）。次に、VP 'から到着するパケットは、VP'に接続しているノードのバインディングで終わる可能性のあるプロセスをトリガーします。
LIFETIME expires:
LIFETIMEの有効期限：
o If LIFETIME expires, a secured NUD_NSOL message is sent through the BINDING_ANCHOR port to IPaddr, the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP. In the TESTING_VP state, packets are still being forwarded until the timer expires without receiving a NUD_NADV.
o LIFETIMEが期限切れになると、保護されたNUD_NSOLメッセージがBINDING_ANCHORポートを介してIPaddrに送信され、LIFETIMEがTENT_LTに設定され、状態がTESTING_VPに変更されます。 TESTING_VP状態では、NUD_NADVを受信せずにタイマーが期限切れになるまで、パケットは引き続き転送されます。
TESTING_VP
TESTING_VP
When the SEND SAVI device enters the TESTING_VP state, the current Validating port is under check through a secured NUD_NSOL message generated by the SEND SAVI device. While testing, packets from the current Validating port are forwarded. Packets coming from Trusted ports are also forwarded. The relevant events for this state are the reception of a NUD_NADV message from VP; the reception of a DAD_NSOL message from VP, VP', or TP; the reception of any packet other than the previous cases from VP, VP', or TP; and the expiration of the timer associated to the reception of NUD_NADV.
SEND SAVIデバイスがTESTING_VP状態になると、SEND SAVIデバイスによって生成された保護されたNUD_NSOLメッセージによって、現在の検証ポートがチェックされます。テスト中、現在の検証ポートからのパケットが転送されます。 Trustedポートからのパケットも転送されます。この状態に関連するイベントは、VPからのNUD_NADVメッセージの受信です。 VP、VP '、またはTPからのDAD_NSOLメッセージの受信。 VP、VP '、またはTPからの前のケース以外のパケットの受信。 NUD_NADVの受信に関連するタイマーの期限切れ。
Messages received from the BINDING_ANCHOR port:
BINDING_ANCHORポートから受信したメッセージ：
o If a validated NUD_NADV is received from VP, the LIFETIME is changed to DEFAULT_LT, and the state is changed to VALID. The message is not forwarded to any other port.
o 検証されたNUD_NADVがVPから受信されると、LIFETIMEはDEFAULT_LTに変更され、状態はVALIDに変更されます。メッセージは他のどのポートにも転送されません。
o If a validated DAD_NSOL message is received from VP, it is forwarded to the appropriate Trusted ports, the LIFETIME is set to DEFAULT_LT, and the state is changed to TENTATIVE_DAD.
o 検証されたDAD_NSOLメッセージがVPから受信されると、適切なTrustedポートに転送され、LIFETIMEがDEFAULT_LTに設定され、状態がTENTATIVE_DADに変更されます。
o Any packet other than DAD_NSOL or NUD_NADV containing IPaddr as a source address arriving from the BINDING_ANCHOR port is forwarded. Neither the LIFETIME nor the state are changed.
o BINDING_ANCHORポートから到着する送信元アドレスとしてIPaddrを含むDAD_NSOLまたはNUD_NADV以外のすべてのパケットが転送されます。 LIFETIMEも状態も変更されません。
Messages received from a Trusted port:
Trustedポートから受信したメッセージ：
o If a DAD_NSOL packet is received from a Trusted port, the message is forwarded to VP and the appropriate Trusted ports. Neither the LIFETIME nor the state are changed. The node at the BINDING_ANCHOR port is under check; if it still is at this port, it should answer with a NUD_NADV and also with a DAD_NADV. If it is not there, neither the NUD_NADV nor the DAD_NADV will be received, the timer will expire, and the local state will move to NO_BIND.
o DAD_NSOLパケットが信頼できるポートから受信された場合、メッセージはVPおよび適切な信頼できるポートに転送されます。 LIFETIMEも状態も変更されません。 BINDING_ANCHORポートのノードはチェック中です。それがまだこのポートにある場合は、NUD_NADVとDAD_NADVで応答する必要があります。そこにない場合、NUD_NADVもDAD_NADVも受信されず、タイマーが期限切れになり、ローカル状態がNO_BINDに移行します。
o If a packet other than a DAD_NSOL arrives from a Trusted port, the packet is forwarded. Neither the LIFETIME nor the state are changed.
o DAD_NSOL以外のパケットがTrustedポートから到着した場合、そのパケットは転送されます。 LIFETIMEも状態も変更されません。
Messages received from a Validating port different from the BINDING_ANCHOR:
BINDING_ANCHORとは異なる検証ポートから受信したメッセージ：
o If a valid DAD_NSOL is received from a Validating port VP' other than the current BINDING_ANCHOR port, the message is forwarded to the BINDING_ANCHOR port and to the appropriate Trusted ports. In addition, a secured NUD_NSOL is sent to the BINDING_ANCHOR port, the ALTERNATIVE BINDING ANCHOR is set to VP' (for future use if the node at VP' is finally selected), the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP'.
o 現在のBINDING_ANCHORポート以外の検証ポートVPから有効なDAD_NSOLを受信した場合、メッセージはBINDING_ANCHORポートと適切な信頼済みポートに転送されます。さらに、保護されたNUD_NSOLがBINDING_ANCHORポートに送信され、ALTERNATIVE BINDING ANCHORがVP '（VP'のノードが最終的に選択された場合の将来の使用のため）に設定され、LIFETIMEがTENT_LTに設定され、状態がTESTING_VP '。
o Any other packet received from a Validating port VP' other than the BINDING_ANCHOR port is discarded. This may occur because the node has moved but has not issued a DAD_NSOL or the DAD_NSOL message has been lost. The state will eventually move to NO_BIND, and then the packets sent from VP' will trigger the creation of the binding for VP'.
o BINDING_ANCHORポート以外の検証ポートVPから受信した他のパケットはすべて破棄されます。これは、ノードが移動したがDAD_NSOLを発行していないか、DAD_NSOLメッセージが失われたために発生する可能性があります。状態は最終的にNO_BINDに移行し、VP 'から送信されたパケットがVP'のバインディングの作成をトリガーします。
LIFETIME expires:
LIFETIMEの有効期限：
o If the LIFETIME expires, the LIFETIME is cleared and the state is changed to NO_BIND.
o LIFETIMEが期限切れになると、LIFETIMEはクリアされ、状態はNO_BINDに変更されます。
TESTING_VP'
TESTING_VP '
To arrive at this state, the SEND SAVI device has received an indication that a node at VP' different from the BINDING_ANCHOR port wants to send data with IPaddr as a source address and has occurred while a binding existed for VP. The port VP' that triggered the change of the state to TESTING_VP' was stored at the ALTERNATIVE_BINDING_ANCHOR, so that it can be retrieved if the node at VP' is determined as the legitimate owner of IPaddr. The SEND SAVI device has issued a NUD_NSOL to IPaddr through the BINDING_ANCHOR port. The relevant events that may occur in this case are the reception of a NUD_NADV from port VP (the BINDING_ANCHOR port); the reception of a DAD_NSOL from VP, VP', TP, and VP" (VP" different from VP and VP'); the reception of any other packet from VP, VP', TP, or VP"; and the expiration of the timer.
この状態に到達するために、SEND SAVIデバイスは、BINDING_ANCHORポートとは異なるVP 'のノードがIPaddrをソースアドレスとしてデータを送信することを望んでおり、VPのバインディングが存在する間に発生したという指示を受け取りました。状態のTESTING_VP 'への変更をトリガーしたポートVP'は、ALTERNATIVE_BINDING_ANCHORに格納されていたため、VP 'のノードがIPaddrの正当な所有者であると判断された場合に取得できます。 SEND SAVIデバイスは、BINDING_ANCHORポートを介してIPaddrにNUD_NSOLを発行しました。この場合に発生する可能性のある関連イベントは、ポートVP（BINDING_ANCHORポート）からのNUD_NADVの受信です。 VP、VP '、TP、およびVP "（VPおよびVP'とは異なるVP"）からのDAD_NSOLの受信。 VP、VP '、TP、またはVPからの他のパケットの受信、およびタイマーの期限切れ。
Messages received from the BINDING_ANCHOR port:
BINDING_ANCHORポートから受信したメッセージ：
o A validated NUD_NADV is received from the BINDING_ANCHOR port. The reception of a valid NUD_NADV indicates that the node at VP is defending its address. The BINDING_ANCHOR in use is kept, the LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o 検証されたNUD_NADVがBINDING_ANCHORポートから受信されます。有効なNUD_NADVの受信は、VPのノードがそのアドレスを防御していることを示します。使用中のBINDING_ANCHORは保持され、LIFETIMEはDEFAULT_LTに設定され、状態はVALIDに変更されます。
o If a valid DAD_NSOL is received from the BINDING_ANCHOR port, it is forwarded to VP' (the port stored in the ALTERNATIVE_BINDING_ANCHOR). The BINDING_ANCHOR in use is kept, the LIFETIME is set to TENT_LT, and the state is changed to TENTATIVE_DAD. When the DAD_NSOL message is received by the node at VP', the address will not be configured.
o 有効なDAD_NSOLがBINDING_ANCHORポートから受信されると、VP '（ALTERNATIVE_BINDING_ANCHORに格納されているポート）に転送されます。使用中のBINDING_ANCHORは保持され、LIFETIMEはTENT_LTに設定され、状態はTENTATIVE_DADに変更されます。 DAD_NSOLメッセージがVP 'のノードで受信されると、アドレスは構成されません。
o Any packet other than a validated DAD_NSOL, or a validated NUD_NADV coming from the BINDING_ANCHOR port, is forwarded, and the state is not changed.
o 検証済みのDAD_NSOLまたはBINDING_ANCHORポートからの検証済みのNUD_NADV以外のパケットは転送され、状態は変更されません。
Messages received from the ALTERNATIVE_BINDING_ANCHOR Validating port:
ALTERNATIVE_BINDING_ANCHOR検証ポートから受信したメッセージ：
o If a valid DAD_NSOL is received from the port stored in the ALTERNATIVE_BINDING_ANCHOR, it is forwarded to the BINDING_ANCHOR port. The BINDING_ANCHOR and the ALTERNATIVE BINDING ANCHOR are kept, the LIFETIME is set to DEFAULT_LT, and the state is not changed.
o 有効なDAD_NSOLがALTERNATIVE_BINDING_ANCHORに格納されているポートから受信されると、それはBINDING_ANCHORポートに転送されます。 BINDING_ANCHORとALTERNATIVE BINDING ANCHORは保持され、LIFETIMEはDEFAULT_LTに設定され、状態は変更されません。
o Any packet other than a validated DAD_NSOL coming from the ALTERNATIVE_BINDING_ANCHOR port is discarded, and the state is not changed.
o ALTERNATIVE_BINDING_ANCHORポートからの検証済みDAD_NSOL以外のパケットはすべて破棄され、状態は変更されません。
Messages received from a Validating port different from the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports:
BINDING_ANCHORおよびALTERNATIVE_BINDING_ANCHORポートとは異なるValidatingポートから受信したメッセージ：
o If a validated DAD_NSOL is received from port VP", different from BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports, it is forwarded to the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports. The node at the ALTERNATIVE BINDING ANCHOR port is expected to unconfigure its address if the message triggering the transition to this state was a DAD_NSOL message received from the ALTERNATIVE_BINDING_ANCHOR port (and not any other packet). The state remains in TESTING_VP', although VP" is stored in the ALTERNATIVE_BINDING_ANCHOR for future use if the node at VP" is finally selected. The LIFETIME is not changed.
o 検証済みのDAD_NSOLがポートVPから受信された場合、BINDING_ANCHORおよびALTERNATIVE_BINDING_ANCHORポートとは異なり、それはBINDING_ANCHORおよびALTERNATIVE_BINDING_ANCHORポートに転送されます。ALTERNATIVEBINDING ANCHORポートにあるノードは、メッセージのトリガーによりアドレスの設定を解除すると、アドレスの設定が解除されますこの状態になったのは、ALTERNATIVE_BINDING_ANCHORポートから受信したDAD_NSOLメッセージでした（他のパケットではありません）。状態はTESTING_VP 'に残りますが、VP "がALTERNATIVE_BINDING_ANCHORに格納され、後でVP"のノードが最終的に選択された場合に使用できます。LIFETIME変更されません。
o Any packet other than a validated DAD_NSOL received from port VP" is discarded and does not affect the state.
o ポートVPから受信した検証済みのDAD_NSOL以外のパケットは破棄され、状態には影響しません。
Messages received from a Trusted port:
Trustedポートから受信したメッセージ：
o If a DAD_NSOL is received from a Trusted port, the message is forwarded to the BINDING_ANCHOR, ALTERNATIVE_BINDING_ANCHOR ports, and other appropriate Trusted ports. The LIFETIME is left unchanged, and the state is changed to TESTING_VP. The node at the ALTERNATIVE_BINDING_ANCHOR port is expected to unconfigure its address if the packet triggering the transition to this state was a DAD_NSOL message received from the ALTERNATIVE_BINDING_ANCHOR port.
o DAD_NSOLがTrustedポートから受信されると、メッセージはBINDING_ANCHOR、ALTERNATIVE_BINDING_ANCHORポート、およびその他の適切なTrustedポートに転送されます。 LIFETIMEは変更されず、状態はTESTING_VPに変更されます。この状態への遷移をトリガーするパケットが、ALTERNATIVE_BINDING_ANCHORポートから受信したDAD_NSOLメッセージであった場合、ALTERNATIVE_BINDING_ANCHORポートのノードは、そのアドレスを構成解除すると予想されます。
o Any packet other than a DAD_NSOL coming from a Trusted port is forwarded appropriately, but the state is not changed.
o TrustedポートからのDAD_NSOL以外のパケットは適切に転送されますが、状態は変更されません。
LIFETIME expires:
LIFETIMEの有効期限：
o If LIFETIME expires, it is assumed that the node for which the binding existed is no longer connected through the BINDING_ANCHOR port. Therefore, the BINDING_ANCHOR is set to the ALTERNATIVE_BINDING_ANCHOR port value. The LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o LIFETIMEが期限切れになると、バインディングが存在していたノードがBINDING_ANCHORポートを介して接続されなくなったと見なされます。したがって、BINDING_ANCHORは、ALTERNATIVE_BINDING_ANCHORポート値に設定されます。 LIFETIMEはDEFAULT_LTに設定され、状態はVALIDに変更されます。
TENTATIVE_NUD
TENTATIVE_NUD
To arrive at this state, a data packet has been received through the BINDING_ANCHOR port without any existing binding in the SEND SAVI device. The SEND SAVI device has sent a NUD_NSOL message to the BINDING_ANCHOR port. The relevant events for this case are the reception of a NUD_NADV from the BINDING_ANCHOR port; the reception of a DAD_NSOL from the BINDING_ANCHOR port, other VP different from the BINDING_ANCHOR port, or a TP; and the reception of any packet other than a DAD_NSOL and a NUD_NADV from the BINDING_ANCHOR port and a DAD_NSOL for other VP different from the BINDING_ANCHOR port, or TP. In addition, the LIFETIME may expire.
この状態に到達するために、SEND SAVIデバイスに既存のバインディングがない状態で、BINDING_ANCHORポートを介してデータパケットが受信されました。 SEND SAVIデバイスがNUD_NSOLメッセージをBINDING_ANCHORポートに送信しました。このケースに関連するイベントは、BINDING_ANCHORポートからのNUD_NADVの受信です。 BINDING_ANCHORポート、BINDING_ANCHORポートとは異なる他のVP、またはTPからのDAD_NSOLの受信。 BINDING_ANCHORポートからのDAD_NSOLおよびNUD_NADV以外のパケットの受信、およびBINDING_ANCHORポートとは異なる他のVPのDAD_NSOL、またはTP。さらに、LIFETIMEが期限切れになる場合があります。
Messages received from the BINDING_ANCHOR port:
BINDING_ANCHORポートから受信したメッセージ：
o If a validated NUD_NADV message is received through the BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, and the state is changed to VALID. The message is not forwarded to any port.
o 検証されたNUD_NADVメッセージがBINDING_ANCHORポートを介して受信されると、LIFETIMEはTENT_LTに設定され、状態はVALIDに変更されます。メッセージはどのポートにも転送されません。
o If a validated DAD_NSOL message is received through the BINDING_ANCHOR port, it is forwarded to the appropriate Trusted ports, the LIFETIME is set to TENT_LT, and the state is changed to TENTATIVE_DAD.
o 検証済みのDAD_NSOLメッセージがBINDING_ANCHORポートを介して受信されると、適切なTrustedポートに転送され、LIFETIMEがTENT_LTに設定され、状態がTENTATIVE_DADに変更されます。
o Any packet other than NUD_NADV or DAD_NSOL received through the BINDING_ANCHOR port is discarded.
o BINDING_ANCHORポートを介して受信したNUD_NADVまたはDAD_NSOL以外のパケットはすべて破棄されます。
Messages received from a Validating port different from the BINDING_ANCHOR:
BINDING_ANCHORとは異なる検証ポートから受信したメッセージ：
o If a validated DAD_NSOL message is received through port VP' different from the BINDING_ANCHOR port, it is forwarded to the appropriate Trusted ports, the LIFETIME is set to TENT_LT, the BINDING_ANCHOR is set to VP', and the state is changed to TENTATIVE_DAD.
o 検証済みのDAD_NSOLメッセージが、BINDING_ANCHORポートとは異なるポートVP 'を介して受信されると、適切なTrustedポートに転送され、LIFETIMEがTENT_LTに設定され、BINDING_ANCHORがVP'に設定され、状態がTENTATIVE_DADに変更されます。
o Any packet other than validated DAD_NSOL received through port VP' MUST NOT be forwarded unless the next state for the binding is VALID. The packets received MAY be discarded or MAY be stored to be sent if the state changes later to VALID. The state is left unchanged.
o ポートVPを介して受信した検証済みDAD_NSOL以外のパケットは、バインディングの次の状態がVALIDでない限り、転送してはなりません（MUST NOT）。受信されたパケットは破棄されるか、状態が後でVALIDに変化した場合に送信するために保存される場合があります。状態は変更されません。
Messages received from a Trusted port:
Trustedポートから受信したメッセージ：
o If a DAD_NSOL message is received through a Trusted port, it is forwarded to the BINDING_ANCHOR port, and the state is left unchanged.
o DAD_NSOLメッセージがTrustedポートを介して受信されると、メッセージはBINDING_ANCHORポートに転送され、状態は変更されません。
o Any other packet received from a Trusted port is forwarded appropriately. This packet may come from a SEND SAVI device that has securely validated the attachment of the node to its Validating port, according to SEND SAVI rules. The state is left unchanged.
o Trustedポートから受信したその他のパケットは、適切に転送されます。このパケットは、SEND SAVIルールに従って、検証ポートへのノードの接続を安全に検証したSEND SAVIデバイスから送信された可能性があります。状態は変更されません。
LIFETIME expires:
LIFETIMEの有効期限：
o If LIFETIME expires, the LIFETIME is cleared and the state is changed to NO_BIND.
o LIFETIMEが期限切れになると、LIFETIMEはクリアされ、状態はNO_BINDに変更されます。
The detailed guidelines for port configuration in SEND SAVI devices are:
SEND SAVIデバイスでのポート構成の詳細なガイドラインは次のとおりです。
o Ports connected to another SEND SAVI device MUST be configured as Trusted ports. Not doing so will prevent off-link traffic from being forwarded, along with the following effects for on-link traffic: significantly increase the CPU time, memory consumption, and signaling traffic due to SEND SAVI validation, in both the SEND SAVI devices and the node whose address is being validated.
o 別のSEND SAVIデバイスに接続されているポートは、信頼できるポートとして構成する必要があります。そうしないと、オフリンクトラフィックが転送されなくなり、オンリンクトラフィックに対する次の影響が生じます。SENDSAVI検証により、SEND SAVIデバイスとSEND SAVIデバイスの両方で、CPU時間、メモリ消費、シグナリングトラフィックが大幅に増加します。アドレスが検証されているノード。
o Ports connected to hosts SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with a spoofed source address.
o ホストに接続されたポートは、検証ポートとして構成する必要があります（SHOULD）。そうしないと、そのポートに接続されているホストは、スプーフィングされた送信元アドレスを持つパケットを送信できます。
o No more than one host SHOULD be connected to each port. Connecting more than one host to a port will allow hosts to generate packets with the same source address as the other hosts connected to the same port, and will allow replaying attacks to be performed as described in Section 5.1.
o 各ポートに接続できるホストは1つだけです。 1つのポートに複数のホストを接続すると、ホストは同じポートに接続された他のホストと同じ送信元アドレスを持つパケットを生成でき、セクション5.1で説明されているようにリプレイ攻撃を実行できます。
o Ports connected to routers MUST be configured as Trusted ports. Not doing so results in SEND SAVI devices discarding off-link traffic. Note that this means that since routers are connected through Trusted ports, they can generate traffic with any source address, even those belonging to the link.
o ルーターに接続されているポートは、信頼できるポートとして構成する必要があります。そうしないと、SEND SAVIデバイスがオフリンクトラフィックを破棄します。これは、ルーターが信頼できるポートを介して接続されているため、リンクに属しているものも含めて、任意の送信元アドレスでトラフィックを生成できることを意味します。
o Ports connected to a chain of one or more legacy switches that have other SEND SAVI devices but have no routers or hosts attached to them SHOULD be configured as Trusted ports. Not doing so will significantly increase the memory consumption in the SEND SAVI devices and increase the signaling traffic due to SEND SAVI validation.
o 他のSEND SAVIデバイスがあり、ルーターやホストが接続されていない1つ以上のレガシースイッチのチェーンに接続されているポートは、信頼できるポートとして構成する必要があります。そうしないと、SEND SAVIデバイスのメモリ消費が大幅に増加し、SEND SAVI検証のためにシグナリングトラフィックが増加します。
In the case where the SEND SAVI device is a switch that supports customer VLANs [IEEE.802-1Q.2005], the SEND SAVI specification MUST behave as if there was one SEND SAVI process per customer VLAN. The SEND SAVI process of each customer VLAN will store the binding information corresponding to the nodes attached to that particular customer VLAN.
SEND SAVIデバイスがカスタマーVLAN [IEEE.802-1Q.2005]をサポートするスイッチである場合、SEND SAVI仕様は、カスタマーVLANごとに1つのSEND SAVIプロセスがあるかのように動作する必要があります。各カスタマーVLANのSEND SAVIプロセスは、その特定のカスタマーVLANに接続されたノードに対応するバインディング情報を保存します。
TENT_LT is 500 milliseconds.
TENT_LTは500ミリ秒です。
DEFAULT_LT is 5 minutes.
DEFAULT_LTは5分です。
In this section, we include two cases that illustrate the behavior of
SEND SAVI, the change of the attachment port of a host, and the
attack of a malicious host. We use the topology depicted in
Figure 4.
+---+
| H |
+---+
|
|
+-1-----2-+ +-1-----2-+
| | | |
| SAVI1 | | SAVI2 |
| | | |
+-3-----4-+ +-3-----4-+
| |
-------------------
Figure 4: Reference SEND SAVI Topology for Protocol Walk-Through
図4：プロトコルウォークスルーの参照SEND SAVIトポロジ
There are two cases, depending on whether the host H moves to a different port on the same switch or to a different switch.
ホストHが同じスイッチの別のポートに移動するか、別のスイッチに移動するかによって、2つのケースがあります。
Host H is connected to port 1 of SAVI1 and moves to port 2 of the same switch. Before moving, the SEND SAVI state associated to IPH, the IP address of H, is:
ホストHはSAVI1のポート1に接続され、同じスイッチのポート2に移動します。移動する前のIPH（HのIPアドレス）に関連付けられているSEND SAVI状態は次のとおりです。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
In the general case, H issues a DAD_NSOL message for IPH when it is connected to a different port. When SAVI1 receives this message, it validates it and changes its state to:
一般的なケースでは、Hは別のポートに接続されているときにIPHに対してDAD_NSOLメッセージを発行します。 SAVI1はこのメッセージを受信すると、それを検証し、状態を次のように変更します。
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2,
TIMER=TENT_LT / SAVI2=NO_BIND
The DAD_NSOL message is propagated to port 1, because it is the current BINDING_ANCHOR, and the Trusted port 3; it is not propagated to Validating port 4. SAVI1 configures a timer for TENT_LT seconds. In addition, SAVI1 generates a NUD_NSOL and sends it through port 1. When SAVI2 receives this message through its Trusted port, it discards it and remains in the NO_BIND state.
DAD_NSOLメッセージは現在のBINDING_ANCHORであり、トラステッドポート3であるため、ポート1に伝播されます。検証ポート4には伝達されません。SAVI1はTENT_LT秒のタイマーを設定します。さらに、SAVI1はNUD_NSOLを生成し、ポート1経由で送信します。SAVI2がこのメッセージをTrustedポート経由で受信すると、SAVI2はそれを破棄し、NO_BIND状態のままになります。
SAVI1 waits for a NUD_NADV message to be received from port 1. Since there is no node attached to 1, there is no response for either of these messages. When TENT_LT expires at SAVI1, the state changes to:
SAVI1は、NUD_NADVメッセージがポート1から受信されるのを待ちます。1に接続されているノードがないため、これらのメッセージのいずれにも応答がありません。 TENT_LTがSAVI1で期限切れになると、状態は次のように変わります。
SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND
If the node moving does not issue a DAD_NSOL when it attaches to port 2, then SAVI1 will receive a data packet through this port. The data packet is discarded, SAVI1 issues a secured NUD_NSOL through port 1, and the state changes to TESTING_VP'.
移動するノードがポート2に接続するときにDAD_NSOLを発行しない場合、SAVI1はこのポートを介してデータパケットを受信します。データパケットは破棄され、SAVI1はポート1を介して保護されたNUD_NSOLを発行し、状態はTESTING_VP 'に変わります。
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2
TIMER=TENT_LT / SAVI2=NO_BIND
SAVI1 waits for a NUD_NADV message to be received from port 1. Since there is no node attached to 1, there is no response for neither of these messages. When TENT_LT expires at SAVI1, the state changes to:
SAVI1は、NUD_NADVメッセージがポート1から受信されるのを待ちます。1に接続されているノードがないため、これらのメッセージのどちらにも応答がありません。 TENT_LTがSAVI1で期限切れになると、状態は次のように変わります。
SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND
An alternative behavior allowed by the specification for the case in which the host does not issue a DAD_NSOL is that SAVI1 does nothing. In this case, after some time (bounded by DEFAULT_LT), the switch will change the state for IPH to TESTING_VP, check if H is still at port 1 (which it is not), and move the state to NO_BIND. Then, a packet arriving from port 2 would trigger a process that finishes with a VALID stated with BINDING_ANCHOR=2.
ホストがDAD_NSOLを発行しない場合の仕様で許可されている別の動作は、SAVI1が何もしないことです。この場合、しばらくすると（DEFAULT_LTによって制限されて）、スイッチはIPHの状態をTESTING_VPに変更し、Hがまだポート1（そうでない）にあるかどうかを確認し、状態をNO_BINDに移動します。次に、ポート2から到着するパケットは、BINDING_ANCHOR = 2で示されたVALIDで終了するプロセスをトリガーします。
Host H, connected to port 1 of SAVI1, moves to port 4 of SAVI2. Before moving, the SEND SAVI state associated to IPH, the IP address of H, is:
SAVI1のポート1に接続されているホストHは、SAVI2のポート4に移動します。移動する前のIPH（HのIPアドレス）に関連付けられているSEND SAVI状態は次のとおりです。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
If H issues a DAD_NSOL message for IPH when it connects to port 4 of SAVI2, the state is changed to:
HがSAVI2のポート4に接続するときにIPHに対してDAD_NSOLメッセージを発行すると、状態は次のように変更されます。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD,
BINDING_ANCHOR=4, TIMER=TENT_LT
The DAD_NSOL message is propagated only through the Trusted port of SAVI2. Then, SAVI1 changes its state as follows:
DAD_NSOLメッセージは、SAVI2のTrustedポートを介してのみ伝播されます。次に、SAVI1はその状態を次のように変更します。
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=TENTATIVE_DAD, BINDING_ANCHOR=4, TIMER=TENT_LT SAVI1 propagates the DAD_NSOL message to port 1. Since the only node that can answer with a secured DAD_NUD has moved, the timer at SAVI2 expires, and SAVI2 changes its state to VALID:
SAVI1 = TESTING_VP、BINDING_ANCHOR = 1、TIMER = TENT_LT / SAVI2 = TENTATIVE_DAD、BINDING_ANCHOR = 4、TIMER = TENT_LT SAVI1はDAD_NSOLメッセージをポート1に伝播します。保護されたDAD_NUDで応答できる唯一のノードが移動したため、SAVI2のタイマーが移動しました期限が切れ、SAVI2はその状態をVALIDに変更します。
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID,
BINDING_ANCHOR=4
Just a very short time after, the timer at SAVI1 expires, and the state changes to NO_BIND:
そのすぐ後、SAVI1のタイマーが期限切れになり、状態がNO_BINDに変わります。
SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4
If host H does not send a DAD_NSOL when it moves to SAVI2 but instead sends a data packet, SAVI2 changes its state to TENTATIVE_NUD:
ホストHがSAVI2に移動するときにDAD_NSOLを送信せず、代わりにデータパケットを送信する場合、SAVI2はその状態をTENTATIVE_NUDに変更します。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_NUD,
BINDING_ANCHOR=4, TIMER=TENT_LT
SAVI2 issues a secured NUD_NSOL through port 4. H is assumed to have the address configured (otherwise, it should not have generated a data packet), so it can respond with a NUD_NADV. When SAVI1 receives the NUD_NADV and validates it, the state is changed to VALID:
SAVI2は、ポート4を介して保護されたNUD_NSOLを発行します。Hはアドレスが構成されていると想定されます（そうでない場合、データパケットを生成してはなりません）。NUD_NADVで応答できます。 SAVI1がNUD_NADVを受信して検証すると、状態はVALIDに変更されます。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=VALID, BINDING_ANCHOR=4
After some time (bounded by DEFAULT_LT), the state in SAVI1 will expire, and SAVI1 will perform a check for host H:
しばらくすると（DEFAULT_LTによって制限されます）、SAVI1の状態が期限切れになり、SAVI1はホストHのチェックを実行します。
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID,
BINDING_ANCHOR=4
SAVI1 issues a NUD_NSOL through port 1 for IPH. No response is received in this case, so SAVI1 changes its state to NO_BIND:
SAVI1は、IPHのポート1を介してNUD_NSOLを発行します。この場合、応答は受信されないため、SAVI1はその状態をNO_BINDに変更します。
SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4
Host H is attached to the SEND SAVI infrastructure through port 1 of SAVI1. We consider that host M starts sending data packets using IPH (the IP address of H) as the source address, without issuing a DAD_NSOL (a similar analysis can be done for this case).
ホストHは、SAVI1のポート1を介してSEND SAVIインフラストラクチャに接続されています。ホストMは、DAD_NSOLを発行せずに、IPH（HのIPアドレス）をソースアドレスとしてデータパケットの送信を開始すると考えます（この場合も同様の分析を行うことができます）。
The initial state before the attack of M is:
Mの攻撃前の初期状態は次のとおりです。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND M attaches to port 2 of SAVI1 and starts sending data packets. When SAVI1 receives the data packet, the packet is discarded. SEND SAVI may issue a secured NUD_NSOL through port 1 and changes the state to:
SAVI1 = VALID、BINDING_ANCHOR = 1 / SAVI2 = NO_BIND MはSAVI1のポート2に接続し、データパケットの送信を開始します。 SAVI1がデータパケットを受信すると、パケットは破棄されます。 SEND SAVIは、ポート1を介して保護されたNUD_NSOLを発行し、状態を次のように変更します。
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2,
TIMER=TENT_LT / SAVI2=NO_BIND
Host H is still attached to port 1, so it receives the NUD_NSOL and responds with a secured NUD_NADV. SAVI1 receives this message, validates it, and changes its state again to:
ホストHは引き続きポート1に接続されているため、NUD_NSOLを受信し、保護されたNUD_NADVで応答します。 SAVI1はこのメッセージを受信して検証し、状態を再び次のように変更します。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
To prevent the drain of CPU resources in SAVI1, the processing of further packets received from port 2 may be rate-limited, as discussed in Section 5.2.
SAVI1でのCPUリソースの浪費を防ぐために、セクション5.2で説明するように、ポート2から受信した以降のパケットの処理はレート制限される場合があります。
An alternative to the previous behavior is that SAVI1 does nothing when node M starts sending packets from port 2. In this case, when the timer to renew the state triggers (this time it's bounded by DEFAULT_LT), SAVI1 moves the state to TESTING_VP, sends a NUD_NSOL through port 1, host H responds, and the state remains in VALID for BINDING_ANCHOR=1. In this way, communication of host H is also defended.
以前の動作の代替案は、ノードMがポート2からパケットの送信を開始したときにSAVI1が何もしないことです。この場合、状態を更新するタイマーがトリガーされると（今回はDEFAULT_LTによって制限されます）、SAVI1は状態をTESTING_VPに移動して送信します。ポート1経由のNUD_NSOL、ホストHが応答し、状態はBINDING_ANCHOR = 1の場合はVALIDのままです。このようにして、ホストHの通信も防御されます。
The initial state before the attack of M is:
Mの攻撃前の初期状態は次のとおりです。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
M attaches to port 2 of SAVI2 and starts sending data packets. When SAVI2 receives the data packet, it changes the state to:
MはSAVI2のポート2に接続し、データパケットの送信を開始します。 SAVI2はデータパケットを受信すると、状態を次のように変更します。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD,
BINDING_ANCHOR=2, TIMER=TENT_LT
SAVI2 issues a secured NUD_NSOL through port 2. Since M does not own the IPH CGA, it cannot respond to the message. When the timer expires, the state is moved back to:
SAVI2は、ポート2を介して保護されたNUD_NSOLを発行します。MはIPH CGAを所有していないため、メッセージに応答できません。タイマーが切れると、状態は次のように戻ります。
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
To prevent the drain of CPU resources in SAVI2, the processing of further packets received from port 2 may be rate-limited, as discussed in Section 5.2.
セクション5.2で説明するように、SAVI2でのCPUリソースの浪費を防ぐために、ポート2から受信した以降のパケットの処理はレート制限される場合があります。
SEND SAVI operates only with validated SEND messages to create bindings. Note that IPv6 packets generated by non-SEND nodes will be discarded by the first SEND SAVI device receiving it. Therefore, attackers cannot obtain any benefit by not using SEND. In order to perform address validation in a mixed scenario comprising SEND and non-SEND devices, a different solution is required, which should be addressed in another document.
SEND SAVIは、検証済みのSENDメッセージでのみ動作し、バインディングを作成します。非SENDノードによって生成されたIPv6パケットは、それを受信した最初のSEND SAVIデバイスによって破棄されることに注意してください。したがって、攻撃者はSENDを使用しないことで利益を得ることができません。 SENDデバイスと非SENDデバイスで構成される混合シナリオでアドレス検証を実行するには、別のドキュメントで対処する必要がある別のソリューションが必要です。
Nodes MUST NOT assume that all SEND messages received from a SEND SAVI device are validated, since these devices only validate the messages strictly required for SEND SAVI operation. Among the number of messages that are not validated by SEND SAVI, we can name NUD_NSOL messages generated by other nodes and its corresponding NUD_NADV responses, or RSOL messages.
これらのデバイスはSEND SAVI操作に厳密に必要なメッセージのみを検証するため、ノードはSEND SAVIデバイスから受信したすべてのSENDメッセージが検証されると想定してはなりません（MUST NOT）。 SEND SAVIによって検証されないメッセージの数の中で、他のノードによって生成されたNUD_NSOLメッセージとそれに対応するNUD_NADV応答、またはRSOLメッセージを指定できます。
SEND SAVI improves protection compared to conventional SAVI as a result of the increased ability of SEND nodes to prove address ownership.
SEND SAVIは、アドレスの所有権を証明するSENDノードの能力が向上した結果として、従来のSAVIと比較して保護を向上させます。
A critical security consideration regarding SEND SAVI deals with the need of proper configuration of the roles of the ports in a SEND SAVI deployment scenario. Regarding security, the main requirement is that ports defining the protected perimeter SHOULD be configured as Validating ports. Not doing so will allow an attacker to send packets using any source address, regardless of the bindings established in other SEND SAVI devices.
SEND SAVIに関する重要なセキュリティの考慮事項は、SEND SAVI展開シナリオでのポートの役割の適切な構成の必要性を扱います。セキュリティに関して、主な要件は、保護された境界を定義するポートを検証ポートとして構成する必要があります。そうしないと、他のSEND SAVIデバイスで確立されたバインディングに関係なく、攻撃者は任意の送信元アドレスを使用してパケットを送信できます。
One possible concern about SEND SAVI is its behavior when an attacker tries to forge the identity of a legitimate node by replaying SEND messages used by the SEND SAVI specification. An attacker could replay any of these messages to interfere with the SEND SAVI operation. For example, it could replay a DAD_NSOL message to abort the configuration of an address for a legitimate node and to gain the right to use the address for DEFAULT_LT seconds.
SEND SAVIに関して懸念される可能性の1つは、攻撃者がSEND SAVI仕様で使用されるSENDメッセージを再生して正当なノードのIDを偽造しようとしたときの動作です。攻撃者はこれらのメッセージを再生して、SEND SAVI操作を妨害する可能性があります。たとえば、DAD_NSOLメッセージを再生して、正当なノードのアドレスの構成を中止し、DEFAULT_LT秒間アドレスを使用する権利を取得できます。
We can analyze two different cases when considering SEND SAVI replay attacks:
SEND SAVIリプレイ攻撃を検討する場合、2つの異なるケースを分析できます。
o When the SEND message replayed is used to create or update binding information for SEND SAVI, since the port through which this message is received is key to the SEND SAVI operation. SEND SAVI creates and maintains bindings as a result of the reception of DAD_NSOL messages and of the exchange of NUD_NSOL/NUD_NADV messages.
o このメッセージが受信されるポートがSEND SAVI操作の鍵となるため、再生されたSENDメッセージを使用してSEND SAVIのバインディング情報を作成または更新する場合。 SEND SAVIは、DAD_NSOLメッセージの受信とNUD_NSOL / NUD_NADVメッセージの交換の結果として、バインディングを作成および維持します。
o When the SEND message replayed does not result in the update of binding information for SEND SAVI and, thus, is not related to the specific port through which it was received. Such situations are the reception of CPA messages containing certificates, and the processing of an RADV message coming from a Trusted port, which can be used in SEND SAVI to populate the SEND SAVI Prefix List. In these two cases, the security risks are equivalent to those of the SEND operation, i.e., we can consider that the information will not be changed by its legitimate sender for the time during which the SEND specification allows replaying (which depends on the values of TIMESTAMP_FUZZ and TIMESTAMP_DRIFT [RFC3971]).
o 再生されたSENDメッセージの結果、SEND SAVIのバインディング情報が更新されないため、受信された特定のポートに関連していない場合。このような状況は、証明書を含むCPAメッセージの受信、およびSEND SAVIで使用してSEND SAVIプレフィックスリストに入力できるTrustedポートからのRADVメッセージの処理です。これらの2つのケースでは、セキュリティリスクはSEND操作のセキュリティリスクと同等です。つまり、SEND仕様で再生が許可されている間は、正当な送信者によって情報が変更されないと見なすことができます（これは、 TIMESTAMP_FUZZおよびTIMESTAMP_DRIFT [RFC3971]）。
For replay of messages belonging to the second case, i.e., messages that do not result in changes in the SEND SAVI binding information, the security provided by SEND is sufficient. For the replay of messages belonging to the first case, DAD_NSOL and NUD_NSOL/NUD_NADV messages, protection results from the behavior of SEND SAVI, as specified in Section 3.3.2, which restricts the ports to which the messages involved in SEND SAVI binding updates are disseminated. SEND SAVI devices only forward these messages to ports for which a binding to the address being tested by the DAD_NSOL message existed. Therefore, it is not enough for an attacker to subscribe to a Solicited Node address to receive DAD_NSOL messages sent to that address, but the attacker needs to generate a valid DAD_NSOL message associated to the address for which the binding is being tested, which is deemed unfeasible [RFC3971].
2番目のケースに属するメッセージの再生、つまりSEND SAVIバインディング情報に変化をもたらさないメッセージの場合、SENDによって提供されるセキュリティで十分です。最初のケースに属するメッセージ、DAD_NSOLおよびNUD_NSOL / NUD_NADVメッセージの再生の場合、保護は、SEND SAVIバインディングの更新に関係するメッセージが送信されるポートを制限するセクション3.3.2で指定されているSEND SAVIの動作に起因します。普及した。 SEND SAVIデバイスは、DAD_NSOLメッセージによってテストされているアドレスへのバインディングが存在するポートにのみこれらのメッセージを転送します。したがって、攻撃者が要請ノードアドレスにサブスクライブして、そのアドレスに送信されたDAD_NSOLメッセージを受信するだけでは不十分ですが、攻撃者は、バインディングがテストされていると見なされるアドレスに関連付けられている有効なDAD_NSOLメッセージを生成する必要があります。実行不可能[RFC3971]。
The attacks against the SEND SAVI device basically consist of making the SEND SAVI device consume its resources until it runs out of them. For instance, a possible attack would be to send packets with different source addresses, making the SEND SAVI device create state for each of the addresses and waste memory. At some point, the SEND SAVI device runs out of memory and needs to decide how to react. The result is that some form of garbage collection is needed to prune the entries. When the SEND SAVI device runs out of the memory allocated for the SEND SAVI Database, it is RECOMMENDED that it creates new entries by deleting the entries with a higher Creation time. This implies that older entries are preserved and newer entries overwrite each other. In an attack scenario where the attacker sends a batch of data packets with different source addresses, each new source address is likely to rewrite another source address created by the attack itself. It should be noted that entries are also garbage collected using the DEFAULT_LT, which is updated by NUD_NSOL/NUD_NADV exchanges. The result is that in order for an attacker to actually fill the SEND SAVI Database with false source addresses, it needs to continuously answer to NUD_NSOL for all the different source addresses, so that the entries grow old and compete with the legitimate entries. The result is that the cost of the attack is highly increased for the attacker.
SEND SAVIデバイスに対する攻撃は、基本的に、SEND SAVIデバイスが不足するまでリソースを消費させることで構成されます。たとえば、攻撃の可能性としては、送信元アドレスが異なるパケットを送信して、SEND SAVIデバイスに各アドレスの状態を作成させ、メモリを浪費させることが考えられます。ある時点で、SEND SAVIデバイスのメモリが不足し、対応方法を決定する必要があります。その結果、エントリをプルーニングするには、何らかの形のガベージコレクションが必要になります。 SEND SAVIデバイスがSEND SAVIデータベースに割り当てられたメモリを使い果たした場合は、作成時間が長いエントリを削除して新しいエントリを作成することをお勧めします。これは、古いエントリが保持され、新しいエントリが互いに上書きすることを意味します。攻撃者が異なる送信元アドレスでデータパケットのバッチを送信する攻撃シナリオでは、新しい送信元アドレスごとに、攻撃自体によって作成された別の送信元アドレスが書き換えられる可能性があります。エントリは、NUD_NSOL / NUD_NADV交換によって更新されるDEFAULT_LTを使用してガベージコレクションされることにも注意してください。その結果、攻撃者が実際にSEND SAVIデータベースに偽の送信元アドレスを入力するためには、すべての異なる送信元アドレスについてNUD_NSOLに継続的に応答し、エントリが古くなり、正当なエントリと競合する必要があります。その結果、攻撃者にとって攻撃のコストが大幅に増加します。
In addition, it is also RECOMMENDED that a SEND SAVI device reserves a minimum amount of memory for each available port (in the case where the port is used as part of the L2 anchor). The REQUIRED minimum is the memory needed to store four bindings associated to the port, although it SHOULD be raised if the ratio between the maximum number of bindings allowed in the device and the number of ports is high. The motivation for setting a minimum number of bindings per port is as follows. An attacker attached to a given port of a SEND SAVI device may attempt to launch a DoS attack towards the SEND SAVI device by creating many bindings for different addresses. It can do so by sending DAD_NSOL for different addresses. The result is that the attack will consume all the memory available in the SEND SAVI device. The above recommendation aims to reserve a minimum amount of memory per port, so that nodes located in different ports can make use of the reserved memory for their port even if a DoS attack is occurring in a different port.
さらに、SEND SAVIデバイスが使用可能なポートごとに最小量のメモリを予約することもお勧めします（ポートがL2アンカーの一部として使用される場合）。必須の最小値は、ポートに関連付けられた4つのバインディングを格納するために必要なメモリですが、デバイスで許可されているバインディングの最大数とポート数の比率が高い場合は増やす必要があります。ポートごとのバインディングの最小数を設定する動機は次のとおりです。 SEND SAVIデバイスの特定のポートに接続している攻撃者は、さまざまなアドレスに対して多くのバインディングを作成することにより、SEND SAVIデバイスに対してDoS攻撃を仕掛けようとする可能性があります。異なるアドレスにDAD_NSOLを送信することにより、これを行うことができます。その結果、攻撃はSEND SAVIデバイスで利用可能なすべてのメモリを消費します。上記の推奨事項は、ポートごとに最小量のメモリを予約することを目的としているため、異なるポートに配置されたノードは、DoS攻撃が別のポートで発生している場合でも、ポート用に予約されたメモリを利用できます。
The SEND SAVI device may store data packets while the address is being verified, for example, when a DAD_NSOL is lost before arriving to the SEND SAVI device to which the host attaches; when the host sends data packets, these data packets may be stored until the SEND SAVI device verifies the binding by means of a NUD packet exchange. In this case, the memory for data packet storage may also be a target of DoS attacks. A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions (such as being able to store new bindings) to have available memory even in the case of an attack, such as those described above.
SEND SAVIデバイスは、アドレスの検証中にデータパケットを保存する場合があります。たとえば、ホストが接続するSEND SAVIデバイスに到達する前にDAD_NSOLが失われた場合などです。ホストがデータパケットを送信するとき、これらのデータパケットは、SEND SAVIデバイスがNUDパケット交換によってバインディングを確認するまで保存されます。この場合、データパケットストレージ用のメモリもDoS攻撃の標的になる可能性があります。 SEND SAVIデバイスは、データパケットを格納するために使用されるメモリの量を制限する必要があります。これにより、上記のような攻撃の場合でも、他の機能（新しいバインディングを格納できるなど）が利用可能なメモリを使用できるようになります。
It is worth noting that the potential of DoS attacks against the SEND SAVI network is increased due to the use of costly cryptographic operations in order to validate the address of the nodes. An attacker could generate packets using new source addresses in order to make the closest SEND SAVI device spend CPU time to validate DAD_NSOL messages or to generate a secure NUD_NSOL. This attack can be used to drain CPU resources of SEND SAVI devices with a very low cost for the attacker. In order to solve this problem, rate-limiting the processing of packets that trigger SEND SAVI events SHOULD be enforced on a per-port basis.
ノードのアドレスを検証するためにコストのかかる暗号化操作を使用するため、SEND SAVIネットワークに対するDoS攻撃の可能性が高まることは注目に値します。攻撃者は、DAD_NSOLメッセージの検証または安全なNUD_NSOLの生成に最も近いSEND SAVIデバイスにCPU時間を費やすために、新しいソースアドレスを使用してパケットを生成する可能性があります。この攻撃は、攻撃者にとって非常に低いコストでSEND SAVIデバイスのCPUリソースを排出するために使用できます。この問題を解決するために、SEND SAVIイベントをトリガーするパケットの処理をレート制限することは、ポートごとに実施する必要があります。
The SEND specification [RFC3971] proposes two deployment models for trust anchors: either a centralized model relaying on a globally rooted public key infrastructure or a more local, decentralized deployment model in which end hosts are configured with a collection of public keys that are trusted only on a domain.
SEND仕様[RFC3971]は、トラストアンカーの2つの展開モデルを提案します。グローバルにルート化された公開キーインフラストラクチャを中継する集中型モデルか、エンドホストが信頼される公開キーのコレクションで構成されているよりローカルな分散型展開モデルです。ドメイン上。
The appeal of a centralized model is the possibility for hosts to use SEND to validate routers as they move through links belonging to different organizations without additional configuration. However, without any further protection, it also enables routers authorized with a certificate path rooted on a global trust anchor to appear as legitimate routers in a link in which they were not intended to act as such. This threat already existed for SEND deployments, for which links configured to accept centralized trust anchors may send outgoing traffic and use prefix information from alien routers. In a SEND SAVI deployment, such routers may be able to deliver off-link traffic to any node of the link.
集中型モデルの利点は、ホストがSENDを使用して、追加の構成なしで異なる組織に属するリンクを移動するときにルーターを検証できることです。ただし、これ以上の保護がなければ、グローバルトラストアンカーをルートとする証明書パスを使用して承認されたルーターが、そのように機能することを意図されていなかったリンクで正当なルーターとして表示されるようになります。この脅威は、SEND配置にすでに存在し、集中トラストアンカーを受け入れるように構成されたリンクが発信トラフィックを送信し、エイリアンルーターからのプレフィックス情報を使用する可能性があります。 SEND SAVI展開では、そのようなルーターはリンクの任意のノードにオフリンクトラフィックを配信できる場合があります。
In order to cope with this threat, SEND SAVI specifies that nodes are only allowed to behave as routers if they connect through Trusted ports. In particular, RADV messages and traffic with off-link source addresses are discarded when received through Validating ports, which are the ports intended for non-trusted infrastructure, as moving nodes. The protection provided by filtering RADV messages prevents SEND nodes from identifying alien routers as legitimate routers, even though the trust anchor of these routers is valid.
この脅威に対処するために、SEND SAVIは、ノードが信頼できるポートを介して接続する場合にのみ、ルーターとして動作することを許可することを指定しています。特に、RADVメッセージとオフリンクの送信元アドレスを持つトラフィックは、移動ノードとして信頼されていないインフラストラクチャ向けのポートである検証ポートを介して受信されると破棄されます。 RADVメッセージのフィルタリングによって提供される保護により、SENDノードは、これらのルーターのトラストアンカーが有効であっても、エイリアンルーターを正当なルーターとして識別できなくなります。
Besides, it is worth to say that SEND SAVI supports a decentralized deployment model.
また、SEND SAVIは分散型の展開モデルをサポートしていることは言うまでもありません。
SEND SAVI assumes that a host will be able to defend its address when the DAD procedure is executed for its addresses, and that it will answer to a NUD_NSOL with a NUD_NADV when required. This is needed, among other things, to support mobility within a link (i.e., to allow a host to detach and reconnect to a different layer-2 anchor of the same IP subnetwork, without changing its IP address). If the SEND SAVI device does not see the DAD_NADV or the NUD_NADV, it may grant the binding to a different binding anchor. This means that if an attacker manages to prevent a host from defending its source address, it will be able to destroy the existing binding and create a new one, with a different binding anchor. An attacker may do so, for example, by launching a DoS attack to the host that will prevent it to issue proper replies.
SEND SAVIは、ホストがそのアドレスに対してDADプロシージャが実行されたときにそのアドレスを防御できること、および必要に応じてNUD_NADVでNUD_NSOLに応答することを想定しています。これは特に、リンク内のモビリティをサポートするために必要です（つまり、ホストがIPアドレスを変更せずに、同じIPサブネットワークの異なるレイヤー2アンカーにデタッチして再接続できるようにするため）。 SEND SAVIデバイスがDAD_NADVまたはNUD_NADVを認識しない場合、別のバインディングアンカーへのバインディングを許可することがあります。つまり、攻撃者がホストの送信元アドレスの防御を防ぐことができた場合、既存のバインディングを破棄し、別のバインディングアンカーで新しいバインディングを作成することができます。攻撃者は、たとえば、ホストにDoS攻撃を仕掛けることにより、ホストが適切な応答を発行できないようにする可能性があります。
A SEND SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), except where there is an identified reason why that information is likely to be involved in the detection, prevention, or tracing of actual source address spoofing. Information about the majority of hosts that never spoof SHOULD NOT be logged.
SEND SAVIデバイスは、バインディングアンカー情報をできるだけ早く（つまり、指定されたアドレスの状態がNO_BINDに戻るとすぐに）削除する必要があります。ただし、その情報が検出に関与する可能性がある特定の理由がある場合を除きます。実際の送信元アドレスのスプーフィングの防止、またはトレース。なりすましを行わないホストの大部分に関する情報はログに記録すべきではありません。
Thanks to Jean-Michel Combes, Ana Kukec, Ted Lemon, Adrian Farrel, Barry Leiba, Brian Haberman, Vicent Roca, and Benoit Claise for their reviews and comments on this document. The text has also benefited from feedback provided by Tony Cheneau and Greg Daley.
このドキュメントに関するレビューとコメントを提供してくれたJean-Michel Combes、Ana Kukec、Ted Lemon、Adrian Farrel、Barry Leiba、Brian Haberman、Vicent Roca、Benoit Claiseに感謝します。このテキストは、Tony CheneauとGreg Daleyによって提供されたフィードバックからも恩恵を受けています。
Marcelo Bagnulo is partly funded by Trilogy 2, a research project supported by the European Commission under its Seventh Framework Program. Alberto Garcia-Martinez was supported, in part, by project TEC2012-38362-C03-01, granted by the Spanish Economy and Competitiveness Ministry.
Marcelo Bagnuloは、第7回フレームワークプログラムの下で欧州委員会が支援する研究プロジェクトであるTrilogy 2から資金提供を受けています。アルベルトガルシアマルティネスは、スペイン経済競争省から許可されたプロジェクトTEC2012-38362-C03-01によって部分的に支援されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、2005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[IEEE.802-1Q.2005] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks", IEEE Standard 802.1Q, May 2005.
[IEEE.802-1Q.2005] Institute of Electrical and Electronics Engineers、「IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks」、IEEE Standard 802.1Q、2005年5月。
[RFC2827] 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.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを利用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434] Jankiewicz、E.、Loughney、J。、およびT. Narten、「IPv6ノードの要件」、RFC 6434、2011年12月。
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012.
[RFC6620] Nordmark、E.、Bagnulo、M。、およびE. Levy-Abegnoli、「FCFS SAVI：First-Come、First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses」、RFC 6620、2012年5月。
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement (SAVI) Framework", RFC 7039, October 2013.
[RFC7039] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F。、およびC. Vogt、「Source Address Validation Improvement（SAVI）Framework」、RFC 7039、2013年10月。
Authors' Addresses
著者のアドレス
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
Marcelo Bagnulo Carlos IIIマドリード大学Av。Universidad 30 Leganes、Madrid 28911 Spain
Phone: 34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Alberto Garcia-Martinez Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
Alberto Garcia-Martinez Carlos IIIマドリッド大学Av。Universidad 30 Leganes、Madrid 28911 Spain
Phone: 34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es