[要約] RFC 6620は、ローカルに割り当てられたIPv6アドレスのソースアドレス検証の改善を目指したFCFS SAVI（First-Come, First-Served Source Address Validation Improvement）に関するものです。このRFCの目的は、ネットワーク内でのIPv6アドレスの不正使用を防ぐために、ソースアドレスの検証を改善することです。
Internet Engineering Task Force (IETF) E. Nordmark
Request for Comments: 6620 Cisco Systems
Category: Standards Track M. Bagnulo
ISSN: 2070-1721 UC3M
E. Levy-Abegnoli
Cisco Systems
May 2012
FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses
FCFS SAVI：ローカルに割り当てられたIPv6アドレスの先着順のソースアドレス検証の改善
Abstract
概要
This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing.
このメモは、FCFS原則を使用してIPv6ネットワークの送信元アドレス検証を提供するメカニズムである、先着順の送信元アドレス検証の改善（FCFS SAVI）について説明しています。提案されているメカニズムは、送信元アドレスのスプーフィングを検出および防止するための入力フィルタリング技術を補完することを目的としています。
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/rfc6620.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6620で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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に記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Background to FCFS SAVI .........................................4
2.1. Scope of FCFS SAVI .........................................4
2.2. Constraints for FCFS SAVI Design ...........................5
2.3. Address Ownership Proof ....................................5
2.4. Binding Anchor Considerations ..............................6
2.5. FCFS SAVI Protection Perimeter .............................6
2.6. Special Cases .............................................10
3. FCFS SAVI Specification ........................................11
3.1. FCFS SAVI Data Structures .................................12
3.2. FCFS SAVI Algorithm .......................................12
3.2.1. Discovering On-Link Prefixes .......................12
3.2.2. Processing of Transit Traffic ......................13
3.2.3. Processing of Local Traffic ........................13
3.2.4. FCFS SAVI Port Configuration Guidelines ............21
3.2.5. VLAN Support .......................................22
3.3. Default Protocol Values ...................................22
4. Security Considerations ........................................22
4.1. Denial-of-Service Attacks .................................22
4.2. Residual Threats ..........................................23
4.3. Privacy Considerations ....................................24
4.4. Interaction with Secure Neighbor Discovery ................25
5. Contributors ...................................................25
6. Acknowledgments ................................................25
7. References .....................................................26
7.1. Normative References ......................................26
7.2. Informative References ....................................26
Appendix A. Implications of Not Following the Recommended
Behavior .............................................28
A.1. Implications of Not Generating DAD_NS Packets upon the
Reception of Non-Compliant Data Packets ...................28
A.1.1. Lack of Binding State due to Packet Loss...............28
A.1.2. Lack of Binding State due to a Change in the
Topology ..............................................31
A.1.3. Lack of Binding State due to State Loss ...............31
A.2. Implications of Not Discarding Non-Compliant Data
Packets ...................................................35
This memo describes FCFS SAVI, a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. Section 2 gives the background and description of FCFS SAVI, and Section 3 specifies the FCFS SAVI protocol.
このメモは、FCFS原理を使用してIPv6ネットワークのソースアドレス検証を提供するメカニズムであるFCFS SAVIについて説明しています。提案されているメカニズムは、送信元アドレスのスプーフィングを検出および防止するための入力フィルタリング技術を補完することを目的としています。セクション2はFCFS SAVIの背景と説明を示し、セクション3はFCFS SAVIプロトコルを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The application scenario for FCFS SAVI is limited to the local link. Hence, the goal of FCFS SAVI is to verify that the source address of the packets generated by the hosts attached to the local link have not been spoofed.
FCFS SAVIのアプリケーションシナリオは、ローカルリンクに限定されています。したがって、FCFS SAVIの目的は、ローカルリンクに接続されたホストによって生成されたパケットの送信元アドレスがスプーフィングされていないことを確認することです。
In a link, hosts and routers are usually attached. Hosts generate packets with their own address as the source address. This is called "local traffic". Routers send packets containing a source IP address other than their own, since they are forwarding packets generated by other hosts (usually located in a different link). This is called "transit traffic".
リンクには、通常、ホストとルーターが接続されています。ホストは、送信元アドレスとして自身のアドレスを持つパケットを生成します。これは「ローカルトラフィック」と呼ばれます。ルーターは、他のホスト（通常は別のリンクにある）によって生成されたパケットを転送しているため、ルーターは自分以外のソースIPアドレスを含むパケットを送信します。これは「トランジットトラフィック」と呼ばれます。
The applicability of FCFS SAVI is limited to the local traffic, i.e., to verify if the traffic generated by the hosts attached to the local link contains a valid source address. The verification of the source address of the transit traffic is out of the scope of FCFS SAVI. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic. In that sense, FCFS SAVI complements ingress filtering, since it relies on ingress filtering to validate transit traffic, but it provides validation of local traffic, which is not provided by ingress filtering. Hence, the security level is increased by using these two techniques.
FCFS SAVIの適用範囲はローカルトラフィックに限定されます。つまり、ローカルリンクに接続されたホストによって生成されたトラフィックに有効な送信元アドレスが含まれているかどうかを確認します。トランジットトラフィックの送信元アドレスの検証は、FCFS SAVIの範囲外です。通過トラフィックの検証には、イングレスフィルタリング[RFC2827]などの他の手法が推奨されます。その意味で、FCFS SAVIは、通過トラフィックを検証するために入力フィルタリングに依存するため、入力フィルタリングを補完しますが、入力フィルタリングでは提供されないローカルトラフィックの検証を提供します。したがって、これら2つの手法を使用することにより、セキュリティレベルが向上します。
In addition, FCFS SAVI is designed to be used with locally assigned IPv6 addresses, in particular with IPv6 addresses configured through Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Manually configured IPv6 addresses can be supported by FCFS SAVI, but manual configuration of the binding on the FCFS SAVI device provides higher security and seems compatible with manual address management. FCFS SAVI can also be used with IPv6 addresses assigned via DHCPv6, since they ought to perform the Duplicate Address Detection (DAD) procedure, but there is a specific mechanism tailored for dealing with DHCP-assigned addresses defined in [SAVI-DHCP]. Additional considerations about how to use FCFS SAVI depending on the type of address management used and the nature of the addresses are discussed in the framework document [SAVI-FRAMEWORK].
さらに、FCFS SAVIはローカルに割り当てられたIPv6アドレス、特にステートレスアドレス自動構成（SLAAC）[RFC4862]で構成されたIPv6アドレスで使用するように設計されています。手動で構成されたIPv6アドレスはFCFS SAVIでサポートできますが、FCFS SAVIデバイスでのバインディングの手動構成はより高いセキュリティを提供し、手動アドレス管理と互換性があるようです。 FCFS SAVIは、重複アドレス検出（DAD）手順を実行する必要があるため、DHCPv6を介して割り当てられたIPv6アドレスでも使用できますが、[SAVI-DHCP]で定義されているDHCP割り当てアドレスを処理するために調整された特定のメカニズムがあります。使用されるアドレス管理のタイプとアドレスの性質に応じたFCFS SAVIの使用方法に関する追加の考慮事項は、フレームワークドキュメント[SAVI-FRAMEWORK]で説明されています。
FCFS SAVI is designed to be deployed in existing networks requiring a minimum set of changes. For that reason, FCFS SAVI does not require any changes in the host whose source address is to be verified. Any verification solely relies on the usage of already available protocols. That is, FCFS SAVI does not define a new protocol, define any new message on existing protocols, or require that a host use an existent protocol message in a different way. In other words, no host changes are required.
FCFS SAVIは、最小限の変更セットを必要とする既存のネットワークに配備されるように設計されています。そのため、FCFS SAVIでは、送信元アドレスを確認するホストに変更を加える必要はありません。検証は、すでに利用可能なプロトコルの使用にのみ依存しています。つまり、FCFS SAVIは新しいプロトコルを定義せず、既存のプロトコルで新しいメッセージを定義せず、ホストが既存のプロトコルメッセージを別の方法で使用することを要求します。つまり、ホストを変更する必要はありません。
FCFS SAVI validation is performed by the FCFS SAVI function. The function can be placed in different types of devices, including a router or a Layer 2 (L2) bridge. The basic idea is that the FCFS SAVI function is located in the points of the topology that can enforce the correct usage of the source address by dropping the non-compliant packets.
FCFS SAVI検証は、FCFS SAVI機能によって実行されます。この機能は、ルーターやレイヤー2（L2）ブリッジなど、さまざまなタイプのデバイスに配置できます。基本的な考え方は、FCFS SAVI機能は、非準拠パケットをドロップすることにより送信元アドレスの正しい使用を強制できるトポロジーのポイントにあるということです。
The main function performed by FCFS SAVI is to verify that the source address used in data packets actually belongs to the originator of the packet. Since the FCFS SAVI scope is limited to the local link, the originator of the packet is attached to the local link. In order to define a source address validation solution, we need to define the meaning of "address ownership", i.e., what it means that a given host owns a given address in the sense that the host is entitled to send packets with that source address. With that definition, we can define how a device can confirm that the source address in a datagram is owned by the originator of the datagram.
FCFS SAVIによって実行される主な機能は、データパケットで使用される送信元アドレスが実際にパケットの発信元に属していることを確認することです。 FCFS SAVIスコープはローカルリンクに限定されているため、パケットの発信元はローカルリンクに接続されます。送信元アドレス検証ソリューションを定義するには、「アドレス所有権」の意味、つまり、ホストがその送信元アドレスでパケットを送信する資格があるという意味で、特定のホストが特定のアドレスを所有しているという意味を定義する必要があります。 。その定義により、データグラムの送信元アドレスがデータグラムの発信者によって所有されていることをデバイスが確認する方法を定義できます。
In FCFS SAVI, proof of address ownership is based on the First-Come, First-Served principle. The first host that claims a given source address is the owner of the address until further notice. Since no host changes are acceptable, we need to find the means to confirm address ownership without requiring a new protocol. So, whenever a source address is used for the first time, a state is created in the device that is performing the FCFS SAVI function binding the source address to a binding anchor that consists of Layer 2 information that the FCFS SAVI box has available (e.g., the port in a switched LAN).
FCFS SAVIでは、アドレス所有権の証明は先着順の原則に基づいています。特定の送信元アドレスを要求する最初のホストは、追って通知があるまでアドレスの所有者です。ホストの変更は受け入れられないため、新しいプロトコルを必要とせずにアドレスの所有権を確認する手段を見つける必要があります。そのため、ソースアドレスが初めて使用されるときは常に、FCFS SAVIボックスが利用できるレイヤ2情報で構成されるバインディングアンカーにソースアドレスをバインドするFCFS SAVI機能を実行しているデバイスで状態が作成されます（たとえば、 、スイッチドLANのポート）。
Subsequent data packets containing that IP source address can be checked against the same binding anchor to confirm that the originator owns the source IP address.
そのIP送信元アドレスを含む後続のデータパケットを同じバインディングアンカーに対してチェックして、発信者が送信元IPアドレスを所有していることを確認できます。
There are, however, additional considerations to be taken into account. For instance, consider the case of a host that moves from one segment of a LAN to another segment of the same subnetwork and keeps the same IP address. In this case, the host is still the owner of the IP address, but the associated binding anchor may have changed. In order to cope with this case, the defined FCFS SAVI behavior implies verification of whether or not the host is still reachable using the previous binding anchor. In order to do that, FCFS SAVI uses the Neighbor Discovery (ND) protocol. If the host is no longer reachable at the previously recorded binding anchor, FCFS SAVI assumes that the new location is valid and creates a new binding using the new binding anchor. In case the host is still reachable using the previously recorded binding anchor, the packets coming from the new binding anchor are dropped.
ただし、考慮すべき追加の考慮事項があります。たとえば、LANの1つのセグメントから同じサブネットワークの別のセグメントに移動し、同じIPアドレスを保持するホストの場合を考えます。この場合、ホストは引き続きIPアドレスの所有者ですが、関連付けられているバインディングアンカーが変更されている可能性があります。このケースに対処するために、定義されたFCFS SAVI動作は、以前のバインディングアンカーを使用してホストがまだ到達可能かどうかの検証を意味します。そのために、FCFS SAVIはNeighbor Discovery（ND）プロトコルを使用します。以前に記録されたバインディングアンカーでホストに到達できなくなった場合、FCFS SAVIは新しい場所が有効であると見なし、新しいバインディングアンカーを使用して新しいバインディングを作成します。以前に記録されたバインディングアンカーを使用してホストにまだ到達できる場合、新しいバインディングアンカーからのパケットはドロップされます。
Note that this only applies to local traffic. Transit traffic generated by a router would be verified using alternative techniques, such as ingress filtering. FCFS SAVI checks would not be fulfilled by the transit traffic, since the router is not the owner of the source address contained in the packets.
これはローカルトラフィックにのみ適用されることに注意してください。ルータによって生成されたトランジットトラフィックは、イングレスフィルタリングなどの代替技術を使用して検証されます。ルーターはパケットに含まれる送信元アドレスの所有者ではないため、FCFS SAVIチェックはトランジットトラフィックでは実行されません。
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 FCFS SAVI device is configured to drop non-compliant packets, then the usage of FCFS SAVI may open a new vector of Denial-of-Service (DoS) attacks, based on spoofed binding anchors. For that reason, in this specification, only switch ports MUST be used as 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）アドレスなど）、結果のソリューションは脆弱になります。非準拠パケットの処理は、それに応じて調整する必要があります。特に、バインディングアンカーが簡単にスプーフィングされ、FCFS SAVIデバイスが非準拠パケットをドロップするように構成されている場合、FCFS SAVIの使用により、スプーフィングされたバインディングに基づいて、サービス拒否（DoS）攻撃の新しいベクトルが開かれる可能性があります。アンカー。そのため、この仕様では、バインディングアンカーとしてスイッチポートのみを使用する必要があります。その他の形式のバインディングアンカーはこの仕様の範囲外であり、それらを使用することの影響の適切な分析は、それらを使用する前に実行する必要があります。
FCFS SAVI provides perimetrical security. FCFS SAVI devices form what can be called an FCFS SAVI protection perimeter, and they verify that any packet that crosses the perimeter is compliant (i.e., the source address is validated). Once the packet is inside the perimeter, no further validations are performed on the packet. This model has implications both on how FCFS SAVI devices are deployed in the topology and on the configuration of the FCFS SAVI boxes.
FCFS SAVIは、周辺セキュリティを提供します。 FCFS SAVIデバイスは、FCFS SAVI保護境界と呼ばれるものを形成し、境界を通過するすべてのパケットが準拠している（つまり、送信元アドレスが検証されている）ことを確認します。パケットが境界の内側に入ると、それ以上の検証は行われません。このモデルは、トポロジでのFCFS SAVIデバイスの展開方法とFCFS SAVIボックスの構成の両方に影響を与えます。
The implication of this perimetrical security approach is that there is part of the topology that is inside the perimeter and part of the topology that is outside the perimeter. So, while packets coming from interfaces connected to the external part of the topology need to be validated by the FCFS SAVI device, packets coming from interfaces connected to the internal part of the topology do not need to be validated. This significantly reduces the processing requirements of the FCFS SAVI device. It also implies that each FCFS SAVI device that is part of the perimeter must be able to verify the source addresses of the packets coming from the interfaces connected to the external part of the perimeter. In order to do so, the FCFS SAVI device binds the source address to a binding anchor.
この周辺セキュリティアプローチの含意は、トポロジの一部が境界の内側にあり、トポロジの一部が境界の外側にあることです。したがって、トポロジの外部に接続されたインターフェイスからのパケットはFCFS SAVIデバイスによって検証される必要がありますが、トポロジの内部に接続されたインターフェイスからのパケットは検証する必要がありません。これにより、FCFS SAVIデバイスの処理要件が大幅に削減されます。また、境界の一部である各FCFS SAVIデバイスは、境界の外部に接続されているインターフェイスから送信されるパケットの送信元アドレスを確認できる必要があることも意味します。そのために、FCFS SAVIデバイスは送信元アドレスをバインディングアンカーにバインドします。
One possible approach would be for every FCFS SAVI device to store binding information about every source address in the subnetwork. In this case, every FCFS SAVI device would store a binding for each source address of the local link. The problem with this approach is that it imposes a significant memory burden on the FCFS SAVI devices. In order to reduce the memory requirements imposed on each device, the FCFS SAVI solution described in this specification distributes the storage of FCFS SAVI binding information among the multiple FCFS SAVI devices of a subnetwork. The FCFS SAVI binding state is distributed across the FCFS SAVI devices according to the following criterion: each FCFS SAVI device only stores binding information about the source addresses bound to anchors corresponding to the interfaces that connect to the part of the topology that is outside of the FCFS SAVI protection perimeter. Since all the untrusted packet sources are by definition in the external part of the perimeter, packets generated by each of the untrusted sources will reach the perimeter through an interface of an FCFS SAVI device. The binding information for that particular source address will be stored in the first FCFS SAVI device the packet reaches.
1つの可能なアプローチは、すべてのFCFS SAVIデバイスがサブネットワーク内のすべてのソースアドレスに関するバインディング情報を格納することです。この場合、すべてのFCFS SAVIデバイスは、ローカルリンクの各送信元アドレスのバインディングを保存します。このアプローチの問題は、FCFS SAVIデバイスにかなりのメモリ負荷がかかることです。各デバイスに課せられるメモリ要件を減らすために、この仕様で説明されているFCFS SAVIソリューションは、サブネットワークの複数のFCFS SAVIデバイス間でFCFS SAVIバインディング情報のストレージを分散します。 FCFS SAVIバインディング状態は、次の基準に従ってFCFS SAVIデバイス全体に分散されます。各FCFS SAVIデバイスは、トポロジの外部にあるトポロジの一部に接続するインターフェースに対応するアンカーにバインドされたソースアドレスに関するバインディング情報のみを保存しますFCFS SAVI保護境界。信頼できないパケットソースはすべて境界の外部にあるため、信頼できない各ソースによって生成されたパケットは、FCFS SAVIデバイスのインターフェイスを介して境界に到達します。その特定の送信元アドレスのバインディング情報は、パケットが到達する最初のFCFS SAVIデバイスに格納されます。
The result is that the FCFS SAVI binding information will be distributed across multiple devices. In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be coherent. In particular, it is important to avoid having the same source address bound to different binding anchors in different FCFS SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what FCFS SAVI is trying to prevent. In order to preserve the coherency of the FCFS SAVI bindings distributed among the FCFS SAVI devices within a realm, the Neighbor Discovery (ND) protocol [RFC4861] is used, in particular the Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages. Following is a simplified example of how this might work. Before creating an FCFS SAVI binding in the local FCFS SAVI database, the FCFS SAVI device will send an NS message querying for the address involved. Should any host reply to that message with an NA message, the FCFS SAVI device that sent the NS will infer that a binding for that address exists in another FCFS SAVI device and will not create a local binding for it. If no NA message is received as a reply to the NS, then the local FCFS SAVI device will infer that no binding for that address exists in other FCFS SAVI device and will create the local FCFS SAVI binding for that address.
その結果、FCFS SAVIバインディング情報が複数のデバイスに分散されます。適切な送信元アドレス検証を提供するために、異なるFCFS SAVIデバイス間で分散される情報が一貫していることが重要です。特に、同じソースアドレスが異なるFCFS SAVIデバイスの異なるバインディングアンカーにバインドされないようにすることが重要です。これが発生した場合は、2つのホストが同じ送信元アドレスでパケットを送信できることを意味します。これは、FCFS SAVIが防止しようとしていることです。レルム内のFCFS SAVIデバイス間で分散されるFCFS SAVIバインディングの一貫性を維持するために、ネイバーディスカバリ（ND）プロトコル[RFC4861]、特にネイバー要請（NS）およびネイバーアドバタイズ（NA）メッセージが使用されます。以下は、これがどのように機能するかを示す簡単な例です。ローカルFCFS SAVIデータベースにFCFS SAVIバインディングを作成する前に、FCFS SAVIデバイスは、関連するアドレスを照会するNSメッセージを送信します。ホストがNAメッセージでそのメッセージに応答した場合、NSを送信したFCFS SAVIデバイスは、そのアドレスのバインディングが別のFCFS SAVIデバイスに存在すると推測し、そのローカルバインディングを作成しません。 NSへの応答としてNAメッセージが受信されない場合、ローカルFCFS SAVIデバイスは、そのアドレスのバインディングが他のFCFS SAVIデバイスに存在しないと推測し、そのアドレスのローカルFCFS SAVIバインディングを作成します。
To summarize, the proposed FCFS SAVI approach relies on the following design choices:
要約すると、提案されているFCFS SAVIアプローチは、次の設計上の選択に依存しています。
o An FCFS SAVI provides perimetrical security, so some interfaces of an FCFS SAVI device will connect to the internal (trusted) part of the topology, and other interfaces will connect to the external (untrusted) part of the topology.
o FCFS SAVIは周辺セキュリティを提供するため、FCFS SAVIデバイスの一部のインターフェイスはトポロジの内部（信頼できる）部分に接続し、他のインターフェイスはトポロジの外部（信頼できない）部分に接続します。
o An FCFS SAVI device only verifies packets coming through an interface connected to the untrusted part of the topology.
o FCFS SAVIデバイスは、トポロジの信頼されていない部分に接続されているインターフェイスを介して送信されるパケットのみを検証します。
o An FCFS SAVI device only stores binding information for the source addresses that are bound to binding anchors that correspond to interfaces that connect to the untrusted part of the topology.
o FCFS SAVIデバイスは、トポロジの信頼できない部分に接続するインターフェイスに対応するバインディングアンカーにバインドされているソースアドレスのバインディング情報のみを保存します。
o An FCFS SAVI uses NS and NA messages to preserve the coherency of the FCFS SAVI binding state distributed among the FCFS SAVI devices within a realm.
o FCFS SAVIは、NSおよびNAメッセージを使用して、レルム内のFCFS SAVIデバイス間で分散されたFCFS SAVIバインディング状態の一貫性を維持します。
So, in a link that is constituted of multiple L2 devices, some of which are FCFS SAVI capable and some of which are not, the FCFS-SAVI-capable devices MUST be deployed forming a connected perimeter (i.e., no data packet can get inside the perimeter without passing through an FCFS SAVI device). Packets that cross the perimeter will be validated while packets that do not cross the perimeter are not validated (hence, FCFS SAVI protection is not provided for these packets). Consider the deployment of FCFS SAVI in the topology depicted in the following figure:
したがって、複数のL2デバイスで構成されるリンクでは、FCFS SAVI対応のデバイスとそうでないデバイスの両方で、接続された境界を形成してFCFS-SAVI対応のデバイスを配置する必要があります（つまり、データパケットが内部に入ることができません） FCFS SAVIデバイスを通過しない境界）境界を越えないパケットは検証されますが、境界を越えないパケットは検証されません（したがって、これらのパケットにはFCFS SAVI保護が提供されません）。次の図に示すトポロジでのFCFS SAVIの導入を検討してください。
+--------+
+--+ +--+ +--+ | +--+ |
|H1| |H2| |H3| | |R1| |
+--+ +--+ +--+ | +--+ |
| | | | | |
+-------------SAVI-PROTECTION-PERIMETER------+ | |
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3------+ |
| | | +--------------+ | |
| | +----------| |--------+ |
| | | SWITCH-A | |
| | +----------| |--------+ |
| | | +--------------+ | |
| +-1--2----+ +--1------+ |
| | SAVI3 | | SAVI4 | |
| +-3-----4-+ +----4----+ |
| | | | |
| +------SAVI-PROTECTION-PERIMETER---------------+
| | | | |
| +--+| +--+ +---------+
| |R2|| |H4| |SWITCH-B |
| +--+| +--+ +---------+
+------+ | |
+--+ +--+
|H5| |H6|
+--+ +--+
Figure 1: SAVI Protection Perimeter
図1：SAVI保護境界
In Figure 1, the FCFS SAVI protection perimeter is provided by four FCFS SAVI devices, namely SAVI1, SAVI2, SAVI3, and SAVI4. These devices verify the source address and filter packets accordingly.
図1では、FCFS SAVI保護境界は、4つのFCFS SAVIデバイス、つまりSAVI1、SAVI2、SAVI3、およびSAVI4によって提供されています。これらのデバイスは、送信元アドレスを確認し、それに応じてパケットをフィルタリングします。
FCFS SAVI devices then have two types of ports: Trusted Ports and Validating Ports.
FCFS SAVIデバイスには、信頼できるポートと検証ポートという2種類のポートがあります。
o Validating Ports (VPs) are those in which FCFS SAVI processing is performed. When a packet is received through one of the Validating Ports, FCFS SAVI processing and filtering will be executed.
o 検証ポート（VP）は、FCFS SAVI処理が実行されるポートです。検証ポートの1つを介してパケットを受信すると、FCFS SAVI処理とフィルタリングが実行されます。
o Trusted Ports (TPs) are those in which FCFS SAVI processing is not performed. So, packets received through Trusted Ports are not validated, and no FCFS SAVI processing is performed on them.
o トラステッドポート（TP）は、FCFS SAVI処理が実行されないポートです。そのため、信頼済みポートを介して受信されたパケットは検証されず、それらに対してFCFS SAVI処理は実行されません。
Trusted Ports are used for connections with trusted infrastructure, including the communication between FCFS SAVI devices, the communication with routers, and the communication of other switches that, while not FCFS SAVI devices, only connect to trusted infrastructure (i.e., other FCFS SAVI devices, routers, or other trusted nodes). So, in Figure 1, Port 3 of SAVI1 and Port 1 of SAVI3 are trusted because they connect two FCFS SAVI devices. Port 4 of SAVI1, Port 3 of SAVI2, Port 2 of SAVI3, and Port 1 of SAVI4 are trusted because they connect to SWITCH-A, to which only trusted nodes are connected. In Figure 1, Port 2 of SAVI2 and Port 3 of SAVI3 are Trusted Ports because they connect to routers.
信頼できるポートは、FCFS SAVIデバイス間の通信、ルーターとの通信、FCFS SAVIデバイスではないが信頼できるインフラストラクチャにのみ接続する他のスイッチ（つまり、他のFCFS SAVIデバイス、ルーター、またはその他の信頼されたノード）。したがって、図1では、SAVI1のポート3とSAVI3のポート1は、2つのFCFS SAVIデバイスを接続しているため、信頼されています。 SAVI1のポート4、SAVI2のポート3、SAVI3のポート2、SAVI4のポート1は、信頼されたノードのみが接続されているSWITCH-Aに接続されているため、信頼されています。図1では、SAVI2のポート2とSAVI3のポート3がルーターに接続されているため、これらは信頼できるポートです。
Validating Ports are used for connection with non-trusted infrastructure. In particular, hosts are normally connected to Validating Ports. Non-SAVI switches that are outside of the FCFS SAVI protection perimeter also are connected through Validating Ports. In particular, non-SAVI devices that connect directly to hosts or that have no SAVI-capable device between themselves and the hosts are connected through a Validating Port. So, in Figure 1, Ports 1 and 2 of SAVI1, Port 1 of SAVI2, and Port 4 of SAVI 3 are Validating Ports because they connect to hosts. Port 4 of SAVI4 is also a Validating Port because it is connected to SWITCH-B, which is a non-SAVI-capable switch that is connected to hosts H5 and H6.
検証ポートは、信頼されていないインフラストラクチャとの接続に使用されます。特に、ホストは通常、検証ポートに接続されています。 FCFS SAVI保護境界外にある非SAVIスイッチも、検証ポートを介して接続されます。特に、ホストに直接接続する、またはホストとの間にSAVI対応デバイスがないSAVI以外のデバイスは、検証ポートを介して接続されます。したがって、図1では、SAVI1のポート1と2、SAVI2のポート1、SAVI 3のポート4は、ホストに接続しているため検証ポートです。 SAVI4のポート4は、ホストH5およびH6に接続されているSAVI非対応スイッチであるSWITCH-Bに接続されているため、検証ポートでもあります。
Multi-subnet links: In some cases, a given subnet may have several prefixes. This is directly supported by SAVI as any port can support multiple prefixes. Forwarding of packets between different prefixes involving a router is even supported, as long as the router is connected to a Trusted Port, as recommended for all the routers.
マルチサブネットリンク：場合によっては、特定のサブネットに複数のプレフィックスが付いていることがあります。どのポートでも複数のプレフィックスをサポートできるため、これはSAVIによって直接サポートされます。すべてのルーターで推奨されているように、ルーターが信頼できるポートに接続されている限り、ルーターを含む異なるプレフィックス間のパケットの転送もサポートされます。
Multihomed hosts: A multihomed host is a host with multiple interfaces. The interaction between 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 always carry the address assigned to that interface as the source address, then from the perspective of a SAVI device, this is equivalent to two hosts with a single interface, each with an IP address. This is supported by SAVI without the need for 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 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 SAVI bindings to allow binding the address of the multihomed host to multiple anchors simultaneously.
マルチホームホスト：マルチホームホストは、複数のインターフェースを持つホストです。 SAVIとマルチホームホスト間の相互作用は次のとおりです。ホストの異なるインターフェースに異なるIPアドレスが割り当てられ、各インターフェースから送信されたパケットが常にそのインターフェースに割り当てられたアドレスをソースアドレスとして運ぶ場合、SAVIデバイスから見ると、これは単一のインターフェースを持つ2つのホストに相当します。 、それぞれにIPアドレスが付いています。これは、追加の考慮事項を必要とせずにSAVIによってサポートされます。異なるインターフェイスが同じIPアドレスを共有している場合、またはインターフェイスに異なるアドレスがあるが、ホストがいずれかのインターフェイスのいずれかのインターフェイスのアドレスを使用してパケットを送信する場合、SAVIは直接サポートしません。マルチホームホストの少なくとも1つのインターフェイスをトラステッドポートに接続するか、SAVIバインディングを手動で構成して、マルチホームホストのアドレスを複数のアンカーに同時にバインドできるようにする必要があります。
Untrusted routers: One can envision scenarios where routers are dynamically attached to an FCFS SAVI network. A typical example would be a mobile phone connecting to an FCFS SAVI switch where the mobile phone is acting as a router for other personal devices that are accessing the network through it. In this case, the 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 FCFS SAVI switch would discard all the packets containing an off-link source address coming from that device. As a result, the default recommendation specified in this specification does not support such a scenario.
信頼できないルーター：ルーターがFCFS SAVIネットワークに動的に接続されているシナリオを想定できます。典型的な例は、FCFS SAVIスイッチに接続している携帯電話で、携帯電話は、それを介してネットワークにアクセスしている他の個人用デバイスのルーターとして機能しています。この場合、ルーターは信頼できるインフラストラクチャのカテゴリに直接該当しないようです（その場合、すべてのデバイスが信頼される可能性があります）。そのため、信頼できるポートに接続できず、検証ポートに接続されている場合、FCFS SAVIスイッチは、そのデバイスからのオフリンクソースアドレスを含むすべてのパケットを破棄します。その結果、この仕様で指定されているデフォルトの推奨は、このようなシナリオをサポートしていません。
The FCFS SAVI function relies on state information binding the source address used in data packets to the binding anchor that contained the first packet that used that source IP address. Such information is stored in an FCFS SAVI database (DB). The FCFS SAVI DB will contain a set of entries about the currently used IP source addresses. Each entry will contain the following information:
FCFS SAVI機能は、データパケットで使用される送信元アドレスを、その送信元IPアドレスを使用した最初のパケットを含むバインディングアンカーにバインドする状態情報に依存しています。このような情報は、FCFS SAVIデータベース（DB）に格納されます。 FCFS SAVI DBには、現在使用されているIP送信元アドレスに関する一連のエントリが含まれます。各エントリには次の情報が含まれます。
o IP source address
o IPソースアドレス
o Binding anchor: port through which the packet was received
o バインディングアンカー：パケットが受信されたポート
o Lifetime
o 一生
o Status: either TENTATIVE, VALID, TESTING_VP, or TESTING_TP-LT
o ステータス：TENTATIVE、VALID、TESTING_VP、またはTESTING_TP-LT
o Creation time: the value of the local clock when the entry was firstly created
o 作成時間：エントリが最初に作成されたときのローカルクロックの値
In addition, FCFS SAVI needs to know what prefixes are directly connected, so it maintains a data structure called the FCFS SAVI Prefix List, which contains: o Prefix
さらに、FCFS SAVIは、どのプレフィックスが直接接続されているかを知る必要があるため、FCFS SAVIプレフィックスリストと呼ばれるデータ構造を維持します。
o Interface where prefix is directly connected
o 接頭辞が直接接続されているインターフェース
In order to distinguish local traffic from transit traffic, the FCFS SAVI device relies on the FCFS SAVI Prefix List, which contains the set of on-link IPv6 prefixes. An FCFS SAVI device MUST support the following two methods for populating the Prefix List: manual configuration and Router Advertisement, as detailed next.
ローカルトラフィックとトランジットトラフィックを区別するために、FCFS SAVIデバイスは、リンク上のIPv6プレフィックスのセットを含むFCFS SAVIプレフィックスリストに依存しています。 FCFS SAVIデバイスは、次に説明するように、手動構成とルーターアドバタイズメントの2つのプレフィックスリストの入力方法をサポートする必要があります。
Manual configuration: An FCFS SAVI device MUST support manual configuration of the on-link prefixes included in the Prefix List. For example, this can be used when there are no prefixes being advertised on the link.
手動構成：FCFS SAVIデバイスは、プレフィックスリストに含まれるオンリンクプレフィックスの手動構成をサポートする必要があります。たとえば、リンク上でアドバタイズされているプレフィックスがない場合に使用できます。
Router Advertisement: An FCFS SAVI device MUST support discovery of on-link prefixes through Router Advertisement messages in Trusted Ports. For Trusted Ports, the FCFS SAVI device will learn the on-link prefixes following the procedure defined for a host to process the Prefix Information options described in Section 6.3.4 of [RFC4861] with the difference that the prefixes will be configured in the FCFS SAVI Prefix List rather than in the ND Prefix List. In addition, when the FCFS SAVI device boots, it MUST send a Router Solicitation message as described in Section 6.3.7 of [RFC4861], using the unspecified source address.
ルーターアドバタイズメント：FCFS SAVIデバイスは、信頼できるポートのルーターアドバタイズメントメッセージを介したオンリンクプレフィックスの検出をサポートする必要があります。トラステッドポートの場合、FCFS SAVIデバイスは、[RFC4861]のセクション6.3.4で説明されているプレフィックス情報オプションをホストが処理するように定義された手順に従って、リンク上のプレフィックスを学習しますが、FCFSでプレフィックスが構成される点が異なります。 NDプレフィックスリストではなくSAVIプレフィックスリスト。さらに、FCFS SAVIデバイスは起動時に、[RFC4861]のセクション6.3.7で説明されているように、未指定の送信元アドレスを使用してルーター要請メッセージを送信する必要があります。
The FCFS SAVI function is located in a forwarding device, such as a router or a Layer 2 switch. The following processing is performed depending on the type of port through which the packet has been received:
FCFS SAVI機能は、ルーターやレイヤー2スイッチなどの転送デバイスにあります。パケットを受信したポートの種類に応じて、以下の処理が行われます。
o If the data packet is received through a Trusted Port, the data packet is forwarded, and no SAVI processing performed on the packet.
o データパケットがトラステッドポート経由で受信された場合、データパケットは転送され、パケットに対してSAVI処理は実行されません。
o If the data packet is received through a Validating Port, then the FCFS SAVI function checks whether the received data packet is local traffic or transit traffic. It does so by verifying if the source address of the packet belongs to one of the directly connected prefixes available in the receiving interface. It does so by searching the FCFS SAVI Prefix List.
o 検証ポートを介してデータパケットを受信した場合、FCFS SAVI機能は、受信したデータパケットがローカルトラフィックかトランジットトラフィックかを確認します。これは、パケットの送信元アドレスが、受信インターフェイスで使用可能な直接接続されたプレフィックスの1つに属しているかどうかを確認することによって行われます。そのためには、FCFS SAVIプレフィックスリストを検索します。
* If the IP source address does not belong to one of the on-link prefixes of the receiving interface, the data packet is transit traffic, and the packet SHOULD be discarded. (If for some reason, discarding the packets is not acceptable, logging or triggering of alarms MAY be used). The FCFS SAVI function MAY send an ICMP Destination Unreachable Error back to the source address of the data packet, and ICMPv6, code 5 (Source address failed ingress/egress policy), should be used.
* IP送信元アドレスが受信インターフェイスのオンリンクプレフィックスのいずれにも属していない場合、データパケットはトランジットトラフィックであり、パケットは破棄する必要があります（SHOULD）。 （何らかの理由でパケットの破棄が受け入れられない場合、アラームのロギングまたはトリガーを使用できます）。 FCFS SAVI機能は、ICMP宛先到達不能エラーをデータパケットの送信元アドレスに送信する場合があり、ICMPv6、コード5（送信元アドレスが失敗した入力/出力ポリシー）を使用する必要があります。
* If the source address of the packet does belong to one of the prefixes available in the receiving port, then the FCFS SAVI local traffic validation process is executed as described below.
* パケットの送信元アドレスが受信ポートで使用可能なプレフィックスの1つに属している場合は、FCFS SAVIローカルトラフィック検証プロセスが以下のように実行されます。
* If the source address of the packet is an unspecified address, the packet is forwarded, and no SAVI processing is performed except for the case of the Neighbor Solicitation messages involved in the Duplicate Address Detection, which are treated as described in Section 3.2.3.
* パケットの送信元アドレスが指定されていないアドレスの場合、パケットは転送され、重複アドレス検出に関連する近傍要請メッセージの場合を除いて、SAVI処理は実行されません。セクション3.2.3で説明されているように処理されます。
We next describe how local traffic, including both control and data packets, is processed by the FCFS SAVI device using a state machine approach.
次に、制御パケットとデータパケットの両方を含むローカルトラフィックが、ステートマシンアプローチを使用してFCFS SAVIデバイスによって処理される方法について説明します。
The state machine described is for the binding of a given source IP address (called IPAddr) in a given FCFS SAVI device. This means that all the packets described as inputs in the state machine above refer to that given IP address. In the case of data packets, the source address of the packet is IPAddr. In the case of the DAD_NS packets, the Target Address is IPAddr. The key attribute is the IP address. The full state information is as follows:
説明されている状態マシンは、特定のFCFS SAVIデバイス内の特定のソースIPアドレス（IPAddrと呼ばれる）のバインディング用です。これは、上記のステートマシンで入力として説明されているすべてのパケットが、その特定のIPアドレスを参照していることを意味します。データパケットの場合、パケットの送信元アドレスはIPAddrです。 DAD_NSパケットの場合、ターゲットアドレスはIPAddrです。重要な属性はIPアドレスです。完全な状態情報は次のとおりです。
o IP ADDRESS: IPAddr
o IPアドレス：IPAddr
o BINDING ANCHOR: P
o 拘束アンカー：P
o LIFETIME: LT
o 生涯：LT
The possible states are as follows:
可能な状態は次のとおりです。
o NO_BIND
o の＿びんＤ
o TENTATIVE
o 暫定の
o VALID o TESTING_TP-LT
o有効o TESTING_TP-LT
o TESTING_VP
o TESTING_VP
We will use VP for Validating Port and TP for Trusted Port.
ポートの検証にはVPを使用し、信頼できるポートにはTPを使用します。
After bootstrapping (when no binding exists), the state for all source IP addresses is NO-BIND, i.e., there is no binding for the IP address to any binding anchor.
ブートストラップ後（バインディングが存在しない場合）、すべてのソースIPアドレスの状態はNO-BINDです。つまり、IPアドレスのバインディングアンカーに対するバインディングはありません。
NO_BIND: The binding for a source IP address entry is in this state when it does not have any binding to an anchor. All addresses are in this state by default after bootstrapping, unless bindings were created for them.
NO_BIND：アンカーへのバインディングがない場合、ソースIPアドレスエントリのバインディングはこの状態です。バインディングが作成されていない限り、すべてのアドレスは、ブートストラップ後にデフォルトでこの状態になります。
TENTATIVE: The binding for a source address for which a data packet or an NS generated by the Duplicate Address Detection (DAD) procedure has been received is in this state during the waiting period during which the DAD procedure is being executed (either by the host itself or the FCFS SAVI device on its behalf).
暫定的：データパケットまたは重複アドレス検出（DAD）プロシージャによって生成されたNSが受信されたソースアドレスのバインディングは、DADプロシージャが実行されている待機期間中にこの状態になります（ホストによって自身またはその代わりにFCFS SAVIデバイス）。
VALID: The binding for the source address is in this state after it has been verified. It means that it is valid and usable for filtering traffic.
VALID：確認後、送信元アドレスのバインディングはこの状態です。これは、トラフィックのフィルタリングに有効で使用できることを意味します。
TESTING_TP-LT: A binding for a source address enters this state due to one of two reasons:
TESTING_TP-LT：次の2つの理由のいずれかにより、送信元アドレスのバインディングがこの状態になります。
o When a Duplicate Address Detection Neighbor Solicitation has been received through a Trusted Port. This implies that a host is performing the DAD procedure for that source address in another switch. This may be due to an attack or to the fact that the host may have moved. The binding in this state is then being tested to determine which is the situation.
o 重複アドレス検出近隣要請が信頼できるポートを通じて受信されたとき。これは、ホストが別のスイッチのそのソースアドレスに対してDAD手順を実行していることを意味します。これは、攻撃が原因であるか、ホストが移動した可能性があります。次に、この状態のバインディングをテストして、どちらが状況かを判別します。
o The lifetime of the binding entry is about to expire. This is due to the fact that no packets have been seen by the FCFS SAVI device for the LIFETIME period. This may be due to the host simply being silent or because the host has left the location. In order to determine which is the case, a test is performed to determine if the binding information should be discarded.
o バインディングエントリのライフタイムがまもなく期限切れになります。これは、ライフタイム期間中、FCFS SAVIデバイスによってパケットが検出されなかったためです。これは、ホストがサイレントであるか、ホストがロケーションを離れたことが原因である可能性があります。どちらであるかを判別するために、バインディング情報を破棄する必要があるかどうかを判別するテストが実行されます。
TESTING_VP: A binding for a source address enters this state when a Duplicate Address Detection Neighbor Solicitation or a data packet has been received through a Validating Port other than the one address to which it is currently bound. This implies that a host is performing the DAD procedure for that source address through a different port. This may be due to an attack, the fact that the host may have moved, or just because another host tries to configure an address already used. The binding in this state is then being tested to determine which is the situation.
TESTING_VP：重複アドレス検出ネイバー請求またはデータパケットが、現在バインドされているアドレス以外の検証ポートを介して受信された場合、ソースアドレスのバインディングはこの状態になります。これは、ホストがそのソースアドレスに対して別のポートを介してDAD手順を実行していることを意味します。これは、攻撃、ホストが移動した可能性、または別のホストがすでに使用されているアドレスを設定しようとしたことが原因である可能性があります。次に、この状態のバインディングをテストして、どちらが状況かを判別します。
Next, we describe how the different inputs are processed depending on the state of the binding of the IP address (IPAddr).
次に、IPアドレス（IPAddr）のバインディングの状態に応じて、さまざまな入力がどのように処理されるかを説明します。
A simplified figure of the state machine is included in Figure 2 below.
以下の図2に、状態マシンの簡略図を示します。
NO_BIND
の＿びんＤ
o Upon the reception through a Validating Port (VP) of a Neighbor Solicitation (NS) generated by the Duplicate Address Detection (DAD) procedure (hereafter named DAD_NS) containing Target Address IPAddr, the FCFS SAVI device MUST forward the NS, and T_WAIT milliseconds later, it MUST send a copy of the same message. These DAD_NS messages are not sent through any of the ports configured as Validating Ports. The DAD_NS messages are sent through the Trusted Ports (but, of course, subject to usual switch behavior and possible Multicast Listener Discovery (MLD) snooping optimizations). The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT:=TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the Creation time is set to the current value of the local clock.
o ターゲットアドレスIPAddrを含む重複アドレス検出（DAD）プロシージャ（以下、DAD_NS）によって生成された近隣要請（NS）の検証ポート（VP）を介して受信すると、FCFS SAVIデバイスはNSおよびT_WAITミリ秒後に転送する必要があります、同じメッセージのコピーを送信する必要があります。これらのDAD_NSメッセージは、検証ポートとして構成されたポートを介して送信されません。 DAD_NSメッセージは、トラステッドポートを介して送信されます（ただし、通常のスイッチの動作と、可能なマルチキャストリスナーディスカバリー（MLD）スヌーピングの最適化が適用されます）。状態はTENTATIVEに移行します。 LIFETIMEはTENT_LT（つまり、LT：= TENT_LT）に設定され、BINDING ANCHORはVP（つまり、P：= VP）に設定され、作成時間はローカルクロックの現在の値に設定されます。
o Upon the reception through a Validating Port (VP) of a DATA packet containing IPAddr as the source address, the SAVI device SHOULD execute the process of sending Neighbor Solicitation messages of the Duplicate Address Detection process as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e., 2 Neighbor Solicitation messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (i.e., the time between two Neighbor Solicitation messages is T_WAIT milliseconds). The implications of not following the recommended behavior are described in Appendix A. The DAD_NS messages are not sent through any of the ports configured as Validating Ports. The DAD_NSOL messages are sent through Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations). The SAVI device MAY discard the data packets while the DAD procedure is being executed, or it MAY store them until the binding is created. In any case, it MUST NOT forward the data packets until the binding has been verified. The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the Creation time is set to the current value of the local clock.
o ソースアドレスとしてIPAddrを含むDATAパケットの検証ポート（VP）を介して受信すると、SAVIデバイスは、[RFC4862]のセクション5.4.2で説明されているように、重複アドレス検出プロセスの近隣要請メッセージを送信するプロセスを実行する必要があります（SHOULD）。次のデフォルトパラメータを使用するIPAddrの場合：2に設定されたDupAddrDetectTransmits（つまり、そのアドレスの2つの近隣要請メッセージがSAVIデバイスによって送信されます）およびT_WAITミリ秒に設定されたRetransTimer（つまり、2つの近隣要請メッセージ間の時間はT_WAITミリ秒です） ）。推奨される動作に従わない場合の影響については、付録Aで説明します。DAD_NSメッセージは、検証ポートとして構成されたどのポートからも送信されません。 DAD_NSOLメッセージは、信頼済みポートを介して送信されます（ただし、通常のスイッチの動作と可能なMLDスヌーピングの最適化が適用されます）。 SAVIデバイスは、DADプロシージャの実行中にデータパケットを破棄する場合があります。または、バインディングが作成されるまでデータパケットを保存する場合があります。いずれの場合も、バインディングが確認されるまでデータパケットを転送してはなりません。状態はTENTATIVEに移行します。 LIFETIMEはTENT_LT（つまり、LT：= TENT_LT）に設定され、BINDING ANCHORはVP（つまり、P：= VP）に設定され、作成時間はローカルクロックの現在の値に設定されます。
o Data packets containing IPAddr as the source address received through Trusted Ports are processed and forwarded as usual (i.e., no special SAVI processing).
o トラステッドポートを介して受信したソースアドレスとしてIPAddrを含むデータパケットは、通常どおりに処理および転送されます（つまり、特別なSAVI処理は行われません）。
o DAD_NS packets containing IPAddr as the Target Address that are received through a Trusted Port MUST NOT be forwarded through any of the Validating Ports, but they are sent through the Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations).
o トラステッドポートを介して受信されるターゲットアドレスとしてIPAddrを含むDAD_NSパケットは、検証ポートを介して転送してはなりません（MUST）が、トラステッドポートを介して送信されます（ただし、通常のスイッチの動作と可能なMLDスヌーピングの最適化が適用されます） ）。
o Neighbor Advertisement packets sent to all nodes as a reply to the DAD_NS (hereafter called DAD_NA) containing IPAddr as the Target Address coming through a Validating Port are discarded.
o 検証ポートを介して着信するターゲットアドレスとしてIPAddrを含むDAD_NS（以降、DAD_NAと呼びます）への応答としてすべてのノードに送信されるネイバーアドバタイズパケットは破棄されます。
o Other signaling packets are processed and forwarded as usual (i.e., no SAVI processing).
o 他のシグナリングパケットは通常どおりに処理および転送されます（つまり、SAVI処理は行われません）。
TENTATIVE
暫定の
o If the LIFETIME times out, the state is moved to VALID. The LIFETIME is set to DEFAULT_LT (i.e., LT:= DEFAULT_LT). Stored data packets (if any) are forwarded.
o LIFETIMEがタイムアウトになると、状態はVALIDに移行します。 LIFETIMEはDEFAULT_LT（つまり、LT：= DEFAULT_LT）に設定されます。保存されているデータパケット（存在する場合）が転送されます。
o If a Neighbor Advertisement (NA) is received through a Trusted Port with the Target Address set to IPAddr, then the message is forwarded through port P, the state is set to NO_BIND, and the BINDING ANCHOR and the LIFETIME are cleared. Data packets stored corresponding to this binding are discarded.
o ターゲットアドレスがIPAddrに設定された信頼できるポートを介して近隣アドバタイズ（NA）を受信した場合、メッセージはポートPを介して転送され、状態はNO_BINDに設定され、バインドアンカーとライフタイムはクリアされます。このバインディングに対応して格納されたデータパケットは破棄されます。
o If an NA is received through a Validating Port with the Target Address set to IPAddr, the NA packet is discarded
o ターゲットアドレスがIPAddrに設定された検証ポートを介してNAを受信した場合、NAパケットは破棄されます
o If a data packet with source address IPAddr is received with binding anchor equal to P, then the packet is either stored or discarded.
o 送信元アドレスがIPAddrのデータパケットがPに等しいバインディングアンカーで受信された場合、パケットは格納または破棄されます。
o If a data packet with source address IPAddr is received through a Trusted Port, the data packet is forwarded. The state is unchanged.
o 送信元アドレスがIPAddrのデータパケットがトラステッドポート経由で受信された場合、データパケットが転送されます。状態は変更されていません。
o If a data packet with source address IPAddr is received through a Validating Port other than P, the data packet is discarded.
o 送信元アドレスがIPAddrのデータパケットがP以外の検証ポートを介して受信された場合、データパケットは破棄されます。
o If a DAD_NS is received from a Trusted Port, with the Target Address set to IPAddr, then the message is forwarded to the Validating Port P, the state is set to NO_BIND, and the BINDING ANCHOR and LIFETIME are cleared. Data packets stored corresponding to this binding are discarded.
o ターゲットアドレスがIPAddrに設定された信頼できるポートからDAD_NSを受信した場合、メッセージは検証ポートPに転送され、状態はNO_BINDに設定され、バインドアンカーとライフタイムはクリアされます。このバインディングに対応して格納されたデータパケットは破棄されます。
o If a DAD_NS with the Target Address set to IPAddr is received from a Validating Port P' other than P, the message is forwarded to the Validating Port P and to the Trusted Ports, and the state remains in TENTATIVE; however, the BINDING ANCHOR is changed from P to P', and LIFETIME is set to TENT_LT. Data packets stored corresponding to the binding with P are discarded.
o ターゲットアドレスがIPAddrに設定されたDAD_NSがP以外の検証ポートP 'から受信された場合、メッセージは検証ポートPおよび信頼ポートに転送され、状態はTENTATIVEのままです。ただし、BINDING ANCHORはPからP 'に変更され、LIFETIMEはTENT_LTに設定されます。 Pとのバインディングに対応して保存されたデータパケットは破棄されます。
o Other signaling packets are processed and forwarded as usual (i.e., no SAVI processing).
o 他のシグナリングパケットは通常どおりに処理および転送されます（つまり、SAVI処理は行われません）。
VALID
有効
o If a data packet containing IPAddr as the source address arrives from Validating Port P, then the LIFETIME is set to DEFAULT_LT and the packet is forwarded as usual.
o 送信元アドレスとしてIPAddrを含むデータパケットがValidating Port Pから到着すると、LIFETIMEはDEFAULT_LTに設定され、パケットは通常どおり転送されます。
o If a DAD_NS is received from a Trusted Port, then the DAD_NS message is forwarded to port P and is also forwarded to the Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations). The state is changed to TESTING_TP-LT. The LIFETIME is set to TENT_LT.
o DAD_NSが信頼できるポートから受信されると、DAD_NSメッセージはポートPに転送され、信頼できるポートにも転送されます（ただし、通常のスイッチの動作と可能なMLDスヌーピングの最適化が適用されます）。状態がTESTING_TP-LTに変更されます。 LIFETIMEはTENT_LTに設定されます。
o If a data packet containing source address IPAddr or a DAD_NA packet with the Target Address set to IPAddr is received through a Validating Port P' other than P, then the SAVI device will execute the process of sending DAD_NS messages as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e., two NS messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (i.e., the time between two NS messages is T_WAIT milliseconds). The DAD_NS message will be forwarded to the port P. The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT. The SAVI device MAY discard the data packet while the DAD procedure is being executed, or it MAY store them until the binding is created. In any case, it MUST NOT forward the data packets until the binding has been verified.
o ソースアドレスIPAddrまたはターゲットアドレスがIPAddrに設定されたDAD_NAパケットを含むデータパケットが、P以外の検証ポートP 'を介して受信されると、SAVIデバイスは、セクション5.4.2で説明されているDAD_NSメッセージの送信プロセスを実行します。次のデフォルトパラメータを使用するIPAddrの[RFC4862]の例：2に設定されたDupAddrDetectTransmits（つまり、そのアドレスの2つのNSメッセージがSAVIデバイスによって送信されます）およびT_WAITミリ秒に設定されたRetransTimer（つまり、2つのNSメッセージ間の時間はT_WAITミリ秒）。 DAD_NSメッセージはポートPに転送されます。状態はTESTING_VPに移動します。 LIFETIMEはTENT_LTに設定されます。 SAVIデバイスは、DADプロシージャの実行中にデータパケットを破棄する場合があります。または、バインディングが作成されるまでデータパケットを保存する場合があります。いずれの場合も、バインディングが確認されるまでデータパケットを転送してはなりません。
o If a DAD_NS packet with the Target Address set to IPAddr is received through a Validating Port P' other than P, then the SAVI device will forward the DAD_NS packet, and T_WAIT milliseconds later, it will execute the process of sending DAD_NS messages as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 1 and RetransTimer set to T_WAIT milliseconds. The DAD_NS messages will be forwarded to the port P. The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT. The SAVI device MAY discard the data packets while the DAD procedure is being executed, or it MAY store them until the binding is created. In any case, it MUST NOT forward the data packets until the binding has been verified.
oターゲットアドレスがIPAddrに設定されたDAD_NSパケットがP以外の検証ポートP 'を介して受信された場合、SAVIデバイスはDAD_NSパケットを転送し、T_WAITミリ秒後に、前述のようにDAD_NSメッセージを送信するプロセスを実行します。 [RFC4862]のセクション5.4.2で、IPAddrのデフォルトパラメータを使用します。DupAddrDetectTransmitsを1に設定し、RetransTimerをT_WAITミリ秒に設定します。 DAD_NSメッセージはポートPに転送されます。状態はTESTING_VPに移動します。 LIFETIMEはTENT_LTに設定されます。 SAVIデバイスは、DADプロシージャの実行中にデータパケットを破棄する場合があります。または、バインディングが作成されるまでデータパケットを保存する場合があります。いずれの場合も、バインディングが確認されるまでデータパケットを転送してはなりません。
o If the LIFETIME expires, then the SAVI device will execute the process of sending DAD_NS messages as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e., two NS messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (i.e., the time between two NS messages is T_WAIT milliseconds). The DAD_NS messages will be forwarded to the port P. The state is changed to TESTING_TP-LT, and the LIFETIME is set to TENT_LT.
o LIFETIMEの有効期限が切れると、SAVIデバイスは、[RFC4862]のセクション5.4.2で説明されているように、IPAddrのDAD_NSメッセージを送信するプロセスを実行します。DupAddrDetectTransmitsは2に設定されます（つまり、そのアドレスの2つのNSメッセージ） SAVIデバイスによって送信されます）、RetransTimerはT_WAITミリ秒に設定されます（つまり、2つのNSメッセージ間の時間はT_WAITミリ秒です）。 DAD_NSメッセージはポートPに転送されます。状態はTESTING_TP-LTに変更され、LIFETIMEはTENT_LTに設定されます。
o If a data packet containing IPAddr as a source address arrives from Trusted Port, the packet MAY be discarded. The event MAY be logged.
o 送信元アドレスとしてIPAddrを含むデータパケットがTrusted Portから到着した場合、パケットは破棄される場合があります。イベントがログに記録される場合があります。
o Other signaling packets are processed and forwarded as usual (i.e., no SAVI processing). In particular, a DAD_NA coming from port P and containing IPAddr as the Target Address is forwarded as usual.
o 他のシグナリングパケットは通常どおりに処理および転送されます（つまり、SAVI処理は行われません）。特に、ポートPから送信され、ターゲットアドレスとしてIPAddrを含むDAD_NAは、通常どおり転送されます。
TESTING_TP-LT
TESTING_TP-LT
o If the LIFETIME expires, the BINDING ANCHOR is cleared, and the state is changed to NO_BIND.
o LIFETIMEが期限切れになると、BINDING ANCHORがクリアされ、状態がNO_BINDに変更されます。
o If an NA message containing the IPAddr as the Target Address is received through the Validating Port P as a reply to the DAD_NS message, then the NA is forwarded as usual, and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT
o ターゲットアドレスとしてIPAddrを含むNAメッセージが、DAD_NSメッセージへの応答として検証ポートPを介して受信された場合、NAは通常どおり転送され、状態はVALIDに変更されます。 LIFETIMEはDEFAULT_LTに設定されます
o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT.
o ソースアドレスとしてIPAddrを含むデータパケットがポートPを介して受信されると、パケットが転送され、状態がVALIDに変更されます。 LIFETIMEはDEFAULT_LTに設定されます。
o If a DAD_NS is received from a Trusted Port, the DAD_NS is forwarded as usual.
o 信頼できるポートからDAD_NSを受信した場合、DAD_NSは通常どおり転送されます。
o If a DAD_NS is received from a Validating Port P' other than P, the DAD_NS is forwarded as usual, and the state is moved to TESTING_VP.
o P以外の検証ポートP 'からDAD_NSを受信した場合、DAD_NSは通常どおり転送され、状態はTESTING_VPに移行します。
o If a data packet is received through a Validating Port P' that is other than port P, then the packet is discarded.
o データパケットがポートP以外の検証ポートP 'を介して受信された場合、パケットは破棄されます。
o If a data packet is received through a Trusted Port, then the packet MAY be discarded. The event MAY be logged.
o 信頼できるポートを介してデータパケットが受信された場合、パケットは破棄される場合があります。イベントがログに記録される場合があります。
TESTING_VP
TESTING_VP
o If the LIFETIME expires, the BINDING ANCHOR is modified from P to P', the LIFETIME is set to DEFAULT_LT, and the state is changed to VALID. Stored data packet coming from P' are forwarded.
o LIFETIMEが期限切れになると、BINDING ANCHORがPからP 'に変更され、LIFETIMEがDEFAULT_LTに設定され、状態がVALIDに変更されます。 P 'からの保存データパケットが転送されます。
o If an NA message containing the IPAddr as the Target Address is received through the Validating Port P as a reply to the DAD_NS message, then the NA is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT.
o ターゲットアドレスとしてIPAddrを含むNAメッセージが、DAD_NSメッセージへの応答として検証ポートPを介して受信された場合、NAは通常どおり転送され、状態はVALIDに変更されます。 LIFETIMEはDEFAULT_LTに設定されます。
o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded.
o 送信元アドレスとしてIPAddrを含むデータパケットがポートPを介して受信されると、パケットは転送されます。
o If a data packet containing IPAddr as the source address is received through a Validating Port P'' that is other than port P or P', then the packet is discarded.
o 送信元アドレスとしてIPAddrを含むデータパケットが、ポートPまたはP '以外の検証ポートP' 'を介して受信されると、パケットは破棄されます。
o If a data packet containing IPAddr as the source address is received through a Trusted Port (i.e., other than port P), the state is moved to TESTING_TP-LT, and the packet MAY be discarded.
o 送信元アドレスとしてIPAddrを含むデータパケットが信頼できるポート（ポートP以外）経由で受信された場合、状態はTESTING_TP-LTに移行し、パケットは破棄される場合があります。
o If a DAD_NS is received through a Trusted Port, the packet is forwarded as usual, and the state is moved to TESTING_TP-LT.
o DAD_NSがTrusted Port経由で受信された場合、パケットは通常どおり転送され、状態はTESTING_TP-LTに移行します。
o If a DAD_NS is received through Validating Port P'' other than P or P', the packet is forwarded as usual, and P'' is stored as the tentative port, i.e., P':=P''. The state remains the same.
o PまたはP '以外の検証ポートP' 'を介してDAD_NSを受信した場合、パケットは通常どおり転送され、P' 'は一時的なポートとして保存されます（つまり、P'：= P ''）。状態は同じままです。
+---------+ VP_NS, VP_DATA/2xNS +-----------+
| |---------------------------------------->| |
| NO_BIND | | TENTATIVE |
| |<----------------------------------------| |
+---------+ TP_NA, TP_NS/- +-----------+
^ |
| | TimeOut
Timeout| |
| v
+---------+ VP_NA/- +-----------+
| |---------------------------------------->| |
| TESTING | TP_NS/- | |
| TP-LT |<----------------------------------------| VALID |
| | TimeOut/2xNS | |
| |<----------------------------------------| |
+---------+ +-----------+
^ | ^ |
| | | |
| +--------------------- ---------------------+ |
| VP_NS/- | | NP_NA, TimeOut/- |
| v | |
| +-----------+ |
| | | |
+---------------------| TESTING |<----------------------+
VP_NS, VP_DATA/- | VP | VP_DATA, VP_NS,
+-----------+ VP_NA/2xNS
Figure 2: Simplified State Machine
図2：簡略化された状態マシン
MLD Considerations
MLDの考慮事項
The FCFS SAVI device MUST join the solicited node multicast group for all the addresses with a state other than NO_BIND. This is needed to make sure that the FCFS SAVI device will receive the DAD_NS for those addresses. Please note that it may not be enough to rely on the host behind the Validating Port to do so, since the node may move, and after a while, the packets for that particular solicited node multicast group will no longer be forwarded to the FCFS SAVI device. Therefore, the FCFS SAVI device MUST join the solicited node multicast groups for all the addresses that are in a state other than NO_BIND.
FCFS SAVIデバイスは、NO_BIND以外の状態のすべてのアドレスの送信請求ノードマルチキャストグループに参加する必要があります。これは、FCFS SAVIデバイスがそれらのアドレスのDAD_NSを確実に受信するために必要です。ノードが移動する可能性があるため、検証ポートの背後にあるホストに依存するだけでは不十分な場合があることに注意してください。しばらくすると、その特定の要請ノードマルチキャストグループのパケットは、FCFS SAVIに転送されなくなります。端末。したがって、FCFS SAVIデバイスは、NO_BIND以外の状態にあるすべてのアドレスの送信請求ノードマルチキャストグループに参加する必要があります。
The guidelines for port configuration in FCFS SAVI devices are as follows:
FCFS SAVIデバイスのポート構成のガイドラインは次のとおりです。
o The FCFS SAVI realm (i.e., the realm that is inside the FCFS SAVI protection perimeter) MUST be connected. If this is not the case, legitimate transit traffic may be dropped.
o FCFS SAVIレルム（つまり、FCFS SAVI保護境界内にあるレルム）を接続する必要があります。そうでない場合、正当な通過トラフィックがドロップされる可能性があります。
o Ports that are connected to another FCFS SAVI device MUST be configured as Trusted Ports. Not doing so will significantly increase the memory consumption in the FCFS SAVI devices and may result in legitimate transit traffic being dropped.
o 別のFCFS SAVIデバイスに接続されているポートは、信頼できるポートとして構成する必要があります。そうしないと、FCFS SAVIデバイスのメモリ消費が大幅に増加し、正当なトランジットトラフィックがドロップされる可能性があります。
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 spoofed source addresses. A valid exception is the case of a trusted host (e.g., a server) that could be connected to a Trusted Port, but untrusted hosts MUST be connected to Validating Ports.
o ホストに接続されているポートは、検証ポートとして構成する必要があります（SHOULD）。そうしないと、そのポートに接続されているホストが、送信元アドレスが偽装されたパケットを送信できるようになります。有効な例外は、信頼できるホスト（サーバーなど）が信頼できるポートに接続できる場合ですが、信頼できないホストは検証ポートに接続する必要があります。
o Ports connected to routers MUST be configured as Trusted Ports. Configuring them as Validating Ports should result in transit traffic being dropped.
o ルーターに接続されているポートは、信頼できるポートとして構成する必要があります。それらをValidating Portsとして設定すると、トランジットトラフィックがドロップされます。
o Ports connected to a chain of one or more legacy switches that have hosts connected SHOULD be configured as Validating Ports. Not doing so will allow the host connected to any of these switches to send packets with spoofed source addresses. A valid exception is the case where the legacy switch only has trusted hosts attached, in which case it could be connected to a Trusted Port, but if there is at least one untrusted hosts connected to the legacy switch, then it MUST be connected to Validating Ports.
o ホストが接続されている1つ以上のレガシースイッチのチェーンに接続されているポートは、検証ポートとして構成する必要があります（SHOULD）。そうしないと、これらのスイッチのいずれかに接続されているホストは、送信元アドレスが偽装されたパケットを送信できます。有効な例外は、レガシースイッチに信頼できるホストのみが接続されている場合です。この場合、信頼できるポートに接続できますが、レガシースイッチに接続されている信頼できないホストが少なくとも1つある場合は、検証に接続する必要があります。ポート。
o Ports connected to a chain of one or more legacy switches that have other FCFS SAVI devices and/or routers connected but had no hosts attached to them MUST be configured as Trusted Ports. Not doing so will at least significantly increase the memory consumption in the FCFS SAVI devices, increase the signaling traffic due to FCFS SAVI validation, and may result in legitimate transit traffic being dropped.
o 他のFCFS SAVIデバイスやルーターが接続されているが、ホストが接続されていない1つ以上のレガシースイッチのチェーンに接続されているポートは、信頼できるポートとして構成する必要があります。そうしないと、FCFS SAVIデバイスのメモリ消費が大幅に増加し、FCFS SAVI検証のためにシグナリングトラフィックが増加し、正当なトランジットトラフィックがドロップされる可能性があります。
If the FCFS SAVI device is a switch that supports customer VLANs [IEEE.802-1Q.2005], the FCFS SAVI implementation MUST behave as if there was one FCFS SAVI process per customer VLAN. The FCFS SAVI process of each customer VLAN will store the binding information corresponding to the nodes attached to that particular customer VLAN.
FCFS SAVIデバイスがカスタマーVLAN [IEEE.802-1Q.2005]をサポートするスイッチである場合、FCFS SAVI実装は、カスタマーVLANごとに1つのFCFS SAVIプロセスがあったかのように動作する必要があります。各カスタマーVLANのFCFS SAVIプロセスは、その特定のカスタマーVLANに接続されたノードに対応するバインディング情報を保存します。
Following are the default values used in the FCFS SAVI specification.
FCFS SAVI仕様で使用されるデフォルト値は次のとおりです。
TENT_LT is 500 milliseconds
TENT_LTは500ミリ秒です
DEFAULT_LT is 5 minutes
DEFAULT_LTは5分
T_WAIT is 250 milliseconds
T_WAITは250ミリ秒
An implementation MAY allow these values to be modified, but tuning them precisely is considered out of the scope of this document.
実装ではこれらの値を変更できる場合がありますが、これらの値を正確に調整することは、このドキュメントの範囲外と見なされます。
There are two types of Denial-of-Service (DoS) attacks [RFC4732] that can be envisaged in an FCFS SAVI environment. On one hand, we can envision attacks against the FCFS SAVI device resources. On the other hand, we can envision DoS attacks against the hosts connected to the network where FCFS SAVI is running.
FCFS SAVI環境では、2種類のサービス拒否（DoS）攻撃[RFC4732]が想定されます。一方では、FCFS SAVIデバイスリソースに対する攻撃を想定できます。一方、FCFS SAVIが実行されているネットワークに接続されたホストに対するDoS攻撃を想定できます。
The attacks against the FCFS SAVI device basically consist of making the FCFS 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 FCFS SAVI device create state for each of the addresses and waste memory. At some point, the FCFS 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 FCFS SAVI device runs out of the memory allocated for the FCFS SAVI DB, it is RECOMMENDED that it create 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 LIFETIME, which is updated using data packets. The result is that in order for an attacker to actually fill the FCFS SAVI DB with false source addresses, it needs to continuously send data packets 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.
FCFS SAVIデバイスに対する攻撃は、基本的に、FCFS SAVIデバイスが不足するまでリソースを消費させることで構成されます。たとえば、可能性のある攻撃は、異なる送信元アドレスでパケットを送信し、FCFS SAVIデバイスに各アドレスの状態を作成させ、メモリを浪費させることです。ある時点で、FCFS SAVIデバイスのメモリが不足し、対応方法を決定する必要があります。その結果、エントリをプルーニングするには、何らかの形のガベージコレクションが必要になります。 FCFS SAVIデバイスがFCFS SAVI DBに割り当てられたメモリを使い果たした場合、作成時間の長いエントリを削除して新しいエントリを作成することをお勧めします。これは、古いエントリが保持され、新しいエントリが互いに上書きすることを意味します。攻撃者が異なる送信元アドレスでデータパケットのバッチを送信する攻撃シナリオでは、新しい送信元アドレスごとに、攻撃自体によって作成された別の送信元アドレスが書き換えられる可能性があります。エントリは、データパケットを使用して更新されるLIFETIMEを使用してガベージコレクションされることにも注意してください。その結果、攻撃者が実際にFCFS SAVI DBに誤ったソースアドレスを入力するためには、エントリが古くなり、正当なエントリと競合するように、すべての異なるソースアドレスのデータパケットを継続的に送信する必要があります。その結果、攻撃者にとって攻撃のコストが大幅に増加します。
In addition, it is RECOMMENDED that an FCFS 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 recommended minimum is the memory needed to store four bindings associated with the port. The motivation for this recommendation is as follows. An attacker attached to a given port of an FCFS SAVI device may attempt to launch a DoS attack towards the FCFS SAVI device by creating many bindings for different addresses. It can do so by sending DAD_NS for different addresses. The result is that the attack will consume all the memory available in the FCFS SAVI device. The above recommendation aims to reserve a minimum amount of memory per port, so that hosts 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.
さらに、FCFS SAVIデバイスが使用可能なポートごとに最小量のメモリを予約することをお勧めします（ポートがL2アンカーの一部として使用される場合）。推奨される最小値は、ポートに関連付けられた4つのバインディングを格納するために必要なメモリです。この勧告の動機は次のとおりです。 FCFS SAVIデバイスの特定のポートに接続している攻撃者は、さまざまなアドレスに対して多くのバインディングを作成することにより、FCFS SAVIデバイスに対してDoS攻撃を仕掛けようとする可能性があります。異なるアドレスに対してDAD_NSを送信することにより、これを行うことができます。その結果、攻撃はFCFS SAVIデバイスで利用可能なすべてのメモリを消費します。上記の推奨事項は、ポートごとに最小量のメモリを予約することを目的としているため、異なるポートに配置されたホストは、別のポートでDoS攻撃が発生している場合でも、ポート用に予約されたメモリを利用できます。
As the FCFS SAVI device may store data packets while the address is being verified, the memory for data packet storage may also be a target of DoS attacks. The effects of such attacks may be limited to the lack of capacity to store new data packets. The effect of such attacks will be that data packets will be dropped during the verification period. An FCFS SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions to have available memory even in the case of attacks such those described above.
FCFS SAVIデバイスは、アドレスの確認中にデータパケットを保存する場合があるため、データパケットの保存用のメモリもDoS攻撃の標的になる可能性があります。このような攻撃の影響は、新しいデータパケットを格納する容量の不足に限定される可能性があります。このような攻撃の影響は、検証期間中にデータパケットがドロップされることです。 FCFS SAVIデバイスは、データパケットを格納するために使用されるメモリの量を制限する必要があります。これにより、上記のような攻撃が発生した場合でも、他の機能で使用可能なメモリを確保できます。
The FCFS SAVI device generates two DAD_NS packets upon the reception of a DAD_NS or a data packet. As such, the FCFS SAVI device can be used as an amplifier by attackers. In order to limit this type of attack, the FCFS SAVI device MUST perform rate limiting of the messages it generates. Rate limiting is performed on a per-port basis, since having an attack on a given port should not prevent the FCFS SAVI device from functioning normally in the rest of the ports.
FCFS SAVIデバイスは、DAD_NSまたはデータパケットの受信時に2つのDAD_NSパケットを生成します。そのため、攻撃者はFCFS SAVIデバイスをアンプとして使用できます。このタイプの攻撃を制限するために、FCFS SAVIデバイスは、生成するメッセージのレート制限を実行する必要があります。レート制限はポートごとに実行されます。これは、特定のポートに攻撃があったとしても、残りのポートでFCFS SAVIデバイスが正常に機能することを妨げるものではないためです。
FCFS SAVI performs its function by binding an IP source address to a binding anchor. If the attacker manages to send packets using the binding anchor associated to a given IP address, FCFS SAVI validation will be successful, and the FCFS SAVI device will allow the packet through. This can be achieved by spoofing the binding anchor or by sharing of the binding anchor between the legitimate owner of the address and the attacker. An example of the latter is the case where the binding anchor is a port of a switched network and a legacy switch (i.e., not a SAVI-capable switch) is connected to that port. All the source addresses of the hosts connected to the legacy switch will share the same binding anchor (i.e., the switch port). This means that hosts connected to the legacy switch can spoof each other's IP address and will not be detected by the FCFS SAVI device. This can be prevented by not sharing binding anchors among hosts.
FCFS SAVIは、IP送信元アドレスをバインディングアンカーにバインドすることにより、その機能を実行します。攻撃者が特定のIPアドレスに関連付けられたバインディングアンカーを使用してパケットを送信できた場合、FCFS SAVI検証は成功し、FCFS SAVIデバイスはパケットの通過を許可します。これは、バインディングアンカーをスプーフィングすることによって、またはアドレスの正当な所有者と攻撃者の間でバインディングアンカーを共有することによって実現できます。後者の例は、バインディングアンカーがスイッチドネットワークのポートであり、レガシースイッチ（つまり、SAVI対応スイッチではない）がそのポートに接続されている場合です。レガシースイッチに接続されているホストのすべての送信元アドレスは、同じバインディングアンカー（つまり、スイッチポート）を共有します。つまり、レガシースイッチに接続されたホストは、互いのIPアドレスを偽装する可能性があり、FCFS SAVIデバイスによって検出されません。これは、ホスト間でバインディングアンカーを共有しないことで防止できます。
FCFS SAVI assumes that a host will be able to defend its address when the DAD procedure is executed for its addresses. 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). So, when a DAD_NS is issued for a given IP address for which a binding exists in an FCFS SAVI device, the FCFS SAVI device expects to see a DAD_NA coming from the binding anchor associated to that IP address in order to preserve the binding. If the FCFS SAVI device does not see the DAD_NA, 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 intercepting the DAD_NA or launching a DoS attack to the host that will prevent it from issuing proper DAD replies.
FCFS SAVIは、アドレスに対してDADプロシージャが実行されると、ホストがそのアドレスを防御できると想定します。これは、とりわけ、リンク内のモビリティをサポートするために必要です（つまり、ホストがIPアドレスを変更せずに、同じIPサブネットワークの異なるレイヤー2アンカーにデタッチして再接続できるようにするため）。そのため、FCFS SAVIデバイスにバインディングが存在する特定のIPアドレスに対してDAD_NSが発行されると、FCFS SAVIデバイスは、そのIPアドレスに関連付けられたバインディングアンカーからのDAD_NAを確認して、バインディングを保持します。 FCFS SAVIデバイスがDAD_NAを認識しない場合、別のバインディングアンカーへのバインディングを許可することがあります。つまり、攻撃者がホストの送信元アドレスの防御を阻止した場合、既存のバインディングを破棄し、別のバインディングアンカーを使用して新しいバインディングを作成することができます。攻撃者は、たとえば、DAD_NAを傍受したり、ホストにDoS攻撃を仕掛けたりして、適切なDAD応答を発行できないようにする可能性があります。
Even if routers are considered trusted, nothing can prevent a router from being compromised and sending traffic with spoofed IP source addresses. Such traffic would be allowed with the present FCFS SAVI specification. A way to mitigate this issue could be to specify a new port type (e.g., Router Port (RP)) that would act as Trusted Port for the transit traffic and as Validating Port for the local traffic. A detailed solution about this issue is outside the scope of this document.
ルーターが信頼できると見なされていても、ルーターが危険にさらされたり、偽装されたIP送信元アドレスでトラフィックを送信したりすることを防ぐことはできません。このようなトラフィックは、現在のFCFS SAVI仕様で許可されます。この問題を軽減する方法として、トランジットトラフィックの信頼ポートおよびローカルトラフィックの検証ポートとして機能する新しいポートタイプ（ルーターポート（RP）など）を指定する方法があります。この問題に関する詳細なソリューションは、このドキュメントの範囲外です。
Personally identifying information MUST NOT be included in the FCFS SAVI DB with the MAC address as the canonical example, except when there is an attack attempt involved. Moreover, compliant implementations MUST NOT log binding anchor information except where there is an identified reason why that information is likely to be involved in detection, prevention, or tracing of actual source address spoofing. Information that is not logged MUST be deleted as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND). Information about the majority of hosts that never spoof SHOULD NOT be logged.
個人を特定する情報は、攻撃の試みが含まれる場合を除いて、正規の例としてMACアドレスとともにFCFS SAVI DBに含めてはなりません（MUST NOT）。さらに、準拠した実装は、その情報が実際の送信元アドレスのなりすましの検出、防止、または追跡に関与する可能性が高いという特定の理由がある場合を除き、バインディングアンカー情報をログに記録してはなりません。ログに記録されない情報は、できるだけ早く（つまり、指定されたアドレスの状態がNO_BINDに戻ったらすぐに）削除する必要があります。なりすましを行わないホストの大部分に関する情報はログに記録すべきではありません。
Even if the FCFS SAVI could get information from ND messages secured with Secure Neighbor Discovery (SEND) [RFC3971], in some case, the FCFS SAVI device must spoof DAD_NS messages but doesn't know the security credentials associated with the IPAddr (i.e., the private key used to sign the DAD_NS messages). So, when SEND is deployed, it is recommended to use SEND SAVI [SAVI-SEND] rather than FCFS SAVI.
FCFS SAVIがSecure Neighbor Discovery（SEND）[RFC3971]で保護されたNDメッセージから情報を取得できたとしても、場合によっては、FCFS SAVIデバイスはDAD_NSメッセージを偽装する必要がありますが、IPAddr（つまり、 DAD_NSメッセージの署名に使用される秘密鍵）。したがって、SENDをデプロイする場合は、FCFS SAVIではなくSEND SAVI [SAVI-SEND]を使用することをお勧めします。
Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@cernet.edu.cn
Jun Bi Cernetネットワーク研究センター、清華大学北京100084中国Eメール：junbi@cernet.edu.cn
Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China EMail: yaog@netarchlab.tsinghua.edu.cn
GU Angy AOC er net network research center、ts inghuauniversity Beijing 100084 China email：岩@net Arch lab。彼の4年計画。クォータ。才能
Fred Baker Cisco Systems EMail: fred@cisco.com
Fred Baker Cisco Systems EMail：fred@cisco.com
Alberto Garcia Martinez University Carlos III of Madrid EMail: alberto@it.uc3m.es
Alberto Garcia Martinez University Carlos III of Madrid EMail：alberto@it.uc3m.es
This document benefited from the input of the following individuals: Joel Halpern, Christian Vogt, Dong Zhang, Frank Xia, Jean-Michel Combes, Jari Arkko, Stephen Farrel, Dan Romascanu, Russ Housley, Pete Resnick, Ralph Droms, Wesley Eddy, Dave Harrington, and Lin Tao.
このドキュメントは、次の個人の入力の恩恵を受けました：ジョエルハルパーン、クリスチャンフォークト、ドンチャン、フランクシア、ジャンミッシェルコームス、ジャリアルコ、スティーブンファレル、ダンローマスカヌ、ラスハウズリー、ピートレズニック、ラルフドロムス、ウェスリーエディ、デイブハリントン、リンタオ。
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnuloは、第7回フレームワークプログラムの下で欧州委員会が支援する研究プロジェクトであるTrilogyから資金提供を受けています。
[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月。
[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月。
[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月。
[SAVI-FRAMEWORK] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement Framework", Work in Progress, December 2011.
[SAVI-FRAMEWORK] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F。、およびC. Vogt、「Source Address Validation Improvement Framework」、Work in Progress、2011年12月。
[SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for DHCP", Work in Progress, February 2012.
[SAVI-DHCP] Bi、J.、Wu、J.、Yao、G.、F。ベイカー、「SAVI Solution for DHCP」、Work in Progress、2012年2月。
[SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-Address Validation Implementation", Work in Progress, March 2012.
[SAVI-SEND] Bagnulo、M。、およびA. Garcia-Martinez、「SENDベースのソースアドレス検証の実装」、Work in Progress、2012年3月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、「インターネットのアーキテクチャの原則」、RFC 1958、1996年6月。
[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月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、E。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[IEEE.802-1D.1998] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks Media Access Control (MAC) Bridges", IEEE Standard 802.1D, 1998.
[IEEE.802-1D.1998] Institute of Electrical and Electronics Engineers、「IEEE Standard for Local and Metropolitan Area Networks Media Access Control（MAC）Bridges」、IEEE Standard 802.1D、1998。
[IEEE.802-1D.2004] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks Media Access Control (MAC) Bridges", IEEE Standard 802.1D, 2004.
[IEEE.802-1D.2004] Institute of Electrical and Electronics Engineers、「IEEE Standard for Local and Metropolitan Area Networks Media Access Control（MAC）Bridges」、IEEE Standard 802.1D、2004。
[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月。
[IEEE.802-1X.2004] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control", IEEE Standard 802.1X, 2004.
[IEEE.802-1X.2004] Institute of Electrical and Electronics Engineers、「IEEE Standard for Local and Metropolitan Area Networks-Port-Based Network Access Control」、IEEE Standard 802.1X、2004。
This section qualifies some of the SHOULDs that are included in this specification by explaining the implications of not following the recommended behavior. We start by describing the implication of not following the recommendation of generating DAD_NS upon the reception of a data packet for which there is no binding, and then we describe the implications of not discarding the non-compliant packets.
このセクションでは、推奨される動作に従わないことの影響を説明することにより、この仕様に含まれるいくつかのSHOULDを限定します。まず、バインディングがないデータパケットを受信したときにDAD_NSを生成するという推奨事項に従わない場合の影響について説明し、次に、非準拠パケットを破棄しない場合の影響について説明します。
A.1. Implications of Not Generating DAD_NS Packets upon the Reception of Non-Compliant Data Packets
A.1. 非準拠データパケットの受信時にDAD_NSパケットを生成しないことの影響
This specification recommends that SAVI implementations generate a DAD_NS message upon the reception of a data packet for which they have no binding. In this section, we describe the implications of not doing so and simply discarding the data packet instead.
この仕様では、SAVI実装がバインディングのないデータパケットの受信時にDAD_NSメッセージを生成することを推奨しています。このセクションでは、そうしない場合の影響について説明し、代わりにデータパケットを単に破棄します。
The main argument against discarding the data packet is the overall robustness of the resulting network. The main concern that has been stated is that a network running SAVI that discards data packets in this case may end up disconnecting legitimate users from the network, by filtering packets coming from them. The net result would be a degraded robustness of the network as a whole, since legitimate users would perceive this as a network failure. There are three different causes that resulted in the lack of state in the binding device for a legitimate address, namely, packet loss, state loss, and topology change. We will next perform an analysis for each of them.
データパケットの破棄に対する主な議論は、結果として得られるネットワークの全体的な堅牢性です。述べられている主な懸念は、この場合にデータパケットを破棄するSAVIを実行しているネットワークが、正規のユーザーからのパケットをフィルタリングすることにより、ネットワークから切断する可能性があることです。正当なユーザーはこれをネットワーク障害と見なすため、最終的にはネットワーク全体の堅牢性が低下します。正当なアドレスのバインディングデバイスで状態が失われる原因は3つあります。つまり、パケット損失、状態損失、およびトポロジ変更です。次に、それぞれについて分析を実行します。
The DAD procedure is inherently unreliable. It consists of sending an NS packet, and if no NA packet is received back, success is assumed, and the host starts using the address. In general, the lack of response is because no other host has that particular address configured in its interface, but it may also be the case that the NS packet or the NA packet has been lost. From the perspective of the sending host, there is no difference, and the host assumes that it can use the address. In other words, the default action is to allow the host to obtain network connectivity.
DADプロシージャは本質的に信頼できません。これはNSパケットの送信で構成され、NAパケットが返されない場合は成功と見なされ、ホストはアドレスの使用を開始します。一般に、応答がないのは、その特定のアドレスがそのインターフェースで構成されている他のホストがないためですが、NSパケットまたはNAパケットが失われた可能性もあります。送信側ホストから見ると、違いはなく、ホストはそのアドレスを使用できると見なします。つまり、デフォルトのアクションは、ホストがネットワーク接続を取得できるようにすることです。
It should be noted that the loss of a DAD packet has little impact on the network performance, since address collision is very rare, and the host assumes success in that case. By designing a SAVI solution that would discard packets for which there is no binding, we are diametrically changing the default behavior in this respect, since the default would be that if the DAD packets are lost, then the node is disconnected from the network (as its packets are filtered). What is worse, the node has little clue of what is going wrong, since it has successfully configured an address, but it has no connectivity. The net result is that the overall reliability of the network has significantly decreased as the loss of a single packet would imply that a host is disconnected from the network.
アドレスの衝突は非常にまれであり、ホストはその場合の成功を想定しているため、DADパケットの損失がネットワークパフォーマンスに与える影響はほとんどありません。バインディングがないパケットを破棄するSAVIソリューションを設計することにより、この点でデフォルトの動作を正反対に変更しています。デフォルトでは、DADパケットが失われた場合、ノードはネットワークから切断されます（パケットはフィルタリングされます）。さらに悪いことに、ノードはアドレスを正常に構成したので、接続に何もないため、問題の手掛かりがほとんどありません。単一のパケットの損失はホストがネットワークから切断されたことを意味するため、最終的な結果として、ネットワークの全体的な信頼性が大幅に低下します。
The only mechanism that the DAD has to improve its reliability is sending multiple NSs. However, [RFC4862] defines a default value of 1 NS message for the DAD procedure, so requiring any higher value would imply manual configuration of all the hosts connected to the SAVI domain.
DADが信頼性を向上させるために必要な唯一のメカニズムは、複数のNSを送信することです。ただし、[RFC4862]はDADプロシージャの1 NSメッセージのデフォルト値を定義しているため、より高い値を要求すると、SAVIドメインに接続されているすべてのホストを手動で構成することになります。
The Case of LANs
LANの事例
Devices connecting to a network may experience periods of packet loss after the link-layer becomes available for two reasons: Invalid Authentication state and incomplete topology assessment. In both cases, physical-layer connection occurs initially and presents a medium where packets are transmissible, but frame forwarding is not available across the LAN.
ネットワークに接続しているデバイスは、リンク層が使用可能になった後、無効な認証状態と不完全なトポロジー評価の2つの理由でパケット損失の期間を経験する可能性があります。どちらの場合も、最初に物理層接続が発生し、パケットを送信できるメディアを提供しますが、LAN経由でフレーム転送を利用できません。
For the authentication system, devices on a controlled port are forced to complete 802.1X authentication, which may take multiple round trips and many milliseconds to complete (see [IEEE.802-1X.2004]). In this time, initial DHCP, IPv6 Neighbor Discovery, Multicast Listener, or Duplicate Address Detection messages may be transmitted. However, it has also been noted that some devices have the ability for the IP stack to not see the port as up until 802.1X has completed. Hence, that issue needs investigation to determine how common it is now.
認証システムの場合、制御されたポート上のデバイスは802.1X認証を完了する必要があり、完了するまでに複数のラウンドトリップと数ミリ秒かかる場合があります（[IEEE.802-1X.2004]を参照）。このとき、初期DHCP、IPv6近隣探索、マルチキャストリスナー、または重複アドレス検出メッセージが送信される場合があります。ただし、一部のデバイスには、802.1Xが完了するまで、IPスタックがポートを認識しない機能があることも指摘されています。したがって、その問題は、それがどれほど一般的であるかを判断するための調査が必要です。
Additionally, any system that requires user input at this stage can extend the authentication time and thus the outage. This is problematic where hosts relying upon DHCP for address configuration time out.
さらに、この段階でユーザー入力を必要とするシステムは、認証時間を延ばすことができるため、システムが停止する可能性があります。これは、ホストがアドレス構成のタイムアウトをDHCPに依存している場合に問題になります。
Upon completion of authentication, it is feasible to signal upper-layer protocols as to LAN forwarding availability. This is not typical today, so it is necessary to assume that protocols are not aware of the preceding loss period.
認証が完了すると、LAN転送の可用性について上位層プロトコルに信号を送ることができます。これは今日では一般的ではないため、プロトコルが前の損失期間を認識していないと想定する必要があります。
For environments that do not require authentication, addition of a new link can cause loops where LAN frames are forwarded continually. In order to prevent loops, all LANs today run a spanning tree protocol, which selectively disables redundant ports. Devices that perform spanning tree calculations are either traditional Spanning Tree Protocol (STP) (see [IEEE.802-1D.1998]) or rapidly converging
認証を必要としない環境では、新しいリンクを追加すると、LANフレームが継続的に転送されるループが発生する可能性があります。ループを防止するために、今日のすべてのLANは、冗長ポートを選択的に無効にするスパニングツリープロトコルを実行しています。スパニングツリー計算を実行するデバイスは、従来のスパニングツリープロトコル（STP）（[IEEE.802-1D.1998]を参照）または高速収束のいずれかです。
versions of the same (Rapid Spanning Tree Protocol (RSTP) / Multiple Spanning Tree Protocol (RSTP)) (see [IEEE.802-1D.2004] and [IEEE.802-1Q.2005]).
同じバージョン（ラピッドスパニングツリープロトコル（RSTP）/マルチスパニングツリープロトコル（RSTP））（[IEEE.802-1D.2004]および[IEEE.802-1Q.2005]を参照）。
Until a port is determined to be an edge port (RSTP/MSTP), the rapid protocol speaker has identified its position within the spanning tree (RSTP/MSTP) or completed a Listening phase (STP), its packets are discarded.
ポートがエッジポート（RSTP / MSTP）であると判断されるまで、高速プロトコルスピーカーは、スパニングツリー（RSTP / MSTP）内の位置を特定するか、リスニングフェーズ（STP）を完了すると、そのパケットは破棄されます。
For ports that are not connected to rapid protocol switches, it takes a minimum of three seconds to perform edge port determination (see [IEEE.802-1D.2004]). Alternatively, completion of the Listening phase takes 15 seconds (see [IEEE.802-1D.1998]). During this period, the link-layer appears available, but initial packet transmissions into and out of this port will fail.
高速プロトコルスイッチに接続されていないポートの場合、エッジポートの決定には最低3秒かかります（[IEEE.802-1D.2004]を参照）。または、リスニングフェーズの完了には15秒かかります（[IEEE.802-1D.1998]を参照）。この期間中、リンク層は使用可能であるように見えますが、このポートとの間の最初のパケット送信は失敗します。
It is possible to pre-assess ports as edge ports using manual configuration of all the involved devices and thus make them immediately transmissible. This is never default behavior though.
関連するすべてのデバイスの手動構成を使用して、ポートをエッジポートとして事前評価し、その結果、それらをすぐに送信可能にすることができます。ただし、これはデフォルトの動作ではありません。
The Case of Fixed Access Networks
固定アクセスネットワークの事例
In fixed access networks such as DSL and cable, the end hosts are usually connected to the access network through a residential gateway (RG). If the host interface is initialized prior to the RG getting authenticated and connected to the access network, the access network is not aware of the DAD packets that the host sent out. As an example, in DSL networks, the Access Node (Digital Subscriber Link Access Multiplexer (DSLAM)) that needs to create and maintain binding state will never see the DAD message that is required to create such a state.
DSLやケーブルなどの固定アクセスネットワークでは、エンドホストは通常、レジデンシャルゲートウェイ（RG）を介してアクセスネットワークに接続されます。 RGが認証されてアクセスネットワークに接続される前にホストインターフェイスが初期化されている場合、アクセスネットワークは、ホストが送信したDADパケットを認識しません。例として、DSLネットワークでは、バインディング状態を作成および維持する必要があるアクセスノード（デジタルサブスクライバーリンクアクセスマルチプレクサー（DSLAM））は、そのような状態を作成するために必要なDADメッセージを決して見ません。
A particular sub-case is the one where the SAVI device itself "drops" ND packets. In order to protect itself against DoS attacks and flash-crowds, the SAVI device will have to rate limit the processing of packets triggering the state-creation process (which requires processing from the SAVI device). This implies that the SAVI device may not process all the ND packets if it is under heavy conditions. The result is that the SAVI device will fail to create a binding for a given DAD_NS packet, which implies that the data packets coming from the host that sent the DAD_NS packet will be filtered if this approach is adopted. The problem is that the host will assume that the DAD procedure was successful and will not perform the DAD procedure again, which in turn will imply that the host will be disconnected from the network. While it is true that the SAVI device will also have to rate limit the processing of the data packets, the host will keep on sending data packets, so it is possible to recover from the alternative approach where data packets trigger the binding-creation procedure.
特定のサブケースは、SAVIデバイス自体がNDパケットを「ドロップ」するケースです。 DoS攻撃やフラッシュクラウドから自身を保護するために、SAVIデバイスは、状態作成プロセスをトリガーするパケットの処理をレート制限する必要があります（SAVIデバイスからの処理が必要です）。これは、SAVIデバイスが過酷な状況にある場合、すべてのNDパケットを処理しない可能性があることを意味します。その結果、SAVIデバイスは特定のDAD_NSパケットのバインディングの作成に失敗します。これは、このアプローチが採用されている場合、DAD_NSパケットを送信したホストからのデータパケットがフィルタリングされることを意味します。問題は、ホストがDAD手順が成功したと想定し、DAD手順を再度実行しないことです。これは、ホストがネットワークから切断されることを意味します。 SAVIデバイスもデータパケットの処理をレート制限する必要があることは事実ですが、ホストはデータパケットの送信を継続するため、データパケットがバインディング作成手順をトリガーする別のアプローチから回復することができます。
If SAVI is deployed in a switched Ethernet network, topology changes may result in a SAVI device receiving packets from a legitimate user for which the SAVI device does not have a binding. Consider the following example:
SAVIがスイッチドイーサネットネットワークに配備されている場合、トポロジの変更により、SAVIデバイスがバインディングを持たない正当なユーザーからパケットを受信する可能性があります。次の例について考えてみます。
+------+ +--------+ +---------------+
|SAVI I|-------------|SWITCH I|-------|rest of the net|
+------+ +--------+ +---------------+
| |
| +--------+
| | SAVI II|
| +--------+
| +----------+ |
+---|SWITCH II |-----+
+----------+
|
+-----+
| Host|
+-----+
Figure 3: Topology Example
図3：トポロジーの例
Suppose that after bootstrapping, all the elements are working properly and the spanning tree is rooted in the router and includes one branch that follows the path SWITCH I - SAVI I - SWITCH II, and another branch that follows SWITCH I-SAVI II.
ブートストラップ後、すべての要素が適切に機能し、スパニングツリーがルータにルートされ、パスSWITCH I-SAVI I-SWITCH IIに続く1つのブランチとSWITCH I-SAVI IIに続く別のブランチが含まれているとします。
Suppose that the host boots at this moment and sends the DAD_NS. The message is propagated through the spanning tree and is received by SAVI I but not by SAVI II. SAVI I creates the binding.
この時点でホストが起動し、DAD_NSを送信するとします。メッセージはスパニングツリーを介して伝播され、SAVI IIではなくSAVI Iで受信されます。 SAVIバインディングを作成します。
Suppose that SAVI I fails and the spanning tree reconverges to SWITCH I - SAVI II - SWITCH II. Now, data packets coming from the host will be coursed through SAVI II, which does not have binding state and will drop the packets.
SAVI Iが失敗し、スパニングツリーがSWITCH I-SAVI II-SWITCH IIに再収束するとします。これで、ホストから送信されるデータパケットは、バインディング状態を持たず、パケットをドロップするSAVI IIを経由します。
The other reason a SAVI device may not have state for a legitimate address is simply because it lost it. State can be lost due to a reboot of the SAVI device or other reasons such as memory corruption. So, the situation would be as follows. The host performs the DAD procedure, and the SAVI device creates a binding for the host's address. The host successfully communicates for a while. The SAVI device reboots and loses the binding state. The packets coming from the host are now discarded as there is no binding state for that address. It should be noted that in this case, the host has been able to use the address successfully for a certain period of time.
SAVIデバイスが正当なアドレスの状態を保持していない可能性があるもう1つの理由は、アドレスが失われたためです。 SAVIデバイスの再起動またはメモリの破損などのその他の理由により、状態が失われる可能性があります。したがって、状況は次のようになります。ホストはDAD手順を実行し、SAVIデバイスはホストのアドレスのバインディングを作成します。ホストはしばらくの間正常に通信します。 SAVIデバイスが再起動し、バインド状態が失われます。そのアドレスのバインディング状態がないため、ホストからのパケットは破棄されます。この場合、ホストは一定期間、アドレスを正常に使用できたことに注意してください。
Architecturally, the degradation of the network robustness in this case can be easily explained by observing that this approach to SAVI implementation breaks the fate-sharing principle. [RFC1958] reads:
アーキテクチャ上、この場合のネットワークの堅牢性の低下は、SAVI実装へのこのアプローチが運命共有の原則を破ることを観察することで簡単に説明できます。 [RFC1958]読み取り：
An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing).
エンドツーエンドのプロトコル設計は、ネットワーク内の状態（つまり、エンドツーエンド通信の状態に関する情報）の維持に依存すべきではありません。このような状態は、エンドポイントでのみ維持する必要があります。つまり、エンドポイント自体が壊れたときにのみ状態を破棄できるようにする必要があります（運命共有と呼ばれます）。
By binding the fate of the host's connectivity to the state in the SAVI device, we are breaking this principle, and the result is degraded network resilience.
ホストの接続の運命をSAVIデバイスの状態にバインドすることにより、この原則を破り、結果としてネットワークの耐障害性が低下します。
Moving on to more practical matters, we can dig deeper into the actual behavior by considering two scenarios, namely, the case where the host is directly connected to the SAVI device and the case where there is an intermediate device between the two.
さらに実用的な問題に移り、ホストがSAVIデバイスに直接接続されている場合と、2つの間に中間デバイスが存在する場合の2つのシナリオを検討することで、実際の動作をさらに掘り下げることができます。
The considered scenario is depicted in the following diagram:
検討中のシナリオを次の図に示します。
+------+ +-----------+ +---------------+
| Host |-------------|SAVI device|-------|rest of the net|
+------+ +-----------+ +---------------+
Figure 4: Host Attached Directly to SAVI Device
図4：SAVIデバイスに直接接続されたホスト
The key distinguishing element of this scenario is that the host is directly connected to the SAVI device. As a result, if the SAVI device reboots, the host will see the carrier disappear and appear again.
このシナリオの重要な特徴は、ホストがSAVIデバイスに直接接続されていることです。その結果、SAVIデバイスが再起動すると、ホストはキャリアが消えて再び表示されるようになります。
[RFC4862] requires that the DAD procedure is performed when the IP address is assigned to the interface (see [RFC4862], Section 5.4):
[RFC4862]では、IPアドレスがインターフェースに割り当てられたときにDAD手順を実行する必要があります（[RFC4862]、セクション5.4を参照）：
Duplicate Address Detection:
重複アドレス検出：
Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions: ...
重複アドレス検出は、ステートレス自動構成、DHCPv6、または手動構成のいずれで取得されたかに関係なく、インターフェイスに割り当てる前にすべてのユニキャストアドレスで実行する必要がありますが、次の例外があります。
However, it has been stated that some of the widely used OSs actually do perform DAD each time the link is up, but further data would be required for this to be taken for granted. Assuming that behavior, this implies that if the loss of state in the SAVI device also results in the link to the host going down, then the host using the tested OSs would redo the DAD procedure allowing the recreation of the binding state in the SAVI device and preserving the connectivity of the host. This would be the case if the SAVI device reboots. It should be noted, however, that it is also possible that the binding state is lost because of an error in the SAVI process and that the SAVI link does not goes down. In this case, the host would not redo the DAD procedure. However, it has been pointed out that it would be possible to require the SAVI process to flap the links of the device it is running, in order to make sure that the link goes down each time the SAVI process restarts and to improve the chances the host will redo the DAD procedure when the SAVI process is rebooted.
ただし、広く使用されている一部のOSは、リンクがアップするたびに実際にDADを実行することが述べられていますが、これを当然のことと見なすには、さらにデータが必要になります。その動作を想定すると、これは、SAVIデバイスでの状態の損失によりホストへのリンクもダウンする場合、テスト済みのOSを使用するホストがDAD手順をやり直して、SAVIデバイスでのバインディング状態の再作成を可能にすることを意味しますホストの接続を維持します。これは、SAVIデバイスが再起動する場合に当てはまります。ただし、SAVIプロセスのエラーが原因でバインディング状態が失われ、SAVIリンクがダウンしないこともあることに注意してください。この場合、ホストはDAD手順をやり直しません。ただし、SAVIプロセスが再起動するたびにリンクがダウンすることを確認し、SAVIプロセスの可能性を向上させるために、実行中のデバイスのリンクをフラップするようにSAVIプロセスに要求することが可能であることが指摘されていますSAVIプロセスが再起動されると、ホストはDAD手順をやり直します。
A.1.3.2. The Case of a Host Connected to the SAVI Device through One or More Legacy Devices
A.1.3.2. ホストが1つ以上のレガシーデバイスを介してSAVIデバイスに接続されているケース
The considered scenario is depicted in the following diagram:
検討中のシナリオを次の図に示します。
+------+ +-------------+ +-----------+ +---------------+
| Host |----|Legacy device|-----|SAVI device|----|rest of the net|
+------+ +-------------+ +-----------+ +---------------+
Figure 5: Host Attached to a Legacy Device
図5：レガシーデバイスに接続されたホスト
The key distinguishing element of this scenario is that the host is not directly connected to the SAVI device. As a result, if the SAVI device reboots, the host will not see any changes.
このシナリオの重要な特徴は、ホストがSAVIデバイスに直接接続されていないことです。その結果、SAVIデバイスが再起動した場合、ホストは変更を認識しません。
In this case, the host would get disconnected from the rest of the network since the SAVI device would filter all its packets once the state has gone. As the node will not perform the DAD procedure again, it will remain disconnected until it reboots.
この場合、状態がなくなるとSAVIデバイスがすべてのパケットをフィルタリングするため、ホストは残りのネットワークから切断されます。ノードはDAD手順を再度実行しないため、再起動するまで切断されたままになります。
As a final comment, it should be noted that it may not be obvious to the network admin which scenario its network is running. Consider the case of a campus network where all the switches in the network are SAVI capable. A small hub connected in the office would turn this into the scenario where the host is not directly connected to the SAVI device. Moreover, consider the case of a host running multiple virtual machines connected through a virtual hub. Depending on the implementation of such a virtual hub, this may turn a directly connected host scenario to the scenario where the multiple (virtual) hosts are connected through a legacy (virtual) hub.
最後のコメントとして、ネットワークがどのシナリオで実行されているかはネットワーク管理者には明らかでない場合があることに注意してください。ネットワーク内のすべてのスイッチがSAVI対応であるキャンパスネットワークの場合を考えます。オフィスに接続された小さなハブは、これをホストがSAVIデバイスに直接接続されていないシナリオに変えます。さらに、ホストが仮想ハブを介して接続された複数の仮想マシンを実行している場合を考えます。このような仮想ハブの実装によっては、直接接続されたホストのシナリオが、複数の（仮想）ホストがレガシー（仮想）ハブを介して接続されるシナリオに変わる可能性があります。
A.1.3.2.1. Enforcing Direct Connectivity between the SAVI Device and the Host
A.1.3.2.1. SAVIデバイスとホスト間の直接接続の実施
It has been argued that enforcing direct connectivity between the SAVI device and the end host is actually a benefit. There are several comments that can be made in this respect:
SAVIデバイスとエンドホスト間の直接接続を強制することは実際には利点であると主張されてきました。この点については、いくつかのコメントがあります。
o First, it may well be the case in some scenarios that this is desirable, but it is certainly not the case in most scenarios. Because of that, the issue of enforcing direct connectivity must be treated as orthogonal to how data packets for which there is no binding are treated, since a general solution must support directly connected nodes and nodes connected through legacy switches.
o 最初に、これが望ましいシナリオである場合もありますが、ほとんどのシナリオではそうではありません。そのため、一般的なソリューションでは、直接接続されたノードとレガシースイッチを介して接続されたノードをサポートする必要があるため、直接接続の強制の問題は、バインディングがないデータパケットの処理方法とは直交して扱う必要があります。
o Second, as a matter of fact, the resulting behavior described above would not actually enforce direct connectivity between the end host and the SAVI device as it would work as long as the SAVI device does not reboot. So, the argument being made is that this approach is not good enough to provide a robust network service, but it is not bad enough to enforce the direct connectivity of the host to the SAVI switch.
o 第2に、実際には、SAVIデバイスが再起動しない限り機能するため、上記の結果として生じる動作は実際にはエンドホストとSAVIデバイス間の直接接続を強制しません。そのため、このアプローチは堅牢なネットワークサービスを提供するには十分ではないが、ホストからSAVIスイッチへの直接接続を強制するには不十分ではないという主張がなされています。
o Third, it should be noted that topology enforcement is not part of the SAVI problem space and that the SAVI problem by itself is complex enough without adding additional requirements.
o 第3に、トポロジの強制はSAVI問題空間の一部ではなく、SAVI問題自体は、追加の要件を追加しなくても十分に複雑であることに注意してください。
The FCFS SAVI mechanism is composed of two main functions, namely, the mechanisms for tracking compliant and non-compliant data packets and the actions to be performed upon the detection of a non-compliant packet. Throughout this specification, we recommend discarding non-compliant data packets. This is because forwarding non-compliant data packets is essentially allowing packets with spoofed source addresses to flow throughout the network. However, there are alternative actions that can be taken with respect to these packets.
FCFS SAVIメカニズムは、2つの主要な機能、つまり、準拠および非準拠のデータパケットを追跡するメカニズムと、非準拠パケットの検出時に実行されるアクションで構成されます。この仕様全体を通して、非準拠のデータパケットを破棄することをお勧めします。これは、非準拠のデータパケットを転送することにより、発信元アドレスが偽装されたパケットがネットワーク全体に流れることが本質的に可能になるためです。ただし、これらのパケットに対して実行できる代替アクションがあります。
For instance, it would be possible to forward the packets and trigger an alarm to network administrators to make them aware of the situation. Similarly, it would be possible to log these events and allow the tracking down cases where packets with spoofed addresses were used for malicious purposes. The reason a site deploying SAVI may not want to take milder actions like the ones mentioned above instead of discarding packets is because there may be cases where the non-compliant packets may be legitimate packets (for example, in the case that the SAVI device is malfunctioning and has failed to create the appropriate bindings upon the reception of a DAD packet).
たとえば、パケットを転送し、ネットワーク管理者にアラームをトリガーして、状況を知らせることができます。同様に、これらのイベントをログに記録し、アドレスが偽装されたパケットが悪意のある目的で使用された場合の追跡追跡を可能にすることができます。 SAVIを展開しているサイトが、パケットを破棄するのではなく、上記のような穏やかなアクションを実行したくない理由は、非準拠パケットが正当なパケットである可能性があるためです（たとえば、SAVIデバイスが誤動作し、DADパケットの受信時に適切なバインディングを作成できませんでした）。
Authors' Addresses
著者のアドレス
Erik Nordmark Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States
Erik Nordmark Cisco Systems 510 McCarthy Blvd.ミルピタス、CA 95035アメリカ合衆国
EMail: nordmark@acm.org
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
Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410 France
エリックレヴィアベニョリシスコシステムズビレッジデントレプリスグリーンサイド-400、アベニュールーマニールビオソフィアアンチポリス-06410フランス
EMail: elevyabe@cisco.com