[要約] RFC 7513は、DHCPにおけるソースアドレスの検証改善（SAVI）ソリューションに関する規格です。その目的は、不正なソースアドレスの使用を防ぎ、ネットワークのセキュリティを向上させることです。
Internet Engineering Task Force (IETF) J. Bi
Request for Comments: 7513 J. Wu
Category: Standards Track G. Yao
ISSN: 2070-1721 Tsinghua Univ.
F. Baker
Cisco
May 2015
Source Address Validation Improvement (SAVI) Solution for DHCP
DHCPのソースアドレス検証改善（SAVI）ソリューション
Abstract
概要
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.
このドキュメントでは、DHCPv4 / DHCPv6によって割り当てられたIPアドレスと、Source Address Validation Improvement（SAVI）デバイスのバインディングアンカーとの間のバインディングを作成する手順について説明します。この手順で設定されたバインディングは、偽造された送信元IPアドレスを持つパケットをフィルタリングするために使用されます。このメカニズムは、BCP 38（RFC 2827）入力フィルタリングを補完し、より細かいソースIPアドレス検証を提供します。
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/rfc7513.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7513で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment Scenario and Configuration . . . . . . . . . . . . 8
4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8
4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 10
4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10
4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 11
4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 12
4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 13
4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13
4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14
4.3.3. On the Placement of the DHCP Server and Relay . . . . 15
4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15
4.3.5. Considerations regarding Binding Anchors . . . . . . 16
4.4. Other Device Configuration . . . . . . . . . . . . . . . 17
5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17
6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18
6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Binding States Description . . . . . . . . . . . . . . . 19
6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19
6.3.2. Control Message Arriving Events . . . . . . . . . . . 19
6.4. The State Machine of DHCP Snooping Process . . . . . . . 21
6.4.1. Initial State: NO_BIND . . . . . . . . . . . . . . . 21
6.4.2. Initial State: INIT_BIND . . . . . . . . . . . . . . 24
6.4.3. Initial State: BOUND . . . . . . . . . . . . . . . . 27
6.4.4. Table of State Machine . . . . . . . . . . . . . . . 30
7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 31
7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3. Additional Binding States Description . . . . . . . . . . 33
7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5. Message Sender Functions . . . . . . . . . . . . . . . . 35
7.5.1. Duplicate Detection Message Sender . . . . . . . . . 35
7.5.2. Leasequery Message Sender . . . . . . . . . . . . . . 36
7.5.3. Address Verification Message Sender . . . . . . . . . 36
7.6. Initial State: NO_BIND . . . . . . . . . . . . . . . . . 37
7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a
matched binding is received . . . . . . . . . . . . . 37
7.6.2. Events Not Observed in NO_BIND for Data Snooping . . 38
7.7. Initial State: DETECTION . . . . . . . . . . . . . . . . 39
7.7.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 39
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message
Received from Unexpected System . . . . . . . . . . . 39
7.7.3. Events Not Observed in DETECTION . . . . . . . . . . 39
7.8. Initial State: RECOVERY . . . . . . . . . . . . . . . . . 40
7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 40
7.8.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 41
7.8.3. Events Not Observed in RECOVERY . . . . . . . . . . . 41
7.9. Initial State: VERIFY . . . . . . . . . . . . . . . . . . 41
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 41
7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is
received from the device attached via the binding
anchor . . . . . . . . . . . . . . . . . . . . . . . 42
7.9.3. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 42
7.9.4. Event: EVE_DATA_EXPIRE . . . . . . . . . . . . . . . 43
7.9.5. Events Not Observed in VERIFY . . . . . . . . . . . . 43
7.10. Initial State: BOUND . . . . . . . . . . . . . . . . . . 43
7.11. Table of State Machine . . . . . . . . . . . . . . . . . 44
8. Filtering Specification . . . . . . . . . . . . . . . . . . . 45
8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 46
8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 46
9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Attribute Configuration Restoration . . . . . . . . . . . 47
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 47
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Security Problems with the Data Snooping Process . . . . 48
11.2. Securing Leasequery Operations . . . . . . . . . . . . . 49
11.3. Client Departure Issues . . . . . . . . . . . . . . . . 49
11.4. Compatibility with Detecting Network Attachment (DNA) . 50
11.5. Binding Number Limitation . . . . . . . . . . . . . . . 51
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 51
11.7. Fragmented DHCP Messages . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
This document describes a fine-grained source address validation mechanism for IPv4 and IPv6 packets. This mechanism creates bindings between IP addresses assigned to network interfaces by DHCP and suitable binding anchors (Section 4.3.5). As discussed in Section 3 and [RFC7039], a "binding anchor" is an attribute that is immutable or difficult to change that may be used to identify the system an IP address has been assigned to; common examples include a Media Access Control (MAC) address found on an Ethernet switch port or Wi-Fi security association. The bindings are used to identify and filter packets originated by these interfaces using forged source IP addresses. In this way, this mechanism can prevent hosts from using IP addresses assigned to any other attachment point in or not associated with the network. This behavior is referred to as "spoofing" and is key to amplification attacks, in which a set of systems send messages to another set of systems claiming to be from a third set of systems, and sending the replies to systems that don't expect them. Whereas BCP 38 [RFC2827] protects a network from a neighboring network by providing prefix granularity source IP address validity, this mechanism protects a network, including a Local Area Network, from itself by providing address granularity source IP validity when DHCP/DHCPv6 is used to assign IPv4/IPv6 addresses. Both provide a certain level of traceability, in that packet drops indicate the presence of a system that is producing packets with spoofed IP addresses.
このドキュメントでは、IPv4およびIPv6パケットの詳細な送信元アドレス検証メカニズムについて説明します。このメカニズムは、DHCPによってネットワークインターフェイスに割り当てられたIPアドレスと適切なバインディングアンカーの間にバインディングを作成します（セクション4.3.5）。セクション3および[RFC7039]で説明されているように、「バインディングアンカー」は、IPアドレスが割り当てられているシステムを識別するために使用できる、不変または変更が難しい属性です。一般的な例には、イーサネットスイッチポートまたはWi-Fiセキュリティアソシエーションで見つかったメディアアクセスコントロール（MAC）アドレスが含まれます。バインディングは、偽造された送信元IPアドレスを使用して、これらのインターフェースから発信されたパケットを識別およびフィルタリングするために使用されます。このようにして、このメカニズムにより、ホストがネットワーク内またはネットワークに関連付けられていない他の接続ポイントに割り当てられたIPアドレスを使用するのを防ぐことができます。この動作は「スプーフィング」と呼ばれ、増幅攻撃の鍵となります。この攻撃では、一連のシステムが、3番目のシステムのセットからのものであると主張する別のシステムのセットにメッセージを送信し、予期しないシステムに応答を送信します。それら。 BCP 38 [RFC2827]は、プレフィックスの粒度のソースIPアドレスの有効性を提供することにより、隣接ネットワークからネットワークを保護しますが、このメカニズムは、ローカルエリアネットワークを含むネットワークを、DHCP / DHCPv6がIPv4 / IPv6アドレスを割り当てます。どちらも、特定のレベルの追跡可能性を提供します。パケットのドロップは、IPアドレスが偽装されたパケットを生成しているシステムの存在を示します。
SAVI-DHCP snoops DHCP address assignments to set up bindings between IP addresses assigned by DHCP and corresponding binding anchors. It includes the DHCPv4 and DHCPv6 Snooping Process (Section 6) and the Data Snooping Process (Section 7), as well as a number of other technical details. The Data Snooping Process is a data-triggered procedure that snoops the IP header of data packets to set up bindings. It is designed to avoid a permanent blockage of valid addresses in the case that DHCP snooping is insufficient to set up all the valid bindings.
SAVI-DHCPはDHCPアドレス割り当てをスヌーピングして、DHCPによって割り当てられたIPアドレスと対応するバインディングアンカー間のバインディングをセットアップします。 DHCPv4およびDHCPv6スヌーピングプロセス（セクション6）とデータスヌーピングプロセス（セクション7）だけでなく、他の多くの技術的な詳細も含まれています。データスヌーピングプロセスは、データパケットのIPヘッダーをスヌーピングしてバインディングをセットアップするデータトリガープロシージャです。これは、DHCPスヌーピングがすべての有効なバインディングをセットアップするのに不十分である場合に、有効なアドレスの永続的なブロックを回避するように設計されています。
This mechanism is designed for the stateful DHCP scenario [RFC2131] [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this document, as it has nothing to do with IP address allocation. An alternative SAVI method would have be used in those cases. For hosts using Stateless Address Autoconfiguration (SLAAC) to allocate addresses, First-Come, First-Served Source Address Validation Improvement (FCFS SAVI) [RFC6620] should be enabled. SAVI-DHCP is primarily designed for pure DHCP scenarios in which only addresses assigned through DHCP are allowed. However, it does not block link- local addresses, as they are not assigned using DHCP. It is RECOMMENDED that the administration deploy a SAVI solution for link-local addresses, e.g., FCFS SAVI [RFC6620].
このメカニズムは、ステートフルDHCPシナリオ[RFC2131] [RFC3315]用に設計されています。ステートレスDHCP [RFC3736]は、IPアドレスの割り当てとは関係がないため、このドキュメントの範囲外です。そのような場合は、代替のSAVIメソッドが使用されます。ステートレスアドレス自動構成（SLAAC）を使用してアドレスを割り当てるホストの場合、先着順の送信元アドレス検証の改善（FCFS SAVI）[RFC6620]を有効にする必要があります。 SAVI-DHCPは主に、DHCPを通じて割り当てられたアドレスのみが許可される純粋なDHCPシナリオ用に設計されています。ただし、DHCPを使用して割り当てられていないため、リンクローカルアドレスはブロックされません。 FCFS SAVI [RFC6620]などのリンクローカルアドレス用のSAVIソリューションを管理者が展開することをお勧めします。
This mechanism works for networks that use DHCPv4 only, DHCPv6 only, or both DHCPv4 and DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6 transition scenarios, e.g., [RFC7341], are beyond the scope of this document.
このメカニズムは、DHCPv4のみ、DHCPv6のみ、またはDHCPv4とDHCPv6の両方を使用するネットワークで機能します。ただし、IPv4 / IPv6移行シナリオのDHCPアドレス割り当てメカニズム（[RFC7341]など）は、このドキュメントの範囲を超えています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Binding anchor: A "binding anchor" is defined to be a physical and/or link-layer property of an attached device, as in [RFC7039]. A list of sample binding anchors can be found in Section 3.2 of that document. To the degree possible, a binding anchor associates an IP address with something unspoofable that identifies a single-client system or one of its interfaces. See Section 4.3.5 for more detail.
バインディングアンカー：「バインディングアンカー」は、[RFC7039]のように、接続されたデバイスの物理プロパティまたはリンクレイヤプロパティ、あるいはその両方として定義されます。サンプルのバインディングアンカーのリストは、そのドキュメントのセクション3.2にあります。可能な限り、バインディングアンカーは、IPアドレスを、単一クライアントシステムまたはそのインターフェイスの1つを識別する偽装できないものに関連付けます。詳細については、4.3.5項を参照してください。
Attribute: A configurable property of each binding anchor (port, MAC address, or other information) that indicates the actions to be performed on packets received from the attached network device.
属性：接続されているネットワークデバイスから受信したパケットに対して実行されるアクションを示す、各バインディングアンカーの構成可能なプロパティ（ポート、MACアドレス、またはその他の情報）。
DHCP address: An IP address assigned via DHCP.
DHCPアドレス：DHCP経由で割り当てられたIPアドレス。
SAVI-DHCP: The name of this SAVI function for DHCP-assigned addresses.
SAVI-DHCP：DHCP割り当てアドレス用のこのSAVI機能の名前。
SAVI device: A network device on which SAVI-DHCP is enabled.
SAVIデバイス：SAVI-DHCPが有効になっているネットワークデバイス。
Non-SAVI device: A network device on which SAVI-DHCP is not enabled.
非SAVIデバイス：SAVI-DHCPが有効になっていないネットワークデバイス。
DHCP Client-to-Server message: A message that is sent from a DHCP client to a DHCP server or DHCP servers and is one of the following types:
DHCPクライアントからサーバーへのメッセージ：DHCPクライアントからDHCPサーバーに送信されるメッセージで、次のいずれかのタイプです。
o DHCPv4 Discover: DHCPDISCOVER [RFC2131].
o DHCPv4検出：DHCPDISCOVER [RFC2131]。
o DHCPv4 Request: DHCPREQUEST generated during SELECTING state [RFC2131].
o DHCPv4要求：DHCPREQUESTがSELECTING状態で生成されました[RFC2131]。
o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state [RFC2131].
o DHCPv4 Renew：DHCPREQUESTはRENEWING状態中に生成されます[RFC2131]。
o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state [RFC2131].
o DHCPv4再バインド：REBINDING状態中に生成されたDHCPREQUEST [RFC2131]。
o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state [RFC2131].
o DHCPv4再起動：INIT-REBOOT状態中に生成されたDHCPREQUEST [RFC2131]。
o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be identified based on Table 4 of [RFC2131].
o 注：DHCPv4要求/更新/再バインド/再起動メッセージは、[RFC2131]の表4に基づいて識別できます。
o DHCPv4 Decline: DHCPDECLINE [RFC2131].
o DHCPv4拒否：DHCPDECLINE [RFC2131]。
o DHCPv4 Release: DHCPRELEASE [RFC2131].
o DHCPv4リリース：DHCPRELEASE [RFC2131]。
o DHCPv4 Inform: DHCPINFORM [RFC2131].
o DHCPv4通知：DHCPINFORM [RFC2131]。
o DHCPv4 DHCPLEASEQUERY: A message sent to inquire about the lease that might exist for an IPv4 address [RFC4388].
o DHCPv4 DHCPLEASEQUERY：IPv4アドレス[RFC4388]に存在する可能性のあるリースについて問い合わせるために送信されるメッセージ。
o DHCPv6 Request: REQUEST [RFC3315].
o DHCPv6要求：要求[RFC3315]。
o DHCPv6 Solicit: SOLICIT [RFC3315].
o DHCPv6要請：SOLICIT [RFC3315]。
o DHCPv6 Confirm: CONFIRM [RFC3315].
o DHCPv6確認：CONFIRM [RFC3315]。
o DHCPv6 Decline: DECLINE [RFC3315].
o DHCPv6拒否：DECLINE [RFC3315]。
o DHCPv6 Release: RELEASE [RFC3315].
o DHCPv6リリース：RELEASE [RFC3315]。
o DHCPv6 Rebind: REBIND [RFC3315].
o DHCPv6再バインド：REBIND [RFC3315]。
o DHCPv6 Renew: RENEW [RFC3315].
o DHCPv6更新：RENEW [RFC3315]。
o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315].
o DHCPv6情報要求：INFORMATION-REQUEST [RFC3315]。
o DHCPv6 LEASEQUERY: A message sent to inquire about the lease that might exist for an IPv6 address [RFC5007].
o DHCPv6 LEASEQUERY：IPv6アドレス[RFC5007]に存在する可能性のあるリースについて問い合わせるために送信されるメッセージ。
DHCP Server-to-Client message: A message that is sent from a DHCP server to a DHCP client and is one of the following types:
DHCPサーバーからクライアントへのメッセージ：DHCPサーバーからDHCPクライアントに送信されるメッセージで、次のいずれかのタイプです。
o DHCPv4 ACK: DHCPACK [RFC2131].
o DHCPv4 ACK：DHCPACK [RFC2131]。
o DHCPv4 NAK: DHCPNAK [RFC2131].
o DHCPv4 NAK：DHCPNAK [RFC2131]。
o DHCPv4 Offer: DHCPOFFER [RFC2131].
o DHCPv4オファー：DHCPOFFER [RFC2131]。
o DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request containing lease information [RFC4388].
o DHCPv4 DHCPLEASEACTIVE：リース情報を含むDHCPLEASEQUERY要求への応答[RFC4388]。
o DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request indicating that the server does not manage the address [RFC4388].
o DHCPv4 DHCPLEASEUNKNOWN：サーバーがアドレスを管理していないことを示すDHCPLEASEQUERY要求への応答[RFC4388]。
o DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY request indicating that the server manages the address and there is no current lease [RFC4388].
o DHCPv4 DHCPLEASEUNASSIGNED：サーバーがアドレスを管理し、現在のリースがないことを示すDHCPLEASEQUERY要求への応答[RFC4388]。
o DHCPv6 Reply: REPLY [RFC3315].
o DHCPv6応答：返信[RFC3315]。
o DHCPv6 Advertise: ADVERTISE [RFC3315].
o DHCPv6アドバタイズ：ADVERTISE [RFC3315]。
o DHCPv6 Reconfigure: RECONFIGURE [RFC3315].
o DHCPv6再構成：RECONFIGURE [RFC3315]。
o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request [RFC5007].
o DHCPv6 LEASEQUERY-REPLY：LEASEQUERY要求への応答[RFC5007]。
Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in IPv6 [RFC3315].
リース時間：IPv4 [RFC2131]のリース時間、またはIPv6 [RFC3315]の有効期間。
Binding entry: A rule that associates an IP address with a binding anchor.
バインディングエントリ：IPアドレスをバインディングアンカーに関連付けるルール。
Binding State Table (BST): The data structure that contains the binding entries.
バインディングステートテーブル（BST）：バインディングエントリを含むデータ構造。
Binding entry limit: The maximum number of binding entries that may be associated with a binding anchor. Limiting the number of binding entries per binding anchor prevents a malicious or malfunctioning node from overloading the binding table on a SAVI device.
バインディングエントリの制限：バインディングアンカーに関連付けることができるバインディングエントリの最大数。バインディングアンカーごとのバインディングエントリの数を制限することで、悪意のあるノードまたは誤動作しているノードがSAVIデバイスのバインディングテーブルに過負荷をかけることを防ぎます。
Direct attachment: Ideally, a SAVI device is an access device that hosts are attached to directly. In such a case, the hosts are direct attachments (i.e., they attach directly) to the SAVI device.
直接接続：SAVIデバイスは、ホストが直接接続されるアクセスデバイスであることが理想的です。このような場合、ホストはSAVIデバイスに直接接続されます（つまり、直接接続されます）。
Indirect attachment: A SAVI device MAY be an aggregation device that other access devices are attached to and that hosts in turn attach to. In such a case, the hosts are indirect attachments (i.e., they attach indirectly) to the SAVI device.
間接接続：SAVIデバイスは、他のアクセスデバイスが接続され、ホストが順番に接続する集約デバイスである場合があります。このような場合、ホストはSAVIデバイスに間接的にアタッチされます（つまり、間接的にアタッチされます）。
Unprotected link: Unprotected links are links that connect to hosts or networks of hosts that receive their DHCP traffic by another path and are therefore outside the SAVI perimeter.
保護されていないリンク：保護されていないリンクは、別のパスによってDHCPトラフィックを受信するホストまたはホストのネットワークに接続するリンクであるため、SAVI境界の外側にあります。
Unprotected device: An unprotected device is a device associated with an unprotected link. One example might be the gateway router of a network.
保護されていないデバイス：保護されていないデバイスは、保護されていないリンクに関連付けられているデバイスです。 1つの例は、ネットワークのゲートウェイルーターです。
Protected link: If DHCP messages for a given attached device always use a given link, the link is considered to be "protected" by the SAVI device and is therefore within the SAVI perimeter.
保護されたリンク：特定の接続デバイスのDHCPメッセージが常に特定のリンクを使用する場合、そのリンクはSAVIデバイスによって「保護されている」と見なされるため、SAVI境界内にあります。
Protected device: A protected device is a device associated with a protected link. One example might be a desktop switch in the network, or a host.
保護されたデバイス：保護されたデバイスは、保護されたリンクに関連付けられたデバイスです。 1つの例は、ネットワーク内のデスクトップスイッチ、またはホストです。
Cut vertex: A cut vertex is any vertex whose removal increases the number of connected components in a (network) graph. This is a concept in graph theory. This term is used in Section 6.1 to accurately specify the required deployment location of SAVI devices when they only perform the DHCP Snooping Process.
カット頂点：カット頂点とは、その削除によって（ネットワーク）グラフ内の接続されたコンポーネントの数が増える任意の頂点です。これはグラフ理論の概念です。この用語はセクション6.1で使用され、DHCPスヌーピングプロセスのみを実行する場合にSAVIデバイスの必要な配置場所を正確に指定します。
Identity Association (IA): "A collection of addresses assigned to a client" [RFC3315].
Identity Association（IS）：「クライアントに割り当てられたアドレスのコレクション」[RFC 3315]。
Detection message: A Neighbor Solicitation or ARP message intended by the Data Snooping Process to detect a duplicate address.
検出メッセージ：データスヌーピングプロセスが重複アドレスを検出することを目的とした近隣要請またはARPメッセージ。
DHCP_DEFAULT_LEASE: Default lifetime for a DHCPv6 address when the binding is triggered by a DHCPv6 Confirm message but a DHCPv6 Leasequery exchange [RFC5007] cannot be performed by the SAVI device to fetch the lease.
DHCP_DEFAULT_LEASE：バインディングがDHCPv6確認メッセージによってトリガーされたが、DHCPv6 Leasequery交換[RFC5007]がリースをフェッチするためにSAVIデバイスによって実行できない場合のDHCPv6アドレスのデフォルトのライフタイム。
The essential elements in a SAVI-DHCP deployment scenario include at least one DHCP server (which may or may not be assigned an address using DHCP and therefore may or may not be protected), zero or more protected DHCP clients, and one or more SAVI devices. It may also include DHCP relays, when the DHCP server is not co-located with a set of clients, and zero or more protected non-SAVI devices. Outside the perimeter, via unprotected links, there may be many unprotected devices.
SAVI-DHCP展開シナリオの重要な要素には、少なくとも1つのDHCPサーバー（DHCPを使用してアドレスが割り当てられる場合と割り当てられない場合があるため保護される場合とされない場合があります）、0個以上の保護されたDHCPクライアント、および1つ以上のSAVIが含まれますデバイス。また、DHCPサーバーがクライアントのセットと同じ場所に配置されていない場合は、DHCPリレー、および0個以上の保護された非SAVIデバイスが含まれる場合があります。保護されていないリンクを介して境界の外側に、保護されていないデバイスが多数存在する可能性があります。
+-------------+
| Unprotected |
| Device |
+------+------+
|
+--------+ +-----+------+ +----------+
|DHCP +-----+ Non-SAVI +----+Bogus DHCP|
|Server A| | Device 1 | |Server |
+--------+ +-----+------+ +----------+
|trusted, unprotected link
. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. | .
. Protection +---+------+ trusted link .
. Perimeter | SAVI +--------------+ .
. | Device C | | .
. +---+------+ | .
. | | .
. untrusted, +----------+ +---+------+ +------+---+ .
. protected | SAVI | | Non-SAVI | | SAVI | .
. link+------+ Device A +----+ Device 3 +-------+ Device B | .
. | +----+--+--+ +----------+ +-+---+----+ .
. | | +----------+ . . . . . | | .
. | . . . . . . | . . | | .
. | . | . | . +--------+ | .
. +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ .
. | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | .
. | Device 2 |. |A | . |Relay | . |B | . |Server B| .
. +----------+. +------+ . +------+ . +------+ . +--------+ .
. . . . . . . . . . . . . . . . . . .
Figure 1: SAVI-DHCP Scenario
図1：SAVI-DHCPシナリオ
Figure 1 shows a deployment scenario that contains these elements. Note that a physical device can instantiate multiple elements, e.g., a switch can be both a SAVI device and a DHCP relay, or in a cloud-computing environment, a physical host may contain a virtual switch plus some number of virtual hosts. In such cases, the links are logical links rather than physical links.
図1は、これらの要素を含む展開シナリオを示しています。物理デバイスは複数の要素をインスタンス化できることに注意してください。たとえば、スイッチはSAVIデバイスとDHCPリレーの両方にすることができます。または、クラウドコンピューティング環境では、物理ホストに仮想スイッチといくつかの仮想ホストを含めることができます。このような場合、リンクは物理リンクではなく論理リンクです。
Networks are not usually isolated. As a result, traffic from other networks, including transit traffic as specified in [RFC6620] (e.g., traffic from another SAVI switch or a router) may enter a SAVI-DHCP network through the unprotected links. Since SAVI solutions are limited to validating traffic generated from a local link, SAVI-DHCP does not set up bindings for addresses assigned in other networks and cannot validate them. Traffic from unprotected links should be checked by an unprotected device or mechanisms described in
通常、ネットワークは分離されていません。その結果、[RFC6620]で指定されたトランジットトラフィックを含む他のネットワークからのトラフィック（別のSAVIスイッチまたはルーターからのトラフィックなど）は、保護されていないリンクを介してSAVI-DHCPネットワークに入る可能性があります。 SAVIソリューションはローカルリンクから生成されたトラフィックの検証に限定されているため、SAVI-DHCPは他のネットワークで割り当てられたアドレスのバインディングを設定せず、検証できません。保護されていないリンクからのトラフィックは、で説明されている保護されていないデバイスまたはメカニズムによってチェックする必要があります。
[RFC2827]. The generation and deployment of such a mechanism is beyond the scope of this document.
[RFC2827]。そのようなメカニズムの生成と展開は、このドキュメントの範囲を超えています。
Traffic from protected links is, however, locally generated and should have its source addresses validated by SAVI-DHCP if possible. In the event that there is an intervening protected non-SAVI device between the host and the SAVI device, however, use of the physical attachment point alone as a binding anchor is insufficiently secure, as several devices on a port or other point of attachment can spoof each other. Hence, additional information such as a MAC address SHOULD be used to disambiguate them.
ただし、保護されたリンクからのトラフィックはローカルで生成されるため、可能であればSAVI-DHCPによって送信元アドレスを検証する必要があります。ただし、ホストとSAVIデバイスの間に保護された非SAVIデバイスが介在している場合、バインディングアンカーとしての物理接続ポイントだけの使用は、ポートまたは他の接続ポイントの複数のデバイスが互いになりすまします。したがって、MACアドレスなどの追加情報を使用して、それらを明確にする必要があります（SHOULD）。
As illustrated in Figure 1, a system attached to a SAVI device can be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI device. Different actions are performed on traffic originated from different elements. To distinguish among their requirements, several properties are associated with their point of attachment on the SAVI device.
図1に示すように、SAVIデバイスに接続されたシステムは、DHCPクライアント、DHCPリレー/サーバー、SAVIデバイス、または非SAVIデバイスです。さまざまな要素から発信されたトラフィックに対して、さまざまなアクションが実行されます。それらの要件を区別するために、いくつかのプロパティがSAVIデバイス上の接続点に関連付けられています。
When a binding association is uninstantiated, e.g., when no host is attached to the SAVI device using a given port or other binding anchor, the binding port attributes take default values unless overridden by configuration. By default, a SAVI switch does not filter DHCP messages, nor does it attempt to validate source addresses, which is to say that the binding attributes are ignored until SAVI-DHCP is itself enabled. This is because a SAVI switch that depends on DHCP cannot tell, a priori, which ports have valid DHCP servers attached, or which have routers or other equipment that would validly appear to use an arbitrary set of source addresses. When SAVI has been enabled, the attributes take effect.
バインディングの関連付けがインスタンス化されていない場合、たとえば、特定のポートまたは他のバインディングアンカーを使用してSAVIデバイスにホストが接続されていない場合、バインディングポート属性は、構成でオーバーライドされない限り、デフォルト値を取ります。デフォルトでは、SAVIスイッチはDHCPメッセージをフィルタリングせず、送信元アドレスの検証も試みません。つまり、SAVI-DHCPが有効になるまでバインディング属性は無視されます。これは、DHCPに依存するSAVIスイッチでは、有効なDHCPサーバーが接続されているポートや、任意の送信元アドレスセットを使用しているように見えるルーターやその他の機器をアプリオリに判断できないためです。 SAVIを有効にすると、属性が有効になります。
The "Trust Attribute" is a Boolean value. If TRUE, it indicates that the packets from the corresponding attached device need not have their source addresses validated. Examples of a trusted attachment would be a port to another SAVI device, or to an IP router, as shown in Figure 1. In both cases, traffic using many source IP addresses will be seen. By default, the Trust attribute is FALSE, indicating that any device found on that port will seek an address using DHCP and be limited to using such addresses.
「信頼属性」はブール値です。 TRUEの場合、対応する接続デバイスからのパケットの送信元アドレスを検証する必要がないことを示します。信頼できるアタッチメントの例は、図1に示すように、別のSAVIデバイスまたはIPルーターへのポートです。どちらの場合も、多くの送信元IPアドレスを使用するトラフィックが表示されます。デフォルトでは、信頼属性はFALSEで、そのポートで検出されたデバイスはDHCPを使用してアドレスを検索し、そのようなアドレスの使用に制限されることを示します。
SAVI devices will not set up bindings for points of attachment with the Trust attribute set TRUE; no packets, including DHCP messages, from devices with this attribute on their attachments will be validated. However, DHCP Server-to-Client messages will be snooped on attachment points with the Trust attribute set TRUE in the same way as if they had the DHCP-Trust attribute set (see Section 4.2.2).
SAVIデバイスは、Trust属性がTRUEに設定された接続ポイントのバインディングを設定しません。添付ファイルにこの属性を持つデバイスからのパケット（DHCPメッセージを含む）は検証されません。ただし、DHCPサーバーからクライアントへのメッセージは、Trust属性がTRUEに設定されている接続ポイントで、DHCP-Trust属性が設定されている場合と同じようにスヌーピングされます（セクション4.2.2を参照）。
The "DHCP-Trust Attribute" is similarly a Boolean attribute. It indicates whether the attached device is permitted to initiate DHCP Server-to-Client messages. In Figure 1, the points of attachment of the DHCP server and the DHCP relay would have this attribute set TRUE, and attachment points that have Trust set TRUE are implicitly treated as if DHCP-Trust is TRUE.
「DHCP信頼属性」も同様にブール属性です。これは、接続されたデバイスがDHCPサーバーからクライアントへのメッセージの開始を許可されているかどうかを示します。図1では、DHCPサーバーとDHCPリレーの接続ポイントでこの属性がTRUEに設定され、信頼セットがTRUEである接続ポイントは、DHCP-TrustがTRUEであるかのように暗黙的に処理されます。
If the DHCP-Trust attribute is TRUE, SAVI devices will forward DHCP Server-to-Client messages from the points of attachment with this attribute. If the DHCP Server-to-Client messages can trigger the state transitions, the binding setup processes specified in Sections 6 and 7 will handle them. By default, the DHCP-Trust attribute is FALSE, indicating that the attached system is not a DHCP server.
DHCP-Trust属性がTRUEの場合、SAVIデバイスは、この属性を持つ接続ポイントからDHCPサーバーからクライアントへのメッセージを転送します。 DHCPサーバーからクライアントへのメッセージが状態遷移をトリガーできる場合、セクション6および7で指定されたバインディング設定プロセスがそれらを処理します。デフォルトでは、DHCP-Trust属性はFALSEであり、接続されたシステムがDHCPサーバーではないことを示します。
A DHCPv6 implementor can refer to [DHCPv6-SHIELD] for more details.
DHCPv6の実装者は、詳細について[DHCPv6-SHIELD]を参照できます。
The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It indicates whether bindings will be set up based on DHCP snooping.
「DHCPスヌーピング属性」も同様にブール属性です。 DHCPスヌーピングに基づいてバインディングがセットアップされるかどうかを示します。
If this attribute is TRUE, DHCP Client-to-Server messages to points of attachment with this attribute will trigger creation of bindings based on the DHCP Snooping Process described in Section 6. If it is FALSE, either the Trust attribute must be TRUE (so that bindings become irrelevant) or another SAVI mechanism such as FCFS SAVI must be used on the point of attachment.
この属性がTRUEの場合、この属性を持つ接続ポイントへのDHCPクライアントからサーバーへのメッセージは、セクション6で説明されているDHCPスヌーピングプロセスに基づくバインディングの作成をトリガーします。FALSEの場合、信頼属性はTRUE（つまりバインディングが無関係になる）、またはFCFS SAVIなどの別のSAVIメカニズムを接続ポイントで使用する必要があります。
The DHCP-Snooping attribute is configured on the DHCP client's point of attachment. This attribute can be also used on the attachments to protected non-SAVI devices that are used by DHCP clients. In Figure 1, the attachment from Client A to SAVI Device A, the attachment from Client B to SAVI Device B, and the attachment from Non-SAVI Device 2 to SAVI Device A can be configured with this attribute.
DHCPスヌーピング属性は、DHCPクライアントの接続点で構成されます。この属性は、DHCPクライアントが使用する保護された非SAVIデバイスへのアタッチメントでも使用できます。図1では、クライアントAからSAVIデバイスAへのアタッチメント、クライアントBからSAVIデバイスBへのアタッチメント、非SAVIデバイス2からSAVIデバイスAへのアタッチメントをこの属性で構成できます。
The "Data-Snooping Attribute" is a Boolean attribute. It indicates whether data packets from the corresponding point of attachment may trigger the binding setup procedure.
「データスヌーピング属性」はブール属性です。対応する接続ポイントからのデータパケットがバインディングセットアップ手順をトリガーするかどうかを示します。
Data packets from points of attachment with this attribute may trigger the setup of bindings. SAVI devices will set up bindings on points of attachment with this attribute based on the data-triggered process described in Section 7.
この属性を持つ接続ポイントからのデータパケットは、バインディングのセットアップをトリガーする場合があります。 SAVIデバイスは、セクション7で説明されているデータトリガープロセスに基づいて、この属性を持つアタッチメントポイントにバインディングをセットアップします。
If the DHCP-Snooping attribute is configured on a point of attachment, the bindings on this attachment are set up based on DHCP message snooping. However, in some scenarios, a DHCP client may use a DHCP address without the DHCP address assignment procedure being performed on its current attachment. For such attached devices, the Data Snooping Process, which is described in Section 7, is necessary. This attribute is configured on such attachments. The usage of this attribute is further discussed in Section 7.
DHCP-Snooping属性がアタッチメントポイントで設定されている場合、このアタッチメントのバインディングはDHCPメッセージスヌーピングに基づいて設定されます。ただし、一部のシナリオでは、DHCPクライアントは、現在のアタッチメントでDHCPアドレス割り当て手順を実行せずにDHCPアドレスを使用する場合があります。このような接続デバイスには、セクション7で説明するデータスヌーピングプロセスが必要です。この属性は、このような添付ファイルに構成されています。この属性の使用法については、セクション7で詳しく説明します。
Since some networks require DHCP deployment and others avoid it, there is no obvious universal default value for the Data-Snooping attribute. Hence, the Data-Snooping attribute should default to FALSE, and a mechanism should be implemented to conveniently set it to TRUE on all points of attachment for which the Trust attribute is FALSE.
DHCPの展開が必要なネットワークもあれば、それを回避するネットワークもあるため、Data-Snooping属性の一般的なデフォルト値は明らかではありません。したがって、Data-Snooping属性はデフォルトでFALSEになり、Trust属性がFALSEであるすべての接続点でTRUEに設定できるようにメカニズムを実装する必要があります。
The "Validating Attribute" is a Boolean attribute. It indicates whether packets from the corresponding attachment will have their IP source addresses validated based on binding entries on the attachment.
「検証属性」はブール属性です。これは、対応するアタッチメントからのパケットが、アタッチメントのバインディングエントリに基づいて検証されたIP送信元アドレスを持つかどうかを示します。
If it is TRUE, packets coming from attachments with this attribute will be validated based on binding entries on the attachment as specified in Section 8. If it is FALSE, they will not. Since the binding table is used in common with other SAVI algorithms, it merely signifies whether the check will be done, not whether it will be done for SAVI-DHCP originated bindings.
TRUEの場合、この属性を持つ添付ファイルから送信されたパケットは、セクション8で指定されている添付ファイルのバインディングエントリに基づいて検証されます。FALSEの場合、検証されません。バインディングテーブルは他のSAVIアルゴリズムと共通して使用されるため、SAVI-DHCPが生成したバインディングに対して行われるかどうかではなく、チェックが行われるかどうかを示すだけです。
This attribute is by default the inverse of the Trust attribute; source addresses on untrusted links are validated by default. It MAY be set FALSE by the administration.
この属性は、デフォルトではTrust属性の逆です。信頼できないリンクの送信元アドレスは、デフォルトで検証されます。これは、管理者によってFALSEに設定される場合があります。
The expected use case is when SAVI is used to monitor but not block forged transmissions. The network manager, in that case, may set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the Validating attribute FALSE.
想定される使用例は、偽造された送信を監視するためにSAVIを使用するがブロックしない場合です。その場合、ネットワークマネージャはDHCPスヌーピングまたはデータスヌーピング、あるいはその両方の属性をTRUEに設定し、検証属性をFALSEに設定します。
Different types of attributes may indicate mutually exclusive actions on a packet. Mutually exclusive attributes MUST NOT be set TRUE on the same attachment. The compatibility of different attributes is listed in Figure 2. Note that although Trust and DHCP-Trust are compatible, there is no need to configure DHCP-Trust to TRUE on an attachment with Trust attribute TRUE.
異なるタイプの属性は、パケットに対する相互に排他的なアクションを示す場合があります。同じアタッチメントで相互に排他的な属性をTRUEに設定してはなりません。さまざまな属性の互換性を図2に示します。TrustとDHCP-Trustは互換性がありますが、Trust属性がTRUEのアタッチメントでDHCP-TrustをTRUEに構成する必要はありません。
+----------+----------+----------+----------+----------+----------+
| | | | DHCP- | Data- | |
| | Trust |DHCP-Trust| Snooping | Snooping |Validating|
+----------+----------+----------+----------+----------+----------+
| | | | mutually | mutually | mutually |
| Trust | - |compatible| exclusive| exclusive| exclusive|
+----------+----------+----------+----------+----------+----------+
| | | | | | |
|DHCP-Trust|compatible| - |compatible|compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|DHCP- |mutually | | | | |
|Snooping |exclusive |compatible| - |compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|Data- |mutually | | | | |
|Snooping |exclusive |compatible|compatible| - |compatible|
+----------+----------+----------+----------+----------+----------+
| |mutually | | | | |
|Validating|exclusive |compatible|compatible|compatible| - |
+----------+----------+----------+----------+----------+----------+
Figure 2: Table of Mutual Exclusions
図2：相互排除の表
SAVI devices form a perimeter separating trusted and untrusted regions of a network, as FCFS SAVI does (Section 2.5 of [RFC6620]). The perimeter is primarily designed for scalability. It has two implications.
SAVIデバイスは、FCFS SAVIと同様に、ネットワークの信頼できる領域と信頼できない領域を分離する境界を形成します（[RFC6620]のセクション2.5）。境界は主にスケーラビリティのために設計されています。これには2つの意味があります。
o SAVI devices only need to establish bindings for directly attached clients, or clients indirectly attached through a non-SAVI protected device, rather than all of the clients in the network.
o SAVIデバイスは、ネットワーク内のすべてのクライアントではなく、直接接続されたクライアント、またはSAVIで保護されていないデバイスを介して間接的に接続されたクライアントのバインディングのみを確立する必要があります。
o Each SAVI device only needs to validate the source addresses in traffic from clients attached to it, without checking all the traffic passing by.
o 各SAVIデバイスは、接続されているクライアントからのトラフィックの送信元アドレスを検証するだけでよく、通過するすべてのトラフィックをチェックする必要はありません。
Consider the example in Figure 1. The protection perimeter is formed by SAVI Devices A, B, and C. In this case, SAVI Device B does not create a binding for Client A. However, because SAVI Device A filters spoofed traffic from Client A, SAVI Device B can avoid receiving spoofed traffic from Client A.
図1の例を検討してください。保護境界はSAVIデバイスA、B、Cで形成されます。この場合、SAVIデバイスBはクライアントAのバインディングを作成しません。ただし、SAVIデバイスAはクライアントAからのスプーフィングされたトラフィックをフィルタリングするため、SAVIデバイスBは、クライアントAからのなりすましトラフィックの受信を回避できます。
The perimeter in SAVI-DHCP is not only a perimeter for data packets but also a perimeter for DHCP messages. DHCP server response messages incoming across the perimeter will be dropped (Section 8). The placement of the DHCP relay and DHCP server, which are not involved in [RFC6620], is related to the construction of the perimeter. The requirement on the placement and configuration of the DHCP relay and DHCP server is discussed in Section 4.3.3.
SAVI-DHCPの境界は、データパケットの境界であるだけでなく、DHCPメッセージの境界でもあります。境界を越えて着信するDHCPサーバー応答メッセージはドロップされます（セクション8）。 [RFC6620]に含まれていないDHCPリレーとDHCPサーバーの配置は、境界の構築に関連しています。 DHCPリレーとDHCPサーバーの配置と構成に関する要件については、セクション4.3.3で説明します。
A perimeter separating trusted and untrusted regions of the network is formed as follows:
ネットワークの信頼できる領域と信頼できない領域を分離する境界は、次のように形成されます。
(1) Configure the Validating and DHCP-Snooping attributes TRUE on the direct attachments of all DHCP clients.
（1）すべてのDHCPクライアントの直接接続で、検証属性とDHCPスヌーピング属性をTRUEに設定します。
(2) Configure the Validating and DHCP-Snooping attributes TRUE on the indirect attachments of all DHCP clients (i.e., DHCP clients on protected links).
（2）すべてのDHCPクライアント（つまり、保護されたリンク上のDHCPクライアント）の間接的なアタッチメントで検証属性とDHCPスヌーピング属性をTRUEに設定します。
(3) Configure the Trust attribute TRUE on the attachments to other SAVI devices.
（3）他のSAVIデバイスへのアタッチメントに信頼属性TRUEを設定します。
(4) If a non-SAVI device, or a number of connected non-SAVI devices, are attached only to SAVI devices, set the Trust attribute TRUE on their attachments.
（4）非SAVIデバイス、または接続された多数の非SAVIデバイスがSAVIデバイスにのみ接続されている場合は、それらの接続の信頼属性をTRUEに設定します。
(5) Configure the DHCP-Trust attribute TRUE on the direct attachments to trusted DHCP relays and servers.
（5）信頼できるDHCPリレーおよびサーバーへの直接接続でDHCP-Trust属性をTRUEに設定します。
In this way, the points of attachments with the Validating attribute TRUE (and generally together with attachments of unprotected devices) on SAVI devices can form a perimeter separating DHCP clients and trusted devices. Data packet checks are only performed on the perimeter. The perimeter is also a perimeter for DHCP messages. The DHCP-Trust attribute is only TRUE on links inside the perimeter. Only DHCP Server-to-Client messages originated within the perimeter are trusted.
このようにして、SAVIデバイスのValidating属性がTRUEであるアタッチメントポイント（および一般に保護されていないデバイスのアタッチメントと共に）は、DHCPクライアントと信頼できるデバイスを分離する境界を形成できます。データパケットのチェックは、境界でのみ実行されます。境界は、DHCPメッセージの境界でもあります。 DHCP-Trust属性は、境界内のリンクでのみTRUEです。境界内で発信されたDHCPサーバーからクライアントへのメッセージのみが信頼されます。
As a result of the configuration guidelines, SAVI devices only trust DHCP Server-to-Client messages originated inside the perimeter. Thus, the trusted DHCP relays and DHCP servers must be placed within the perimeter. DHCP Server-to-Client messages will be filtered on the perimeter. Server-to-Relay messages will not be filtered, as they are within the perimeter. In this way, DHCP Server-to-Client messages from bogus DHCP servers are filtered on the perimeter, having entered through untrusted points of attachment. The SAVI devices are protected from forged DHCP messages.
構成ガイドラインの結果として、SAVIデバイスは、境界の内側から発信されたDHCPサーバーからクライアントへのメッセージのみを信頼します。したがって、信頼できるDHCPリレーとDHCPサーバーは、境界内に配置する必要があります。 DHCPサーバーからクライアントへのメッセージは、境界でフィルタリングされます。サーバーからリレーへのメッセージは境界内にあるため、フィルタリングされません。このようにして、偽のDHCPサーバーからのDHCPサーバーからクライアントへのメッセージは、信頼されていない接続ポイントから入った境界でフィルタリングされます。 SAVIデバイスは偽造DHCPメッセージから保護されています。
DHCP Server-to-Client messages arriving at the perimeter from outside the perimeter are not trusted. There is no distinction between a DHCP server owned and operated by the correct administration but outside the SAVI perimeter and a bogus DHCP server. For example, in Figure 1, DHCP Server A is valid, but it is attached to Non-SAVI Device 1. A bogus DHCP server is also attached to Non-SAVI Device 1. While one could imagine a scenario in which the valid one had a statistically configured port number and MAC address, and therefore a binding, by default SAVI-DHCP cannot distinguish whether a message received from the port of Non-SAVI Device 1 is from DHCP Server A or the bogus DHCP server. If DHCP Server A is contained in the perimeter, Non-SAVI Device 1 will also be contained in the perimeter. Thus, DHCP Server A cannot be contained within the perimeter apart from manual configuration of the binding anchor.
境界の外側から境界に到着するDHCPサーバーからクライアントへのメッセージは信頼されません。正しい管理者によって所有および運用されているが、SAVI境界の外側にあるDHCPサーバーと偽のDHCPサーバーとの間に違いはありません。たとえば、図1では、DHCPサーバーAは有効ですが、非SAVIデバイス1に接続されています。偽のDHCPサーバーも非SAVIデバイス1に接続されていますが、有効なものがあるシナリオを想像できますが統計的に構成されたポート番号とMACアドレス、したがってバインディングは、デフォルトではSAVI-DHCPは、非SAVIデバイス1のポートから受信したメッセージがDHCPサーバーAからのものか、偽のDHCPサーバーからのものかを区別できません。 DHCPサーバーAが境界に含まれている場合、非SAVIデバイス1も境界に含まれます。したがって、バインディングアンカーの手動構成を除き、DHCPサーバーAを境界内に含めることはできません。
Another consideration on the placement is that if the DHCP server/ relay is not inside the perimeter, the SAVI devices may not be able to set up bindings correctly because the SAVI devices may not be on the path between the clients and the server/relay, or the DHCP messages are encapsulated (e.g., Relay-reply and Relay-forward).
配置に関する別の考慮事項は、DHCPサーバー/リレーが境界の内側にない場合、SAVIデバイスがクライアントとサーバー/リレーの間のパス上にない可能性があるため、SAVIデバイスがバインディングを正しく設定できない可能性があることです。またはDHCPメッセージがカプセル化されます（たとえば、リレー応答とリレー転送）。
In common deployment practice, the traffic from the unprotected network is treated as trustworthy, which is to say that it is not filtered. In such a case, the Trust attribute can be set TRUE on the unprotected link. If non-SAVI devices, or a number of connected non-SAVI devices, are only attached to SAVI devices and unprotected devices, their attachment to SAVI devices can have the Trust attribute set TRUE. Then an unclosed perimeter will be formed, as illustrated in Figure 3.
一般的な展開方法では、保護されていないネットワークからのトラフィックは信頼できるものとして扱われます。つまり、フィルタリングされません。このような場合、保護されていないリンクでTrust属性をTRUEに設定できます。非SAVIデバイス、または接続されている多数の非SAVIデバイスがSAVIデバイスと保護されていないデバイスにのみ接続されている場合、SAVIデバイスへの接続には、Trust属性をTRUEに設定できます。次に、図3に示すように、閉じていない境界が形成されます。
| . . Protection |
| | | Perimeter |
| | | |
| Unprotected | | Unprotected |
| Link | | Link |
| | | |
| | | |
| +----+---+ +----+---+ +--------+ |
| |SAVI +----+Non-SAVI+----+SAVI | |
| |Device | |Device | |Device | |
| +----+---+ +--------+ +----+---+ |
| | | |
\_____________+___________________________+________/
| |
| |
+--------+ +--------+
|DHCP | |DHCP |
|Client | |Client |
+--------+ +--------+
Figure 3: Alternative Perimeter Configuration
図3：代替の境界構成
The strength of this binding-based mechanism depends on the strength of the binding anchor. The sample binding anchors in [RFC7039] have the property in which they associate an IP address with a direct physical or secure virtual interface such as a switch port, a subscriber association, or a security association. In addition, especially in the case where a protected non-SAVI device such as a desktop switch or a hub is between the client and SAVI devices, they MAY be extended to also include a MAC address or other link-layer attribute. In short, a binding anchor is intended to associate an IP address with something unspoofable that identifies a single-client system or one of its interfaces; this may be a physical or virtual interface or that plus disambiguating link-layer information.
このバインディングベースのメカニズムの強さは、バインディングアンカーの強さに依存します。 [RFC7039]のサンプルバインディングアンカーには、IPアドレスを、スイッチポート、サブスクライバーアソシエーション、セキュリティアソシエーションなどの直接の物理またはセキュア仮想インターフェイスに関連付けるという特性があります。さらに、特にデスクトップスイッチやハブなどの保護された非SAVIデバイスがクライアントとSAVIデバイスの間にある場合、それらはMACアドレスまたは他のリンク層属性を含むように拡張される場合があります。つまり、バインディングアンカーは、IPアドレスを、単一クライアントシステムまたはそのインターフェイスの1つを識別するなりすましできないものに関連付けることを目的としています。これは、物理または仮想インターフェイス、または明確化されたリンク層情報です。
If the binding anchor is spoofable, such as a plain MAC address, or non-exclusive, such as a switch port extended using a non-SAVI device, an attacker can use a forged binding anchor to evade validation. Indeed, using a binding anchor that can be easily spoofed can lead to worse outcomes than allowing spoofed IP traffic. Thus, a SAVI device MUST use a non-spoofable and exclusive binding anchor.
バインディングアンカーがプレーンなMACアドレスなどのスプーフィング可能であるか、非SAVIデバイスを使用して拡張されたスイッチポートなどの非排他的である場合、攻撃者は偽造されたバインディングアンカーを使用して検証を回避できます。実際、スプーフィングが容易なバインディングアンカーを使用すると、スプーフィングされたIPトラフィックを許可するよりも悪い結果を招く可能性があります。したがって、SAVIデバイスは、スプーフィングできない排他的なバインディングアンカーを使用する必要があります。
In addition to a possible binding anchor configuration specified in Section 4.2, an implementation has the following configuration requirements:
セクション4.2で指定された可能なバインディングアンカー構成に加えて、実装には次の構成要件があります。
(1) Address configuration. For DHCPv4: the SAVI device MUST have an IPv4 address. For DHCPv6: the client of a SAVI device MUST have a link-local address; when the DHCPv6 server is not on the same link as the SAVI device, the SAVI device MUST also have an IPv6 address of at least the same scope as the DHCPv6 Server.
（1）アドレス構成。 DHCPv4の場合：SAVIデバイスにはIPv4アドレスが必要です。 DHCPv6の場合：SAVIデバイスのクライアントにはリンクローカルアドレスが必要です。 DHCPv6サーバーがSAVIデバイスと同じリンク上にない場合、SAVIデバイスは少なくともDHCPv6サーバーと同じスコープのIPv6アドレスも持っている必要があります。
(2) DHCP server address configuration: a SAVI device MUST store the list of the DHCP server addresses that it could contact during a leasequery process.
（2）DHCPサーバーアドレスの構成：SAVIデバイスは、leasequeryプロセス中に接続できるDHCPサーバーアドレスのリストを保存する必要があります。
(3) A SAVI device may also require security parameters, such as preconfigured keys to establish a secure connection for the leasequery process [RFC4388] [RFC5007] connection.
（3）SAVIデバイスは、leasequeryプロセス[RFC4388] [RFC5007]接続のための安全な接続を確立するために事前設定されたキーなどのセキュリティパラメータも必要とする場合があります。
The Binding State Table, which may be implemented centrally in the switch or distributed among its ports, is used to contain the bindings between the IP addresses assigned to the attachments and the corresponding binding anchors of the attachments. Note that in this description, there is a binding entry for each IPv4 or IPv6 address associated with each binding anchor, and there may be several of each such address, especially if the port is extended using a protected non-SAVI device. Each binding entry has six fields:
バインディング状態テーブルは、スイッチの中央に実装されるか、ポート間で分散され、アタッチメントに割り当てられたIPアドレスとアタッチメントの対応するバインディングアンカー間のバインディングを含めるために使用されます。この説明では、各バインディングアンカーに関連付けられたIPv4またはIPv6アドレスごとにバインディングエントリがあり、特に保護された非SAVIデバイスを使用してポートが拡張されている場合は、そのようなアドレスがいくつかあることに注意してください。各バインディングエントリには6つのフィールドがあります。
o Binding Anchor (listed as "Anchor" in subsequent figures): the binding anchor, i.e., one or more physical and/or link-layer properties of the attachment.
o バインディングアンカー（後続の図で「アンカー」としてリストされています）：バインディングアンカー、つまり、アタッチメントの1つ以上の物理プロパティおよび/またはリンク層プロパティ。
o IP Address (listed as "Address" in subsequent figures): the IPv4 or IPv6 address assigned to the attachment by DHCP.
o IPアドレス（後続の図では「アドレス」としてリストされています）：DHCPによってアタッチメントに割り当てられたIPv4またはIPv6アドレス。
o State: the state of the binding. Possible values of this field are listed in Sections 6.2 and 7.3.
o 状態：バインディングの状態。このフィールドの可能な値は、セクション6.2および7.3にリストされています。
o Lifetime: the remaining seconds of the binding. Internally, this MAY be stored as the timestamp value at which the lifetime expires.
o 存続期間：バインディングの残りの秒数。内部的には、これは、有効期限が切れるタイムスタンプ値として格納される場合があります。
o Transaction ID (TID): the Transaction ID [RFC2131] [RFC3315] of the corresponding DHCP transaction. The TID field is used to associate DHCP Server-to-Client messages with corresponding binding entries.
oトランザクションID（TID）：対応するDHCPトランザクションのトランザクションID [RFC2131] [RFC3315]。 TIDフィールドは、DHCPサーバーからクライアントへのメッセージを対応するバインディングエントリに関連付けるために使用されます。
o Timeouts: the number of timeouts that expired in the current state (only used in the Data Snooping Process; see Section 7).
o タイムアウト：現在の状態で期限切れになったタイムアウトの数（データスヌーピングプロセスでのみ使用。セクション7を参照）。
The IA is not present in the BST for three reasons:
IAは、次の3つの理由でBSTに存在しません。
o The lease of each address in one IA is assigned separately.
o 1つのIAの各アドレスのリースは、個別に割り当てられます。
o When the binding is set up based on data snooping, the IA cannot be recovered from the leasequery protocol.
o バインディングがデータスヌーピングに基づいて設定されている場合、IAはleasequeryプロトコルから回復できません。
o DHCPv4 does not define an IA.
o DHCPv4はIAを定義していません。
An example of such a table is shown in Figure 4.
そのようなテーブルの例を図4に示します。
+---------+----------+-----------+-----------+--------+----------+
| Anchor | Address | State | Lifetime | TID | Timeouts |
+---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_1 | BOUND | 65535 | TID_1 | 0 |
+---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_2 | BOUND | 10000 | TID_2 | 0 |
+---------+----------+-----------+-----------+--------+----------+
| Port_2 | IP_3 | INIT_BIND | 1 | TID_3 | 0 |
+---------+----------+-----------+-----------+--------+----------+
Figure 4: Example Binding State Table
図4：バインド状態テーブルの例
This section specifies the process of setting up bindings based on DHCP snooping. This process is illustrated using a state machine.
このセクションでは、DHCPスヌーピングに基づいてバインディングをセットアップするプロセスを指定します。このプロセスは、ステートマシンを使用して示されています。
The rationale of the DHCP Snooping Process is that if a DHCP client is legitimately using a DHCP-assigned address, the DHCP address assignment procedure that assigns the IP address to the client must have been performed via the client's point of attachment. This assumption works when the SAVI device is always on the path(s) from the DHCP client to the DHCP server(s)/relay(s). Without considering the movement of DHCP clients, the SAVI device should be the cut vertex whose removal will separate the DHCP client and the remaining network containing the DHCP server(s)/relay(s). For most of the networks whose topologies are simple, it is possible to deploy this SAVI function at proper devices to meet this requirement.
DHCPスヌーピングプロセスの理論的根拠は、DHCPクライアントがDHCP割り当てアドレスを正当に使用している場合、クライアントにIPアドレスを割り当てるDHCPアドレス割り当て手順は、クライアントの接続ポイントを介して実行されている必要があるということです。この仮定は、SAVIデバイスが常にDHCPクライアントからDHCPサーバー/リレーへのパス上にある場合に機能します。 DHCPクライアントの移動を考慮せずに、SAVIデバイスは、その削除によってDHCPクライアントとDHCPサーバー/リレーを含む残りのネットワークが分離されるカット頂点である必要があります。トポロジが単純なほとんどのネットワークでは、このSAVI機能を適切なデバイスに展開して、この要件を満たすことができます。
However, if there are multiple paths from a DHCP client to the DHCP server and the SAVI device is only on one of them, there is an obvious failure case: the SAVI device may not be able to snoop the DHCP procedure. Host movement may also make this requirement difficult to meet. For example, when a DHCP client moves from one attachment to another attachment in the same network, it may fail to reinitialize its interface or send a Confirm message because of incomplete protocol implementation. Thus, there can be scenarios in which only performing this DHCP Snooping Process is insufficient to set up bindings for all the valid DHCP addresses. These exceptions and the solutions are discussed in Section 7.
ただし、DHCPクライアントからDHCPサーバーへのパスが複数あり、SAVIデバイスがそのうちの1つだけにある場合は、明らかな障害ケースがあります。SAVIデバイスがDHCP手順をスヌーピングできない可能性があります。ホストの移動により、この要件を満たすのが困難になる場合もあります。たとえば、DHCPクライアントが同じネットワーク内のあるアタッチメントから別のアタッチメントに移動した場合、プロトコルの実装が不完全なため、インターフェイスの再初期化や確認メッセージの送信に失敗することがあります。したがって、このDHCPスヌーピングプロセスを実行するだけでは、すべての有効なDHCPアドレスのバインディングを設定するには不十分な場合があります。これらの例外と解決策については、セクション7で説明します。
The following binding states are present in this process and the corresponding state machine:
このプロセスおよび対応するステートマシンには、次のバインディング状態が存在します。
NO_BIND: No binding has been set up.
NO_BIND：バインドが設定されていません。
INIT_BIND: A potential binding has been set up.
INIT_BIND：潜在的なバインディングがセットアップされました。
BOUND: The binding has been set up.
BOUND：バインディングが設定されました。
This section describes events in this process and the corresponding state machine transitions. The DHCP message categories (e.g., DHCPv4 Discover) defined in Section 3 are used extensively in the definitions of events and elsewhere in the state machine definition. If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
このセクションでは、このプロセスのイベントと、対応するステートマシンの遷移について説明します。セクション3で定義されたDHCPメッセージカテゴリ（DHCPv4 Discoverなど）は、イベントの定義や、ステートマシン定義の他の場所で広く使用されています。イベントが新しいバインディングエントリの作成をトリガーする場合、バインディングアンカーのバインディングエントリ制限を超えてはなりません（MUST NOT）。
EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires.
EVE_ENTRY_EXPIRE：バインディングエントリの有効期限が切れます。
EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received.
EVE_DHCP_REQUEST：DHCPv4要求またはDHCPv6要求メッセージが受信されます。
EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received.
EVE_DHCP_CONFIRM：DHCPv6確認メッセージを受信しました。
EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received.
EVE_DHCP_REBOOT：DHCPv4 Rebootメッセージを受信しました。
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received.
EVE_DHCP_REBIND：DHCPv4 RebindまたはDHCPv6 Rebindメッセージが受信されます。
EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received.
EVE_DHCP_RENEW：DHCPv4 RenewまたはDHCPv6 Renewメッセージを受信しました。
EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received.
EVE_DHCP_SOLICIT_RC：Rapid Commitオプションを含むDHCPv6要請メッセージを受信しました。
EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received.
EVE_DHCP_REPLY：DHCPv4 ACKまたはDHCPv6応答メッセージが受信されます。
EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received.
EVE_DHCP_DECLINE：DHCPv4 DeclineまたはDHCPv6 Declineメッセージを受信しました。
EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received.
EVE_DHCP_RELEASE：DHCPv4リリースまたはDHCPv6リリースメッセージが受信されます。
EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer to Section 4.3.3 of [RFC5007]) is received.
EVE_DHCP_LEASEQUERY：DHCPv6 LEASEQUERY-REPLY（[RFC5007]のセクション4.3.3を参照）が正常に受信されます。
Note: the events listed here do not cover all the DHCP messages in Section 3. The messages that do not really determine address usage (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, and DHCPv6 Reconfigure) and that are not necessary to snoop (DHCPv4 Negative Acknowledgment (NAK); refer to Section 6.4.2.3) are not included. Note also that DHCPv4 DHCPLEASEQUERY is not used in the DHCP Snooping Process to avoid confusion with Section 7. Also, since the LEASEQUERY should have been originated by the SAVI device itself, the destination check should verify that the message is directed to this SAVI device, and it should not be forwarded once it has been processed here.
注：ここにリストされているイベントは、セクション3のすべてのDHCPメッセージを網羅しているわけではありません。実際にアドレスの使用を決定しないメッセージ（DHCPv4 Discover、DHCPv4 Inform、DHCPv6 Solicit without Rapid Commit、DHCPv6 Information-Request、DHCPv4 Offer、DHCPv6 Advertise、およびDHCPv6再構成）およびスヌープする必要はありません（DHCPv4否定応答（NAK）。セクション6.4.2.3を参照）は含まれていません。セクション7との混同を避けるために、DHCPv4 DHCPLEASEQUERYはDHCPスヌーピングプロセスでは使用されないことにも注意してください。また、LEASEQUERYはSAVIデバイス自体によって生成されているはずなので、宛先チェックはメッセージがこのSAVIデバイスに向けられていることを確認する必要があります。ここで処理された後は転送しないでください。
Moreover, only if a DHCP message can pass the following checks, the corresponding event is regarded as a valid event:
さらに、DHCPメッセージが次のチェックに合格した場合にのみ、対応するイベントは有効なイベントと見なされます。
o Attribute check: the DHCP Server-to-Client messages and LEASEQUERY-REPLY should be from attachments with the DHCP-Trust attribute; the DHCP Client-to-Server messages should be from attachments with the DHCP-Snooping attribute.
o 属性チェック：DHCPサーバーからクライアントへのメッセージとLEASEQUERY-REPLYは、DHCP-Trust属性を持つ添付ファイルからのものである必要があります。 DHCPクライアントからサーバーへのメッセージは、DHCPスヌーピング属性を持つ添付ファイルからのものでなければなりません。
o Destination check: the DHCP Server-to-Client messages should be destined to attachments with the DHCP-Snooping attribute. This check is performed to ensure the binding is set up on the SAVI device that is nearest to the destination client.
o 宛先チェック：DHCPサーバーからクライアントへのメッセージは、DHCPスヌーピング属性を持つ添付ファイルを宛先とする必要があります。このチェックは、宛先クライアントに最も近いSAVIデバイスでバインディングが設定されていることを確認するために実行されます。
o Binding anchor check: the DHCP Client-to-Server messages that may trigger modification or removal of an existing binding entry must have a matching binding anchor with the corresponding entry.
o バインディングアンカーチェック：既存のバインディングエントリの変更または削除をトリガーする可能性があるDHCPクライアントからサーバーへのメッセージには、対応するエントリと一致するバインディングアンカーが必要です。
o TID check: the DHCP Server-to-Client/Client-to-Server messages that may cause modification of existing binding entries must have a matched TID with the corresponding entry. Note that this check is not performed on LEASEQUERY and LEASEQUERY-REPLY messages as they are exchanged between the SAVI devices and the DHCP servers. Besides, this check is not performed on DHCP Renew/Rebind messages.
o TIDチェック：既存のバインディングエントリの変更を引き起こす可能性のあるDHCPサーバーからクライアント/クライアントからサーバーへのメッセージには、対応するエントリと一致するTIDが必要です。 LEASEQUERYおよびLEASEQUERY-REPLYメッセージはSAVIデバイスとDHCPサーバー間で交換されるため、このチェックは実行されないことに注意してください。さらに、このチェックはDHCP Renew / Rebindメッセージでは実行されません。
o Binding limitation check: the DHCP messages must not cause new binding setup on an attachment whose binding entry limitation has been reached (refer to Section 11.5).
o バインディング制限チェック：DHCPメッセージによって、バインディングエントリの制限に達した添付ファイルに新しいバインディング設定が発生してはなりません（セクション11.5を参照）。
o Address check: the source address of the DHCP messages should pass the check specified in Section 8.2.
o アドレスチェック：DHCPメッセージの送信元アドレスは、セクション8.2で指定されたチェックに合格する必要があります。
On receiving a DHCP message without triggering a valid event, the state will not change, and the actions will not be performed. Note that if a message does not trigger a valid event but it can pass the checks in Section 8.2, it MUST be forwarded.
有効なイベントをトリガーせずにDHCPメッセージを受信しても、状態は変化せず、アクションは実行されません。メッセージが有効なイベントをトリガーしなくても、セクション8.2のチェックに合格できる場合は、転送する必要があることに注意してください。
This section specifies state transitions and their corresponding actions.
このセクションでは、状態遷移とそれに対応するアクションを指定します。
6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request message is received
6.4.1.1. イベント：EVE_DHCP_REQUEST-DHCPv4要求またはDHCPv6要求メッセージが受信されました
The SAVI device MUST forward the message.
SAVIデバイスはメッセージを転送する必要があります。
The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Request, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5.
SAVIデバイスはBSTにエントリを生成します。 [バインディングアンカー]フィールドは、メッセージの受信元である添付ファイルのバインディングアンカーに設定されます。 StateフィールドはINIT_BINDに設定されます。 LifetimeフィールドはMAX_DHCP_RESPONSE_TIMEに設定されています。 TIDフィールドはメッセージのTIDに設定されます。メッセージがDHCPv4リクエストの場合、アドレスフィールドはリクエストするアドレス、つまり「リクエストされたIPアドレス」に設定できます。エントリの例を図5に示します。
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
Figure 5: Binding Entry in BST on Initialization Triggered by Request/Rapid Commit/Reboot Messages
図5：リクエスト/ラピッドコミット/リブートメッセージによってトリガーされる初期化時のBSTのバインディングエントリ
Resulting state: INIT_BIND - A potential binding has been set up.
結果の状態：INIT_BIND-潜在的なバインディングがセットアップされました。
The SAVI device MUST forward the message.
SAVIデバイスはメッセージを転送する必要があります。
The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Reboot, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5.
SAVIデバイスはBSTにエントリを生成します。 [バインディングアンカー]フィールドは、メッセージの受信元である添付ファイルのバインディングアンカーに設定されます。 StateフィールドはINIT_BINDに設定されます。 LifetimeフィールドはMAX_DHCP_RESPONSE_TIMEに設定されています。 TIDフィールドはメッセージのTIDに設定されます。メッセージがDHCPv4 Rebootの場合、アドレスフィールドには、要求するアドレス、つまり「要求されたIPアドレス」を設定できます。エントリの例を図5に示します。
Resulting state: INIT_BIND - A potential binding has been set up.
結果の状態：INIT_BIND-潜在的なバインディングがセットアップされました。
6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message with the Rapid Commit option is received
6.4.1.3. イベント：EVE_DHCP_SOLICIT_RC-Rapid Commitオプションを含むDHCPv6要請メッセージが受信された
The SAVI device MUST forward the message.
SAVIデバイスはメッセージを転送する必要があります。
The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. An example of the entry is illustrated in Figure 5.
SAVIデバイスはBSTにエントリを生成します。 [バインディングアンカー]フィールドは、メッセージの受信元である添付ファイルのバインディングアンカーに設定されます。 StateフィールドはINIT_BINDに設定されます。 LifetimeフィールドはMAX_DHCP_RESPONSE_TIMEに設定されています。 TIDフィールドはメッセージのTIDに設定されます。エントリの例を図5に示します。
Resulting state: INIT_BIND - A potential binding has been set up.
結果の状態：INIT_BIND-潜在的なバインディングがセットアップされました。
The SAVI device MUST forward the message.
SAVIデバイスはメッセージを転送する必要があります。
The SAVI device will generate corresponding entries in the BST for each address in each Identity Association (IA) option of the Confirm message. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. The Address field is set to the address(es) to confirm. An example of the entries is illustrated in Figure 6.
SAVIデバイスは、確認メッセージの各IDアソシエーション（IA）オプションの各アドレスのBSTに対応するエントリを生成します。 [バインディングアンカー]フィールドは、メッセージの受信元である添付ファイルのバインディングアンカーに設定されます。 StateフィールドはINIT_BINDに設定されます。 LifetimeフィールドはMAX_DHCP_RESPONSE_TIMEに設定されています。 TIDフィールドはメッセージのTIDに設定されます。住所フィールドは、確認する住所に設定されます。エントリの例を図6に示します。
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
Figure 6: Binding Entry in BST on Confirm-Triggered Initialization
図6：確認トリガー初期化時のBSTのバインディングエントリ
Resulting state: INIT_BIND - A potential binding has been set up.
結果の状態：INIT_BIND-潜在的なバインディングがセットアップされました。
o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires
o EVE_ENTRY_EXPIRE：バインディングエントリの有効期限が切れます
o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received
o EVE_DHCP_REBIND：DHCPv4 RebindまたはDHCPv6 Rebindメッセージが受信された
o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
o EVE_DHCP_RENEW：DHCPv4 RenewまたはDHCPv6 Renewメッセージが受信された
o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received
o EVE_DHCP_REPLY：DHCPv4 ACKまたはDHCPv6応答メッセージが受信された
o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received
o EVE_DHCP_DECLINE：DHCPv4 DeclineまたはDHCPv6 Declineメッセージを受信しました
o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received
o EVE_DHCP_RELEASE：DHCPv4 ReleaseまたはDHCPv6 Releaseメッセージが受信された
o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is received
o EVE_DHCP_LEASEQUERY：DHCPv6 LEASEQUERY-REPLYが正常に受信されました
These cannot happen because they are each something that happens AFTER a binding has been created.
これらは、バインディングが作成された後に発生するものであるため、発生することはありません。
6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received
6.4.2.1. イベント：EVE_DHCP_REPLY-DHCPv4 ACKまたはDHCPv6応答メッセージが受信された
The message MUST be forwarded to the corresponding client.
メッセージは対応するクライアントに転送されなければなりません。
If the message is DHCPv4 ACK, the Address field of the corresponding entry (i.e., the binding entry whose TID is the same as the message) is set to the address in the message (i.e., 'yiaddr' in DHCPv4 ACK). The Lifetime field is set to the sum of the lease time in the ACK message and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND.
メッセージがDHCPv4 ACKの場合、対応するエントリ（つまり、TIDがメッセージと同じであるバインディングエントリ）のアドレスフィールドは、メッセージ内のアドレス（つまり、DHCPv4 ACKの「yiaddr」）に設定されます。 Lifetimeフィールドは、ACKメッセージのリース時間とMAX_DHCP_RESPONSE_TIMEの合計に設定されます。状態フィールドがBOUNDに変更されます。
If the message is DHCPv6 Reply, note the following cases:
メッセージがDHCPv6応答の場合は、次の場合に注意してください。
1. If the status code is not "Success", no modification of corresponding entries will be made. Corresponding entries will expire automatically if no "Success" Reply is received during the lifetime. The entries are not removed immediately because the client may be able to use the addresses whenever a "Success" Reply is received ("If the client receives any Reply messages that do not indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status" [RFC3315]).
1. ステータスコードが「成功」でない場合、対応するエントリの変更は行われません。存続期間中に「成功」応答を受信しない場合、対応するエントリは自動的に期限切れになります。クライアントは、「成功」応答を受信するたびにアドレスを使用できる可能性があるため、エントリはすぐには削除されません（「クライアントがNotOnLinkステータスを示さない応答メッセージを受信した場合、クライアントはIAのアドレスを使用できますNotOnLinkステータスを示すメッセージは無視してください」[RFC3315]）。
2. If the status code is "Success", the SAVI device checks the IA options in the Reply message.
2. ステータスコードが「成功」の場合、SAVIデバイスは返信メッセージのIAオプションをチェックします。
A. If there are IA options in the Reply message, the SAVI device checks each IA option. When the first assigned address is found, the Address field of the binding entry with a matched TID is set to the address. The Lifetime field is set to the sum of the lease time in the Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. If there is more than one address assigned in the message, new binding entries are set up for the remaining address assigned in the IA options. An example of the entries is illustrated in Figure 8. SAVI devices do not specially process IA options with a NoAddrsAvail status because there should be no address contained in such IA options.
A.返信メッセージにIAオプションがある場合、SAVIデバイスは各IAオプションをチェックします。最初に割り当てられたアドレスが見つかると、一致したTIDを持つバインディングエントリのアドレスフィールドがそのアドレスに設定されます。 Lifetimeフィールドは、応答メッセージのリース時間とMAX_DHCP_RESPONSE_TIMEの合計に設定されます。状態フィールドがBOUNDに変更されます。メッセージに複数のアドレスが割り当てられている場合、IAオプションで割り当てられた残りのアドレスに対して新しいバインディングエントリが設定されます。エントリの例を図8に示します。SAVIデバイスは、NoAddrsAvailステータスのIAオプションを特別に処理しません。そのようなIAオプションにはアドレスが含まれていないはずです。
B. Otherwise, the DHCP Reply message is in response to a Confirm message. The state of the binding entries with a matched TID is changed to BOUND. Because [RFC3315] does not require the lease time of addresses to be contained in the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] message querying by IP address to the All_DHCP_Servers multicast address [RFC3315] or a list of configured DHCP server addresses. The LEASEQUERY message is generated for each IP address if multiple addresses are confirmed. The lifetime of corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example of the entries is illustrated in Figure 7. If the SAVI device does not send the LEASEQUERY message, a preconfigured lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. (Note: it is RECOMMENDED to use T1 configured on DHCP servers as the DHCP_DEFAULT_LEASE.)
B.それ以外の場合、DHCP応答メッセージは確認メッセージへの応答です。 TIDが一致するバインディングエントリの状態はBOUNDに変更されます。 [RFC3315]はアドレスのリース時間を返信メッセージに含める必要がないため、SAVIデバイスはIPアドレスでクエリするLEASEQUERY [RFC5007]メッセージをAll_DHCP_Serversマルチキャストアドレス[RFC3315]または構成済みDHCPサーバーのリストに送信する必要があります（SHOULD）。アドレス。複数のアドレスが確認された場合、LEASEQUERYメッセージはIPアドレスごとに生成されます。対応するエントリの有効期間は2 * MAX_LEASEQUERY_DELAYに設定されます。 MAX_LEASEQUERY_DELAYの後に応答メッセージがない場合は、LEASEQUERYメッセージを再送信してください。エントリの例を図7に示します。SAVIデバイスがLEASEQUERYメッセージを送信しない場合は、対応するエントリに事前設定された有効期間DHCP_DEFAULT_LEASEを設定する必要があります。 （注：DHCPサーバーで構成されたT1をDHCP_DEFAULT_LEASEとして使用することをお勧めします。）
Note: the SAVI devices do not check if the assigned addresses are duplicated because in SAVI-DHCP scenarios, the DHCP servers are the only source of valid addresses. However, the DHCP servers should be configured to make sure no duplicated addresses are assigned.
注：SAVI-DHCPシナリオでは、DHCPサーバーが有効なアドレスの唯一のソースであるため、SAVIデバイスは割り当てられたアドレスが重複しているかどうかをチェックしません。ただし、重複するアドレスが割り当てられないようにDHCPサーバーを構成する必要があります。
+--------+-------+-------+------------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+-------+------------------------+-----+----------+
Figure 7: From INIT_BIND to BOUND on DHCP Reply in Response to Confirm
図7：確認への応答としてDHCP応答のINIT_BINDからBOUNDへ
Transition
+--------+-------+-------+------------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr1 | BOUND |Lease time+ | TID | 0 |
| | | |MAX_DHCP_RESPONSE_TIME | | |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr2 | BOUND |Lease time+ | TID | 0 |
| | | |MAX_DHCP_RESPONSE_TIME | | |
+--------+-------+-------+------------------------+-----+----------+
Figure 8: From INIT_BIND to BOUND on DHCP Reply in Response to Request
図8：要求への応答としてDHCP応答のINIT_BINDからBOUNDへ
Resulting state: BOUND - The binding has been set up.
結果の状態：BOUND-バインディングがセットアップされました。
6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires
6.4.2.2. イベント：EVE_ENTRY_EXPIRE-バインディングエントリの有効期限が切れます
The entry MUST be deleted from the BST.
エントリはBSTから削除する必要があります。
Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
結果の状態：BSTから削除されたエントリは、「NO_BIND」状態にあると見なされる場合があります-バインドが設定されていません。
If no DHCP Server-to-Client messages that assign addresses or confirm addresses are received, corresponding entries will expire automatically. Thus, other DHCP Server-to-Client messages (e.g., DHCPv4 NAK) are not specially processed.
アドレスを割り当てるか、アドレスを確認するDHCPサーバーからクライアントへのメッセージが受信されない場合、対応するエントリは自動的に期限切れになります。したがって、他のDHCPサーバーからクライアントへのメッセージ（DHCPv4 NAKなど）は特別に処理されません。
As a result, the following events, should they occur, are ignored until either a DHCPv4 ACK or a DHCPv6 Reply message is received or the lifetime of the binding entry expires.
その結果、次のイベントが発生した場合、DHCPv4 ACKまたはDHCPv6 Replyメッセージが受信されるか、バインディングエントリのライフタイムが期限切れになるまで無視されます。
o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received
o EVE_DHCP_REQUEST：DHCPv4要求またはDHCPv6要求メッセージが受信されました
o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received
o EVE_DHCP_CONFIRM：DHCPv6確認メッセージを受信しました
o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received
o EVE_DHCP_REBOOT：DHCPv4 Rebootメッセージを受信しました
o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received
o EVE_DHCP_REBIND：DHCPv4 RebindまたはDHCPv6 Rebindメッセージが受信された
o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
o EVE_DHCP_RENEW：DHCPv4 RenewまたはDHCPv6 Renewメッセージが受信された
o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received
o EVE_DHCP_SOLICIT_RC：Rapid Commitオプションを含むDHCPv6要請メッセージを受信しました
o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received
o EVE_DHCP_DECLINE：DHCPv4 DeclineまたはDHCPv6 Declineメッセージを受信しました
o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received
o EVE_DHCP_RELEASE：DHCPv4 ReleaseまたはDHCPv6 Releaseメッセージが受信された
o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is received
o EVE_DHCP_LEASEQUERY：DHCPv6 LEASEQUERY-REPLYが正常に受信されました
In each case, the message MUST be forwarded.
いずれの場合も、メッセージを転送する必要があります。
Resulting state: INIT_BIND - A potential binding has been set up.
結果の状態：INIT_BIND-潜在的なバインディングがセットアップされました。
6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires
6.4.3.1. イベント：EVE_ENTRY_EXPIRE-バインディングエントリの有効期限が切れます
The entry MUST be deleted from the BST.
エントリはBSTから削除する必要があります。
Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
結果の状態：BSTから削除されたエントリは、「NO_BIND」状態にあると見なされる場合があります-バインドが設定されていません。
6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline message is received
6.4.3.2. イベント：EVE_DHCP_DECLINE-DHCPv4 DeclineまたはDHCPv6 Declineメッセージが受信された
The message MUST be forwarded.
メッセージを転送する必要があります。
First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then, the corresponding entries MUST be removed.
まず、SAVIデバイスはすべてのアドレス（DHCPv4拒否の「要求されたIPアドレス」、DHCPv4リリースの「ciaddr」、およびDHCPv6拒否/リリースのすべてのIAオプションのアドレス）を取得して、メッセージで拒否/リリースします。次に、対応するエントリを削除する必要があります。
Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
関連する各BSTエントリの結果の状態：BSTから削除されたエントリは、「NO_BIND」状態であると見なされる場合があります-バインドが設定されていません。
6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release message is received
6.4.3.3. イベント：EVE_DHCP_RELEASE-DHCPv4リリースまたはDHCPv6リリースメッセージが受信された
The message MUST be forwarded.
メッセージを転送する必要があります。
First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then, the corresponding entries MUST be removed.
まず、SAVIデバイスはすべてのアドレス（DHCPv4拒否の「要求されたIPアドレス」、DHCPv4リリースの「ciaddr」、およびDHCPv6拒否/リリースのすべてのIAオプションのアドレス）を取得して、メッセージで拒否/リリースします。次に、対応するエントリを削除する必要があります。
Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
関連する各BSTエントリの結果の状態：BSTから削除されたエントリは、「NO_BIND」状態であると見なされる場合があります-バインドが設定されていません。
6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind message is received
6.4.3.4. イベント：EVE_DHCP_REBIND-DHCPv4 RebindまたはDHCPv6 Rebindメッセージが受信された
The message MUST be forwarded.
メッセージを転送する必要があります。
In such a case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that the TID check will not be performed on such messages.
このような場合、新しいTIDがクライアントによって使用されます。対応するエントリのTIDフィールドを新しいTIDに設定する必要があります。このようなメッセージではTIDチェックは実行されないことに注意してください。
Resulting state: BOUND: The binding has been set up.
結果の状態：BOUND：バインディングがセットアップされました。
6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew message is received
6.4.3.5. イベント：EVE_DHCP_RENEW-DHCPv4 RenewまたはDHCPv6 Renewメッセージが受信された
The message MUST be forwarded.
メッセージを転送する必要があります。
In such a case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that the TID check will not be performed on such messages.
このような場合、新しいTIDがクライアントによって使用されます。対応するエントリのTIDフィールドを新しいTIDに設定する必要があります。このようなメッセージではTIDチェックは実行されないことに注意してください。
Resulting state: BOUND: The binding has been set up.
結果の状態：BOUND：バインディングがセットアップされました。
6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received
6.4.3.6. イベント：EVE_DHCP_REPLY-DHCPv4 ACKまたはDHCPv6応答メッセージが受信された
The message MUST be forwarded.
メッセージを転送する必要があります。
The DHCP Reply messages received in current states should be in response to DHCP Renew/Rebind.
現在の状態で受信されたDHCP応答メッセージは、DHCPの更新/再バインドに対する応答である必要があります。
If the message is DHCPv4 ACK, the SAVI device updates the binding entry with a matched TID, with the Lifetime field set to be the sum of the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in the BOUND state.
メッセージがDHCPv4 ACKの場合、SAVIデバイスは一致したTIDでバインディングエントリを更新し、Lifetimeフィールドを新しいリース時間とMAX_DHCP_RESPONSE_TIMEの合計に設定して、エントリをBOUND状態のままにします。
If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. For each:
メッセージがDHCPv6応答の場合、SAVIデバイスは各IAオプションの各IAアドレスオプションをチェックします。それぞれについて：
1. If the IA entry in the REPLY message has the status "NoBinding", there is no address in the option, and no operation on an address is performed.
1. REPLYメッセージのIAエントリのステータスが「NoBinding」の場合、オプションにはアドレスがなく、アドレスに対する操作は実行されません。
2. If the valid lifetime of an IA Address option is 0, the binding entry with a matched TID and address is removed, leaving it effectively in the NO_BIND state.
2. IAアドレスオプションの有効期間が0の場合、TIDとアドレスが一致するバインディングエントリは削除され、実質的にNO_BIND状態のままになります。
3. Otherwise, set the Lifetime field of the binding entry with the matched TID and address to be the sum of the new valid lifetime and MAX_DHCP_RESPONSE_TIME, leaving the entry in the BOUND state.
3. それ以外の場合は、一致するTIDとアドレスを持つバインディングエントリのLifetimeフィールドを、新しい有効なライフタイムとMAX_DHCP_RESPONSE_TIMEの合計に設定し、エントリをBOUND状態のままにします。
Resulting state: NO_BIND or BOUND, as specified.
結果の状態：指定どおり、NO_BINDまたはBOUND。
6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 LEASEQUERY_REPLY is received
6.4.3.7. イベント：EVE_DHCP_LEASEQUERY-成功したDHCPv6 LEASEQUERY_REPLYを受信
The message MUST be forwarded.
メッセージを転送する必要があります。
The message should be in response to the LEASEQUERY message sent in Section 6.4.2. The related binding entry can be determined based on the address in the IA Address option in the LEASEQUERY-REPLY message. The Lifetime field of the corresponding binding entry is set to the sum of the lease time in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME.
メッセージは、セクション6.4.2で送信されたLEASEQUERYメッセージに応答する必要があります。関連するバインディングエントリは、LEASEQUERY-REPLYメッセージのIAアドレスオプションのアドレスに基づいて決定できます。対応するバインディングエントリのLifetimeフィールドは、LEASEQUERY-REPLYメッセージのリース時間とMAX_DHCP_RESPONSE_TIMEの合計に設定されます。
Resulting state: BOUND: The binding has been set up.
結果の状態：BOUND：バインディングがセットアップされました。
The following events are ignored if received while the indicated entry is in the BOUND state. Any required action will be the result of the next message in the client/server exchange.
以下のイベントは、示されているエントリーがBOUND状態のときに受信された場合は無視されます。必要なアクションは、クライアント/サーバー交換の次のメッセージの結果です。
o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received
o EVE_DHCP_REQUEST：DHCPv4要求またはDHCPv6要求メッセージが受信されました
o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received
o EVE_DHCP_CONFIRM：DHCPv6確認メッセージを受信しました
o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received
o EVE_DHCP_REBOOT：DHCPv4 Rebootメッセージを受信しました
o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received
o EVE_DHCP_SOLICIT_RC：Rapid Commitオプションを含むDHCPv6要請メッセージを受信しました
The main state transits are listed as follows. Note that not all the details are specified in the table and the diagram.
主な状態遷移は次のとおりです。すべての詳細が表と図に指定されているわけではないことに注意してください。
State Event Action Next State
---------------------------------------------------------------------
NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
INIT_BIND RPL Record lease time BOUND (send leasequery if no lease)
INIT_BIND RPLレコードリース時間BOUND（リースがない場合は、leasequeryを送信します）
INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND
INIT_BIND EVE_ENTRY_EXPIREエントリNO_BINDを削除
BOUND RLS/DCL Remove entry NO_BIND
BOUND RLS / DCLエントリNO_BINDを削除
BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND
BOUND EVE_ENTRY_EXPIREエントリNO_BINDを削除
BOUND RPL Set new lifetime BOUND
BOUND RPL新しいライフタイムを設定BOUND
BOUND LQR Record lease time BOUND
BOUND LQRリース時間の記録BOUND
Figure 9: State Transition Table
図9：状態遷移表
RQ: EVE_DHCP_REQUEST RC: EVE_DHCP_SOLICIT_RC CF: EVE_DHCP_CONFIRM RE: EVE_DHCP_REBOOT RPL: EVE_DHCP_REPLY RLS: EVE_DHCP_RELEASE DCL: EVE_DHCP_DECLINE LQR: EVE_DHCP_LEASEQUERY
RQ：EVE_DHCP_REQUEST RC：EVE_DHCP_SOLICIT_RC CF：EVE_DHCP_CONFIRM RE：EVE_DHCP_REBOOT RPL：EVE_DHCP_REPLY RLS：EVE_DHCP_RELEASE DCL：EVE_DHCP_DECLINE LQR：EVE_DHCP_LEASEQUERY
+-------------+
| |
/--------+ NO_BIND |<--------\
| ----->| | |
| | +-------------+ |EVE_DHCP_RELEASE
EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE
EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE
EVE_DHCP_SOLICIT_RC| | |
EVE_DHCP_REBOOT | | |
| | |
| | |
v | |
+-------------+ +------------+
| | EVE_DHCP_REPLY | |
| INIT_BIND --------------------->| BOUND |<-\
| | | | |
+-------------+ +------------+ |
| |
\--------/
EVE_DHCP_REPLY
EVE_DHCP_LEASEQUERY
Figure 10: Diagram of Transit
図10：トランジットの図
The rationale of the DHCP Snooping Process specified in Section 6 is that if a DHCP client's use of a DHCP address is legitimate, the corresponding DHCP address assignment procedure must have been finished during the attachment of the DHCP client. This is the case when the SAVI device is continuously on the path(s) from the DHCP client to the DHCP server(s)/relay(s). However, there are two cases in which this does not work:
セクション6で指定されたDHCPスヌーピングプロセスの理論的根拠は、DHCPクライアントによるDHCPアドレスの使用が正当である場合、対応するDHCPアドレス割り当て手順は、DHCPクライアントの接続中に完了している必要があるということです。これは、SAVIデバイスがDHCPクライアントからDHCPサーバー/リレーへのパス上に継続的に存在する場合です。ただし、これが機能しない2つのケースがあります。
o Multiple paths: there is more than one feasible link-layer path from the client to the DHCP server/relay, and the SAVI device is not on every one of them. The client may get its address through one of the paths that does not pass through the SAVI device, but packets from the client can travel on paths that pass through the SAVI device, such as when the path through the link-layer network changes. Because the SAVI device could not snoop the DHCP packet exchange procedure, the DHCP Snooping Process cannot set up the corresponding binding.
o 複数のパス：クライアントからDHCPサーバー/リレーへの実行可能なリンク層パスが複数あり、SAVIデバイスがそれらのすべてにあるわけではありません。クライアントは、SAVIデバイスを通過しないパスの1つを介してアドレスを取得する場合がありますが、クライアントからのパケットは、リンク層ネットワークのパスが変更された場合など、SAVIデバイスを通過するパス上を移動できます。 SAVIデバイスはDHCPパケット交換手順をスヌープできなかったため、DHCPスヌーピングプロセスは対応するバインディングをセットアップできません。
o Dynamic path: there is only one feasible link-layer path from the client to the DHCP server/relay, but the path is dynamic due to topology change (for example, some link becomes broken due to failure or some planned change) or link-layer path change. This situation also covers the local-link movement of clients without the address confirm/reconfiguration process. For example, a host changes its attached switch port in a very short time. In such cases, the DHCP Snooping Process will not set up the corresponding binding.
o 動的パス：クライアントからDHCPサーバー/リレーへの実行可能なリンク層パスは1つだけですが、パスはトポロジーの変更（たとえば、一部のリンクが障害または計画的な変更により破損する）またはリンクのために動的ですレイヤーパスの変更。この状況は、アドレスの確認/再構成プロセスなしのクライアントのローカルリンクの移動もカバーします。たとえば、ホストは接続されているスイッチポートを非常に短時間で変更します。そのような場合、DHCPスヌーピングプロセスは対応するバインディングをセットアップしません。
The Data Snooping Process can avoid the permanent blocking of legitimate traffic in case one of these two exceptions occurs. This process is performed on attachments with the Data-Snooping attribute. Data packets without a matching binding entry may trigger this process to set up bindings.
データスヌーピングプロセスでは、これら2つの例外のいずれかが発生した場合に、正当なトラフィックが永続的にブロックされるのを回避できます。このプロセスは、Data-Snooping属性を持つ添付ファイルに対して実行されます。一致するバインディングエントリのないデータパケットは、このプロセスをトリガーしてバインディングをセットアップします。
Snooping data traffic introduces a considerable burden on the processor and ASIC-to-Processor bandwidth of SAVI devices. Because of the overhead of this process, the implementation of this process is OPTIONAL. This function SHOULD be enabled unless the implementation is known to be used in the scenarios without the above exceptions. For example, if the implementation is to be used in networks with tree topology and without host local-link movement, there is no need to implement this process in such scenarios.
データトラフィックをスヌーピングすると、SAVIデバイスのプロセッサとASICからプロセッサへの帯域幅にかなりの負担がかかります。このプロセスのオーバーヘッドのため、このプロセスの実装はオプションです。上記の例外のないシナリオで実装が使用されることがわかっている場合を除き、この関数を有効にする必要があります。たとえば、実装がツリートポロジがあり、ホストのローカルリンクの移動がないネットワークで使用される場合、このようなシナリオでこのプロセスを実装する必要はありません。
This process is not intended to set up a binding whenever a data packet without a matched binding entry is received. Instead, unmatched data packets trigger this process probabilistically, and generally a number of unmatched packets will be discarded before the binding is set up. The parameter(s) of this probabilistic process SHOULD be configurable, defaulting to a situation where data snooping is disabled.
このプロセスは、一致するバインディングエントリのないデータパケットが受信されるたびにバインディングをセットアップすることを目的としていません。代わりに、一致しないデータパケットが確率的にこのプロセスをトリガーし、一般に、バインドが設定される前に、一致しないパケットの数が破棄されます。この確率的プロセスのパラメータは設定可能である必要があり（SHOULD）、デフォルトでデータスヌーピングが無効になっている状況になります。
This process makes use of NS/ARP and DHCP Leasequery to set up bindings. If an address is not used by another client in the network, and the address has been assigned in the network, the address can be bound with the binding anchor of the attachment from which the unmatched packet is received.
このプロセスでは、NS / ARPおよびDHCP Leasequeryを使用してバインディングをセットアップします。アドレスがネットワーク内の別のクライアントによって使用されておらず、そのアドレスがネットワーク内で割り当てられている場合、そのアドレスは、一致しないパケットの受信元であるアタッチメントのバインディングアンカーでバインドできます。
The Data Snooping Process provides an alternative path for binding entries to reach the BOUND state in the exceptional cases explained in Section 7.1 when there are no DHCP messages that can be snooped by the SAVI device.
データスヌーピングプロセスは、SAVIデバイスがスヌーピングできるDHCPメッセージがない場合に、セクション7.1で説明されている例外的なケースでBOUND状態に到達するためのバインディングエントリの代替パスを提供します。
In some of the exceptional cases (especially the dynamic topology case), by the time the binding has reached the BOUND state, the DHCP messages may be passing through the SAVI device. In this case, the events driven by DHCP messages that are expected in the BOUND state in the DHCP Snooping Process may occur, and the binding can be handled by the DHCP Snooping Process state machine.
一部の例外的なケース（特に動的トポロジのケース）では、バインディングがBOUND状態に達するまでに、DHCPメッセージがSAVIデバイスを通過している可能性があります。この場合、DHCPスヌーピングプロセスのBOUND状態で予期されるDHCPメッセージによって駆動されるイベントが発生する可能性があり、バインディングはDHCPスヌーピングプロセスステートマシンで処理できます。
In any event, the lease expiry timeout event will occur even if no others do. This will cause the binding to be deleted and the state to logically return to NO_BIND state. Either the DHCP or the Data Snooping Process will be reinvoked if the lease is still in place. If DHCP messages are still not passing through the SAVI device, there will be a brief disconnection during which data packets passing through the SAVI device will be dropped. The probabilistic initiation of the Data Snooping Process can then take over again and return the binding state to BOUND in due course.
いずれの場合も、他に何もしなくても、リース期限切れタイムアウトイベントが発生します。これにより、バインディングが削除され、状態は論理的にNO_BIND状態に戻ります。リースがまだ有効な場合、DHCPまたはデータスヌーピングプロセスのいずれかが再度呼び出されます。それでもDHCPメッセージがSAVIデバイスを通過しない場合、SAVIデバイスを通過するデータパケットがドロップされるまでの短い切断が発生します。データスヌーピングプロセスの確率論的開始は、その後再び引き継ぎ、やがてバインディング状態をBOUNDに戻すことができます。
The security issues concerning this process are discussed in Section 11.1.
このプロセスに関するセキュリティの問題については、11.1項で説明します。
In addition to NO_BIND and BOUND from Section 6.2, three new states used in this process are listed here. The INIT_BIND state is not used, as it is entered by observing a DHCP message.
セクション6.2のNO_BINDおよびBOUNDに加えて、このプロセスで使用される3つの新しい状態がここにリストされます。 INIT_BIND状態は、DHCPメッセージを監視することによって開始されるため、使用されません。
DETECTION: The address in the entry is undergoing local duplication detection.
検出：エントリのアドレスはローカルで重複を検出しています。
RECOVERY: The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery.
リカバリ：SAVIデバイスは、DHCP Leasequeryを介して、エントリ内のアドレスの割り当てとリース時間をクエリしています。
VERIFY: The SAVI device is verifying that the device connected to the attachment point has a hardware address that matches the one returned in the DHCP Leasequery.
検証：SAVIデバイスは、アタッチメントポイントに接続されているデバイスが、DHCP Leasequeryで返されたアドレスと一致するハードウェアアドレスを持っていることを確認しています。
Because the mechanisms used for the operations carried out while the binding is in these three states operate over unreliable protocols, each operation is carried out twice with a timeout that is triggered if no response is received.
バインディングがこれらの3つの状態にあるときに実行される操作に使用されるメカニズムは信頼性の低いプロトコル上で動作するため、応答が受信されない場合にトリガーされるタイムアウトで各操作が2回実行されます。
To handle the Data Snooping Process, six extra events, described here, are needed in addition to those used by the DHCP Snooping Process (see Section 6.3). If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
データスヌーピングプロセスを処理するには、DHCPスヌーピングプロセスで使用されるイベントに加えて、ここで説明する6つの追加イベントが必要です（セクション6.3を参照）。イベントが新しいバインディングエントリの作成をトリガーする場合、バインディングアンカーのバインディングエントリ制限を超えてはなりません（MUST NOT）。
EVE_DATA_UNMATCH: A data packet without a matched binding is received.
EVE_DATA_UNMATCH：一致するバインディングのないデータパケットが受信されます。
EVE_DATA_CONFLICT: An ARP Reply / Neighbor Advertisement (NA) message against an address in the DETECTION state is received from a host other than the one for which the entry was added (i.e., a host attached at a point other than the one on which the triggering data packet was received).
EVE_DATA_CONFLICT：DETECTION状態のアドレスに対するARP応答/ネイバーアドバタイズ（NA）メッセージが、エントリが追加されたホスト以外のホスト（つまり、トリガーデータパケットが受信されました）。
EVE_DATA_LEASEQUERY:
EVE_DATA_LEASEQUERY：
o IPv4: A DHCPLEASEACTIVE message with the IP Address Lease Time option is received. Note that the DHCPLEASEUNKNOWN and DHCPLEASEUNASSIGNED replies are ignored.
o IPv4：IPアドレスリース時間オプションを含むDHCPLEASEACTIVEメッセージが受信されます。 DHCPLEASEUNKNOWNおよびDHCPLEASEUNASSIGNED応答は無視されることに注意してください。
o IPv6: A successful LEASEQUERY-REPLY is received.
o IPv6：成功したLEASEQUERY-REPLYが受信されます。
EVE_DATA_VERIFY: An ARP Reply / NA message has been received in the VERIFY state from the device connected to the attachment point on which the data packet was received.
EVE_DATA_VERIFY：データパケットが受信された接続ポイントに接続されたデバイスから、VERIFY状態でARP応答/ NAメッセージが受信されました。
The triggering packet should pass the following checks to trigger a valid event:
トリガーパケットは、有効なイベントをトリガーするために次のチェックに合格する必要があります。
o Attribute check: the data packet should be from attachments with the Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages should be from attachments with the DHCP-Snooping attribute.
o 属性チェック：データパケットは、Data-Snooping属性を持つ添付ファイルからのものである必要があります。 DHCPLEASEACTIVE / LEASEQUERY-REPLYメッセージは、DHCPスヌーピング属性を持つ添付ファイルからのものである必要があります。
o Binding limitation check: the data messages must not cause new binding setup on an attachment whose binding entry limitation has been reached (refer to Section 11.5).
o バインディング制限チェック：データメッセージは、バインディングエントリ制限に達した添付ファイルに新しいバインディング設定を引き起こしてはなりません（セクション11.5を参照）。
o Address check: For EVE_DATA_LEASEQUERY, the source address of the DHCPLEASEQUERY messages must pass the check specified in Section 8.2. For EVE_DATA_CONFLICT and EVE_DATA_VERIFY, the source address and target address of the ARP or NA messages must pass the check specified in Section 8.2.
o アドレスチェック：EVE_DATA_LEASEQUERYの場合、DHCPLEASEQUERYメッセージの送信元アドレスは、セクション8.2で指定されたチェックに合格する必要があります。 EVE_DATA_CONFLICTおよびEVE_DATA_VERIFYの場合、ARPまたはNAメッセージのソースアドレスとターゲットアドレスは、セクション8.2で指定されたチェックに合格する必要があります。
o Interval check: the interval between two successive EVE_DATA_UNMATCH events triggered by an attachment MUST be no smaller than DATA_SNOOPING_INTERVAL.
o 間隔のチェック：添付ファイルによってトリガーされる2つの連続するEVE_DATA_UNMATCHイベントの間隔は、DATA_SNOOPING_INTERVALよりも小さくしてはなりません（MUST）。
o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have a matched TID with the corresponding entry.
o TIDチェック：DHCPLEASEACTIVE / LEASEQUERY-REPLYメッセージには、対応するエントリと一致するTIDが必要です。
o Prefix check: the source address of the data packet should be of a valid local prefix, as specified in Section 7 of [RFC7039].
o プレフィックスチェック：[RFC7039]のセクション7で指定されているように、データパケットのソースアドレスは有効なローカルプレフィックスである必要があります。
EVE_DATA_EXPIRE: A timer expires indicating that a response to a hardware address verification message sent in the VERIFY state has not been received within the specified DETECTION_TIMEOUT period.
EVE_DATA_EXPIRE：タイマーが期限切れになり、VERIFY状態で送信されたハードウェアアドレス検証メッセージへの応答が、指定されたDETECTION_TIMEOUT期間内に受信されなかったことを示します。
EVE_ENTRY_EXPIRE: A timer expires after the Lifetime indicated in the relevant BST entry has elapsed. This is identical to the usage in the DHCP Snooping Process.
EVE_ENTRY_EXPIRE：関連するBSTエントリに示されているライフタイムが経過すると、タイマーが期限切れになります。これは、DHCPスヌーピングプロセスでの使用方法と同じです。
The Data Snooping Process involves sending three different messages to other network devices. Each message may be sent up to two times since they are sent over unreliable transports and are sent in different states. The functions defined in this section specify the messages to be sent in the three cases. In each case, the message to be sent depends on whether the triggering data packet is an IPv4 or an IPv6 packet.
データスヌーピングプロセスでは、3つの異なるメッセージを他のネットワークデバイスに送信します。各メッセージは、信頼性の低いトランスポートを介して送信され、さまざまな状態で送信されるため、最大2回送信される場合があります。このセクションで定義されている関数は、3つのケースで送信されるメッセージを指定します。どちらの場合も、送信されるメッセージは、トリガーデータパケットがIPv4パケットかIPv6パケットかによって異なります。
Send a message to check if the source address in the data packet that triggered the Data Snooping Process has a local conflict (that is, it uses an address that is being used by another node):
メッセージを送信して、データスヌーピングプロセスをトリガーしたデータパケットの送信元アドレスにローカル競合があるかどうかを確認します（つまり、別のノードで使用されているアドレスを使用します）。
IPv4 address: Broadcast an Address Resolution Protocol (ARP) Request [RFC826] or an ARP Probe [RFC5227] for the address to the local network. An ARP Response will be expected from the device on the attachment point on which the triggering data packet was received. An ARP Reply received on any other port indicates a duplicate address.
IPv4アドレス：ローカルネットワークへのアドレスのアドレス解決プロトコル（ARP）要求[RFC826]またはARPプローブ[RFC5227]をブロードキャストします。 ARP応答は、トリガーデータパケットが受信された接続ポイントのデバイスから予期されます。他のポートで受信したARP応答は、アドレスが重複していることを示しています。
IPv6 address: Send a Duplicate Address Detection (DAD) message (Neighbor Solicitation message) to the solicited-node multicast address [RFC4861] targeting the address. Ideally, only the host on that point of attachment responds with a Neighbor Advertisement. A Neighbor Advertisement received on any other port indicates a duplicate address.
IPv6アドレス：重複アドレス検出（DAD）メッセージ（近隣要請メッセージ）を、アドレスをターゲットとする要請ノードマルチキャストアドレス[RFC4861]に送信します。理想的には、その接続点にあるホストのみがネイバーアドバタイズメントで応答します。他のポートで受信したネイバーアドバタイズメントは、アドレスが重複していることを示しています。
As both the ARP and DAD processes are unreliable (the packet either to or from the other system may be lost in transit; see [RFC6620]), if there is no response after the DETECTION_TIMEOUT, an EVE_ENTRY_EXPIRE is generated.
ARPとDADの両方のプロセスは信頼できないため（他のシステムとの間のパケットが転送中に失われる可能性があります。[RFC6620]を参照）、DETECTION_TIMEOUTの後に応答がない場合、EVE_ENTRY_EXPIREが生成されます。
Send a DHCPLEASEQUERY message to the DHCP server(s) to determine if it has given out a lease for the source address in the triggering data packet. A list of authorized DHCP servers is kept by the SAVI device. The list should be either preconfigured with the IPv4 and/or IPv6 addresses or dynamically discovered: For networks using IPv4, this can be done by sending DHCPv4 Discover messages and parsing the returned DHCPv4 Offer messages; for networks using IPv6, discovery can be done by sending DHCPv6 SOLICIT messages and parsing the returned ADVERTISE messages. The same TID should be used for all LEASEQUERY messages sent in response to a triggering data message on an attachment point. The TID is generated if the TID field in the BST entry is empty and recorded in the TID field of the BST entry when the first message is sent. Subsequent messages use the TID from the BST entry.
DHCPサーバーにDHCPLEASEQUERYメッセージを送信して、トリガーデータパケットの送信元アドレスにリースを提供しているかどうかを確認します。許可されたDHCPサーバーのリストは、SAVIデバイスによって保持されます。リストは、IPv4アドレスまたはIPv6アドレス、あるいはその両方で事前構成するか、動的に検出する必要があります。IPv4を使用するネットワークの場合、これはDHCPv4 Discoverメッセージを送信し、返されたDHCPv4 Offerメッセージを解析することで実行できます。 IPv6を使用するネットワークの場合、DHCPv6 SOLICITメッセージを送信し、返されたADVERTISEメッセージを解析することにより、検出を行うことができます。接続点のトリガーデータメッセージに応答して送信されるすべてのLEASEQUERYメッセージに同じTIDを使用する必要があります。 TIDは、BSTエントリのTIDフィールドが空の場合に生成され、最初のメッセージが送信されたときにBSTエントリのTIDフィールドに記録されます。後続のメッセージは、BSTエントリのTIDを使用します。
(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to each DHCPv4 server in the list of authorized servers with an IP Address Lease Time option (option 51). If the server has a valid lease for the address, the requested information will be returned in a DHCPLEASEACTIVE message.
（1）IPv4アドレス：DHCPLEASEQUERY [RFC4388]メッセージをIPアドレスで照会し、IPアドレスリース時間オプション（オプション51）を使用して、承認されたサーバーのリスト内の各DHCPv4サーバーに送信します。サーバーにアドレスの有効なリースがある場合、要求された情報はDHCPLEASEACTIVEメッセージで返されます。
(2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP address to each DHCPv6 server in the list of authorized servers using the server address as the link-address in the LEASEQUERY message. If the server has a valid lease for the address, the requested information will be returned in a LEASEQUERY-REPLY message marked as successful (i.e., without an OPTION_STATUS_CODE in the reply). The IA Address option(s) returned contains any IPv6 addresses bound to the same link together with the lease validity time.
（2）IPv6アドレス：サーバーアドレスをLEASEQUERYメッセージのリンクアドレスとして使用して、承認済みサーバーのリスト内の各DHCPv6サーバーにIPアドレスでクエリするLEASEQUERY [RFC5007]メッセージを送信します。サーバーにアドレスの有効なリースがある場合、要求された情報は、成功としてマークされたLEASEQUERY-REPLYメッセージで返されます（つまり、応答にOPTION_STATUS_CODEがありません）。返されるIAアドレスオプションには、リースの有効期間と共に同じリンクにバインドされたIPv6アドレスが含まれます。
As DHCP Leasequeries are an unreliable process (the packet either to or from the server may be lost in transit), if there is no response after the MAX_LEASEQUERY_DELAY, an EVE_DATA_EXPIRE is generated. Note that multiple response messages may be received if the list of authorized servers contains more than one address of the appropriate type and, in the case of DHCPv6, the responses may contain additional addresses for which leases have been allocated.
DHCPリースクエリは信頼性の低いプロセスであるため（サーバーへのパケットまたはサーバーからのパケットは転送中に失われる可能性があります）、MAX_LEASEQUERY_DELAYの後に応答がない場合、EVE_DATA_EXPIREが生成されます。許可されたサーバーのリストに適切なタイプのアドレスが複数含まれている場合、複数の応答メッセージが受信される場合があります。DHCPv6の場合、応答には、リースが割り当てられている追加のアドレスが含まれる場合があります。
Send a message to verify that the link-layer address in the attached device that sent the triggering data packet matches the link-layer address contained in the leasequery response: IPv4 address: Send an ARP Request with the Target Protocol Address set to the IP address in the BST entry. The ARP Request is only sent to the attachment that triggered the binding. If the attached device has the IP address bound to the interface attached to the SAVI device, an ARP Reply should be received containing the hardware address of the interface on the attached device that can be compared with the leasequery value.
メッセージを送信して、トリガーデータパケットを送信した接続デバイスのリンク層アドレスが、leasequery応答に含まれるリンク層アドレスと一致することを確認します。IPv4アドレス：ターゲットプロトコルアドレスがIPアドレスに設定されたARP要求を送信しますBSTエントリ内。 ARP要求は、バインディングをトリガーしたアタッチメントにのみ送信されます。接続されたデバイスのIPアドレスがSAVIデバイスに接続されたインターフェイスにバインドされている場合、リースクエリ値と比較できる接続されたデバイスのインターフェイスのハードウェアアドレスを含むARP応答を受信する必要があります。
IPv6 address: Send a Neighbor Solicitation (NS) message with the target address set to the IP address in the BST entry. The NS is only sent to the attachment that triggered the binding. If the attached device has the IP address bound to the interface attached to the SAVI device, an NA should be received indicating that the attached device has the IP address configured on the interface.
IPv6アドレス：ターゲットアドレスをBSTエントリのIPアドレスに設定して、近隣要請（NS）メッセージを送信します。 NSは、バインディングをトリガーしたアタッチメントにのみ送信されます。接続されたデバイスのIPアドレスがSAVIデバイスに接続されたインターフェースにバインドされている場合、NAを受信して、接続されたデバイスのIPアドレスがインターフェースに設定されていることを示します。
As both the ARP and NS/NA processes are unreliable (the packet either to or from the other system may be lost in transit; see [RFC6620]), if there is no response after the DETECTION_TIMEOUT, an EVE_DATA_EXPIRE is generated.
ARPプロセスとNS / NAプロセスの両方が信頼できないため（他のシステムとの間のパケットが転送中に失われる可能性があります。[RFC6620]を参照）、DETECTION_TIMEOUTの後に応答がない場合、EVE_DATA_EXPIREが生成されます。
7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding is received
7.6.1. イベント：EVE_DATA_UNMATCH：一致するバインディングのないデータパケットが受信されました
Make a probabilistic determination as to whether to act on this event. The probability may be configured or calculated based on the state of the SAVI device. This probability should be low enough to mitigate the damage from DoS attacks against this process.
このイベントに対処するかどうかについて、確率的な決定を行います。確率は、SAVIデバイスの状態に基づいて設定または計算できます。この確率は、このプロセスに対するDoS攻撃による被害を軽減するのに十分なほど低くなければなりません。
Create a new entry in the BST. Set the Binding Anchor field to the corresponding binding anchor of the attachment. Set the Address field to the source address of the packet.
BSTに新しいエントリを作成します。 [バインディングアンカー]フィールドを、添付ファイルの対応するバインディングアンカーに設定します。 [アドレス]フィールドをパケットの送信元アドレスに設定します。
Address conflicts MUST be detected and prevented.
アドレスの競合を検出して防止する必要があります。
If local address detection is performed: Set the State field to DETECTION. Set the Lifetime of the created entry to DETECTION_TIMEOUT. Set the Timeouts field to 0. Start the detection of any local address conflicts by sending a Duplicate Address Detection Message (Section 7.5.1). Transition to DETECTION state.
ローカルアドレス検出が実行される場合：[状態]フィールドを[検出]に設定します。作成したエントリの存続期間をDETECTION_TIMEOUTに設定します。 [タイムアウト]フィールドを0に設定します。重複アドレス検出メッセージ（セクション7.5.1）を送信して、ローカルアドレスの競合の検出を開始します。 DETECTION状態に移行します。
If local address detection is not performed: Set the State field to RECOVERY. Set the Lifetime of the created entry to LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Transition to RECOVERY state.
ローカルアドレス検出が実行されない場合：[状態]フィールドをRECOVERYに設定します。作成したエントリのライフタイムをLEASEQUERY_DELAYに設定します。 [タイムアウト]フィールドを0に設定します。1つ以上のLEASEQUERYメッセージを送信することにより、送信元IPアドレスに関連付けられたDHCPリースの回復を開始します（7.5.2項）。リカバリー状態に移行します。
The packet that triggers this event SHOULD be discarded.
このイベントをトリガーするパケットは破棄する必要があります。
An example of the BST entry during duplicate address detection is illustrated in Figure 11.
重複アドレス検出中のBSTエントリの例を図11に示します。
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 |
+--------+-------+---------+-----------------------+-----+----------+
Figure 11: Binding Entry in BST on Data-Triggered Initialization
図11：データトリガー初期化時のBSTのエントリのバインド
Resulting state: DETECTION - The address in the entry is undergoing local duplication detection - or RECOVERY - The DHCP lease(s) associated with the address is being queried.
結果の状態：DETECTION-エントリのアドレスはローカルで重複を検出しています-またはRECOVERY-アドレスに関連付けられているDHCPリースが照会されています。
EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system.
EVE_DATA_CONFLICT：予期しないシステムからARP応答/ NAメッセージが受信されました。
EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is received.
EVE_DATA_LEASEQUERY：有効なDHCPLEASEACTIVEまたはLEASEQUERY-REPLYを受信しました。
EVE_DATA_VERIFY: A valid ARP Reply or NA message is received from the attached device.
EVE_DATA_VERIFY：接続されたデバイスから有効なARP応答またはNAメッセージを受信しました。
All EVE_DHCP_* events defined in Section 6.3.2 are treated as described in the DHCP Snooping Process (Section 6.4.1) and may result in that process being triggered.
セクション6.3.2で定義されているすべてのEVE_DHCP_ *イベントは、DHCPスヌーピングプロセス（セクション6.4.1）で説明されているように処理され、そのプロセスがトリガーされる可能性があります。
EVE_ENTRY_EXPIRE: Expiration of the DECTECTION_TIMEOUT
EVE_ENTRY_EXPIRE：DECTECTION_TIMEOUTの有効期限
EVE_DATA_EXPIRE: Expiration of the DECTECTION_TIMEOUT
EVE_DATA_EXPIRE：DECTECTION_TIMEOUTの有効期限
When this event occurs, no address conflict has been detected during the previous DETECTION_TIMEOUT period.
このイベントが発生した場合、前のDETECTION_TIMEOUT期間中にアドレスの競合は検出されていません。
If the Timeouts field in the BST entry is 0: Set the Lifetime of the BST entry to DETECTION_TIMEOUT. Set the Timeouts field to 1. Restart the detection of any local address conflicts by sending a second Duplicate Address Detection Message (Section 7.5.1). Remain in DETECTION state.
BSTエントリの[タイムアウト]フィールドが0の場合：BSTエントリのライフタイムをDETECTION_TIMEOUTに設定します。 [タイムアウト]フィールドを1に設定します。2番目の重複アドレス検出メッセージ（セクション7.5.1）を送信して、ローカルアドレスの競合の検出を再開します。 DETECTION状態のままにします。
If the Timeouts field in the BST entry is 1:
BSTエントリの[タイムアウト]フィールドが1の場合：
Assume that there is no local address conflict. Set the State field to RECOVERY. Set the Lifetime of the BST entry to LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Transition to RECOVERY state.
ローカルアドレスの競合がないと仮定します。 [状態]フィールドをRECOVERYに設定します。 BSTエントリの存続期間をLEASEQUERY_DELAYに設定します。 [タイムアウト]フィールドを0に設定します。1つ以上のLEASEQUERYメッセージを送信することにより、送信元IPアドレスに関連付けられたDHCPリースの回復を開始します（7.5.2項）。リカバリー状態に移行します。
An example of the entry is illustrated in Figure 12.
エントリの例を図12に示します。
+--------+-------+----------+----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+----------+----------------------+-----+----------+
| Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+----------+----------------------+-----+----------+
Figure 12: Binding Entry in BST on Leasequery
図12：LeasequeryのBSTのエントリのバインド
Resulting state: DETECTION - If a second local conflict period is required - or RECOVERY - The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery.
結果の状態：DETECTION-2回目のローカル競合期間が必要な場合-またはRECOVERY-SAVIデバイスは、DHCP Leasequeryを通じてエントリのアドレスの割り当てとリース時間をクエリしています。
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message Received from Unexpected System
7.7.2. イベント：EVE_DATA_CONFLICT：予期しないシステムから受信したARP応答/ NAメッセージ
Remove the entry.
エントリを削除します。
Resulting state: NO_BIND - No binding has been set up.
結果の状態：NO_BIND-バインドが設定されていません。
EVE_DATA_UNMATCH: A data packet without a matched binding is received
EVE_DATA_UNMATCH：一致するバインディングのないデータパケットが受信された
All EVE_DHCP_* events defined in Section 6.3.2
セクション6.3.2で定義されているすべてのEVE_DHCP_ *イベント
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received
EVE_DHCP_REBIND：DHCPv4 RebindまたはDHCPv6 Rebindメッセージが受信された
7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received
7.8.1. イベント：EVE_DATA_LEASEQUERY：有効なDHCPLEASEACTIVEまたは成功したLEASEQUERY-REPLYが受信された
Set the State in the BST entry to VERIFY. Depending on the type of triggering source IP address, process the received DHCP Leasequery response:
BSTエントリの状態をVERIFYに設定します。トリガーする送信元IPアドレスのタイプに応じて、受信したDHCP Leasequery応答を処理します。
IPv4 address: Update the Lifetime field in the BST entry to the sum of the value encoded in the IP Address Lease Time option of the DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Record the value of the "chaddr" field (hardware address) in the message for checking against the hardware address received during verification in the next state. Set the Timeouts field to 0. Start the verification process by sending an Address Verification Message (see Section 7.5.3). Transition to VERIFY state. Start an additional verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated.
IPv4アドレス：BSTエントリのLifetimeフィールドを、DHCPLEASEACTIVEメッセージのIPアドレスリース時間オプションでエンコードされた値とMAX_DHCP_RESPONSE_TIMEの合計に更新します。 「chaddr」フィールド（ハードウェアアドレス）の値をメッセージに記録し、次の状態での検証中に受信したハードウェアアドレスと照合してチェックします。 「タイムアウト」フィールドを0に設定します。アドレス検証メッセージを送信して検証プロセスを開始します（セクション7.5.3を参照）。 VERIFY状態に移行します。 DETECTION_TIMEOUTの期間で追加の検証タイマーを開始します。これが期限切れになると、EVE_DATA_EXPIREイベントが生成されます。
IPv6 address: Update the Lifetime field in the BST entry to the sum of the valid lifetime extracted from the OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME. Set the Timeouts field to 0. Start the verification process by sending an Address Verification Message (see Section 7.5.3). Transition to VERIFY state. Start an additional verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated.
IPv6アドレス：BSTエントリのLifetimeフィールドを、LEASEQUERY-REPLYメッセージのOPTION_CLIENT_DATAオプションから抽出された有効なライフタイムとMAX_DHCP_RESPONSE_TIMEの合計に更新します。 「タイムアウト」フィールドを0に設定します。アドレス検証メッセージを送信して検証プロセスを開始します（セクション7.5.3を参照）。 VERIFY状態に移行します。 DETECTION_TIMEOUTの期間で追加の検証タイマーを開始します。これが期限切れになると、EVE_DATA_EXPIREイベントが生成されます。
If multiple addresses are received in the LEASEQUERY-REPLY, new BST entries MUST be created for the additional addresses using the same binding anchor. The entries are created with state set to VERIFY and the other fields set as described in this section for the triggering source IP address. Also, start the verification process and start verification timers for each additional address.
LEASEQUERY-REPLYで複数のアドレスが受信された場合、同じバインディングアンカーを使用して、追加のアドレスに対して新しいBSTエントリを作成する必要があります。エントリは、状態をVERIFYに設定して作成され、その他のフィールドは、このセクションで説明されているトリガー元のIPアドレスに対して設定されています。また、検証プロセスを開始し、追加アドレスごとに検証タイマーを開始します。
Resulting state: VERIFY - Awaiting verification or otherwise of the association of the IP address with the connected interface.
結果の状態：VERIFY-接続されたインターフェースとのIPアドレスの関連付けの検証またはその他の待機中。
Depending on the value of the Timeouts field in the BST entry, either send repeat LEASEQUERY messages or discard the binding:
BSTエントリのTimeoutsフィールドの値に応じて、繰り返しLEASEQUERYメッセージを送信するか、バインディングを破棄します。
If the Timeouts field in the BST entry is 0: No responses to the LEASEQUERY message(s) sent have been received during the first LEASEQUERY_DELAY period. Set the Lifetime of the BST entry to LEASEQUERY_DELAY. Set the Timeouts field to 1. Restart the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Remain in RECOVERY state.
BSTエントリのTimeoutsフィールドが0の場合：最初のLEASEQUERY_DELAY期間中に、送信されたLEASEQUERYメッセージへの応答が受信されていません。 BSTエントリの存続期間をLEASEQUERY_DELAYに設定します。 [タイムアウト]フィールドを1に設定します。1つ以上のLEASEQUERYメッセージを送信して、送信元IPアドレスに関連付けられたDHCPリースの回復を再開します（7.5.2項）。リカバリ状態を維持します。
If the Timeouts field in the BST entry is 1: No responses to the LEASEQUERY messages sent during two LEASEQUERY_DELAY periods were received. Assume that no leases exist and hence that the source IP address is bogus. Delete the BST entry. Transition to NO_BIND state.
BSTエントリのタイムアウトフィールドが1の場合：2つのLEASEQUERY_DELAY期間中に送信されたLEASEQUERYメッセージへの応答が受信されませんでした。リースが存在しないため、送信元IPアドレスが偽であると想定します。 BSTエントリを削除します。 NO_BIND状態に遷移します。
Resulting state: RECOVERY - If repeat leasequeries are sent - or NO_BIND - If no successful responses to LEASEQUERY messages have been received.
結果の状態：RECOVERY-リースクエリが繰り返し送信された場合-またはNO_BIND-LEASEQUERYメッセージへの正常な応答が受信されなかった場合。
EVE_DATA_UNMATCH: A data packet without a matched binding is received
EVE_DATA_UNMATCH：一致するバインディングのないデータパケットが受信された
EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system
EVE_DATA_CONFLICT：予期しないシステムからARP応答/ NAメッセージを受信しました
EVE_DATA_VERIFY: A valid ARP Reply or NA message is received from the attached device
EVE_DATA_VERIFY：接続されたデバイスから有効なARP応答またはNAメッセージを受信しました
All EVE_DHCP_* events defined in Section 6.3.2
セクション6.3.2で定義されているすべてのEVE_DHCP_ *イベント
EVE_DATA_EXPIRE: Expiration of the DECTECTION_TIMEOUT
EVE_DATA_EXPIRE：DECTECTION_TIMEOUTの有効期限
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received
7.9.1. イベント：EVE_DATA_LEASEQUERY：有効なDHCPLEASEACTIVEまたは成功したLEASEQUERY-REPLYが受信された
If LEASEQUERY messages were sent to more than one DHCP server during RECOVERY state, additional successful leasequery responses may be received relating to the source IP address. The conflict resolution mechanisms specified in Section 6.8 of [RFC4388] and Section 4.3.4 of [RFC5007] can be used to determine the message from which values are used to update the BST Lifetime entry and the hardware address obtained from DHCP, as described in Section 7.8.1. In the case of DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses as described in Section 7.8.1. If so, additional BST entries MUST be created or ones previously created updated as described in that section.
RECOVERY状態でLEASEQUERYメッセージが複数のDHCPサーバーに送信された場合、送信元IPアドレスに関連して、追加の成功したleasequery応答が受信されることがあります。 [RFC4388]のセクション6.8と[RFC5007]のセクション4.3.4で指定されている競合解決メカニズムを使用して、BSTライフタイムエントリとDHCPから取得したハードウェアアドレスを更新するために使用される値のメッセージを決定できます。セクション7.8.1。 DHCPv6クエリの場合、LEASEQUERY-REPLYには、セクション7.8.1で説明されている追加のアドレスが含まれる場合があります。その場合は、追加のBSTエントリを作成するか、そのセクションで説明されているように、以前に作成したエントリを更新する必要があります。
Resulting state: VERIFY (no change).
結果の状態：VERIFY（変化なし）。
7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is received from the device attached via the binding anchor
7.9.2. イベント：EVE_DATA_VERIFY：バインディングアンカーを介して接続されたデバイスから有効なARP応答またはNAを受信しました
Depending on the type of triggering source IP address, this event may indicate that the device attached via the binding anchor in the BST entry is configured by DHCP using the IP address:
トリガーしているソースIPアドレスのタイプによっては、このイベントは、BSTエントリのバインディングアンカーを介して接続されているデバイスが、IPアドレスを使用してDHCPによって構成されていることを示している可能性があります。
IPv4 address: Check that the value of the sender hardware address in the ARP Reply matches the saved "chaddr" field (hardware address) from the previously received DHCPLEASEACTIVE message. If not, ignore this event; a subsequent retry may provide verification. If the hardware addresses match, the binding entry has been verified.
IPv4アドレス：ARP応答の送信側ハードウェアアドレスの値が、以前に受信したDHCPLEASEACTIVEメッセージから保存された「chaddr」フィールド（ハードウェアアドレス）と一致することを確認します。そうでない場合は、このイベントを無視してください。その後の再試行により、検証が提供される場合があります。ハードウェアアドレスが一致する場合、バインディングエントリは確認されています。
IPv6 address: Simple receipt of a valid NA from the triggering source IP address at the binding anchor port provides verification for the binding entry.
IPv6アドレス：バインディングアンカーポートでトリガー元のIPアドレスから有効なNAを受信するだけで、バインディングエントリの検証が行われます。
If the binding entry has been verified, set the state in the BST entry to BOUND. Clear the TID field. Cancel the verification timer.
バインディングエントリが確認されている場合は、BSTエントリの状態をBOUNDに設定します。 TIDフィールドをクリアします。確認タイマーをキャンセルします。
Resulting state: VERIFY (no change) - If the IPv4 DHCPLEASEQUERY "chaddr" address does not match the ARP Reply hardware address. Otherwise, the resulting state is BOUND.
結果の状態：VERIFY（変更なし）-IPv4 DHCPLEASEQUERY "chaddr"アドレスがARP応答ハードウェアアドレスと一致しない場合。それ以外の場合、結果の状態はBOUNDです。
The DHCP lease lifetime has expired before the entry could be verified. Remove the entry. Transition to NO_BIND state.
エントリを確認する前に、DHCPリースの有効期限が切れました。エントリを削除します。 NO_BIND状態に遷移します。
Resulting state: NO_BIND - No binding has been set up.
結果の状態：NO_BIND-バインドが設定されていません。
Depending on the value of the Timeouts field in the BST entry, either send a repeat validation message or discard the binding:
BSTエントリのTimeoutsフィールドの値に応じて、再検証メッセージを送信するか、バインディングを破棄します。
If the Timeouts field in the BST entry is 0: No response to the verification message sent has been received during the first DETECTION_TIMEOUT period. Set the Timeouts field to 1. Restart the verification process by sending an Address Verification Message (see Section 7.5.3). Start a verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated. Remain in VERIFY state.
BSTエントリのTimeoutsフィールドが0の場合：最初のDETECTION_TIMEOUT期間中に、送信された検証メッセージに対する応答が受信されていません。 「タイムアウト」フィールドを1に設定します。アドレス検証メッセージを送信して、検証プロセスを再開します（セクション7.5.3を参照）。 DETECTION_TIMEOUTの期間で検証タイマーを開始します。これが期限切れになると、EVE_DATA_EXPIREイベントが生成されます。 VERIFY状態のままにします。
If the Timeouts field in the BST entry is 1: No responses to the verification messages sent during two DETECTION_TIMEOUT periods were received. Assume that the configuration of the triggering source IP address cannot be verified and hence that the source IP address is bogus. Delete the BST entry. Transition to NO_BIND state.
BSTエントリのTimeoutsフィールドが1の場合：2つのDETECTION_TIMEOUT期間中に送信された検証メッセージへの応答が受信されませんでした。トリガーとなる送信元IPアドレスの構成を検証できないため、送信元IPアドレスが偽物であると想定します。 BSTエントリを削除します。 NO_BIND状態に遷移します。
Resulting state: VERIFY - Additional verification message sent - or NO_BIND - No binding has been set up.
結果の状態：VERIFY-追加の検証メッセージが送信されました-またはNO_BIND-バインドが設定されていません
EVE_DATA_UNMATCH: A data packet without a matched binding is received
EVE_DATA_UNMATCH：一致するバインディングのないデータパケットが受信された
EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system
EVE_DATA_CONFLICT：予期しないシステムからARP応答/ NAメッセージを受信しました
All EVE_DHCP_* events defined in Section 6.3.2
セクション6.3.2で定義されているすべてのEVE_DHCP_ *イベント
Upon entry to the BOUND state, control of the system continues as if a DHCP message assigning the address has been observed, as in Section 6.4.3. The BST entry has been restored.
BOUND状態に入ると、セクション6.4.3のように、アドレスを割り当てるDHCPメッセージが確認されたかのように、システムの制御が続行されます。 BSTエントリが復元されました。
Note that the TID field contains no value after the binding state changes to BOUND. The TID field is recovered from snooping DHCP Renew/Rebind messages if these are observed as described in the DHCP Snooping Process. Because TID is used to associate binding entries with messages from DHCP servers, it must be recovered or else a number of state transitions of this mechanism will not be executed normally.
バインド状態がBOUNDに変わった後、TIDフィールドには値が含まれないことに注意してください。 DHCPスヌーピングプロセスで説明されているように、これらが観察された場合、TIDフィールドはスヌーピングDHCP Renew / Rebindメッセージから回復されます。 TIDはDHCPサーバーからのメッセージにバインディングエントリを関連付けるために使用されるため、回復する必要があります。そうしないと、このメカニズムのいくつかの状態遷移が正常に実行されません。
The main state transitions are listed as follows.
主な状態遷移は次のとおりです。
State Event Action Next State
---------------------------------------------------------------------
NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION
DETECTION EVE_ENTRY_EXPIRE 1 Repeat duplicate detect DETECTION
DETECTION EVE_ENTRY_EXPIRE 1重複検出の繰り返しDETECTION
DETECTION EVE_ENTRY_EXPIRE 2 Start leasequery RECOVERY
DETECTION EVE_ENTRY_EXPIRE 2 leasequery RECOVERYを開始します
DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
DETECTION EVE_DATA_CONFLICTエントリNO_BINDを削除
RECOVERY EVE_ENTRY_EXPIRE 1 Repeat leasequery RECOVERY
RECOVERY EVE_ENTRY_EXPIRE 1 leasequery RECOVERYを繰り返す
RECOVERY EVE_ENTRY_EXPIRE 2 No lease found; remove entry NO_BIND
RECOVERY EVE_ENTRY_EXPIRE 2リースが見つかりません。エントリNO_BINDを削除します
RECOVERY EVE_DATA_LEASEQUERY Set lease time; start verify VERIFY
RECOVERY EVE_DATA_LEASEQUERYリース時間を設定します。検証を開始します
VERIFY EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND
VERIFY EVE_ENTRY_EXPIREリースの有効期限。エントリNO_BINDを削除します
VERIFY EVE_DATA_LEASEQUERY Resolve lease conflict(s) VERIFY
VERIFY EVE_DATA_LEASEQUERYリースの競合を解決VERIFY
VERIFY EVE_DATA_VERIFY Finish validation BOUND or NO_BIND
VERIFY EVE_DATA_VERIFY検証を終了BOUNDまたはNO_BIND
VERIFY EVE_DATA_EXPIRE 1 Repeat verify VERIFY
VERIFY EVE_DATA_EXPIRE 1確認を繰り返しますVERIFY
VERIFY EVE_DATA_EXPIRE 2 Verify failed; remove entry NO_BIND
VERIFY EVE_DATA_EXPIRE 2検証に失敗しました。エントリNO_BINDを削除します
BOUND EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND
BOUND EVE_ENTRY_EXPIREリースの有効期限。エントリNO_BINDを削除します
BOUND RENEW/REBIND Record TID BOUND
BOUND RENEW / REBINDレコードTID BOUND
Figure 13: State Transition Table
図13：状態遷移表
+-------------+ EVE_ENTRY_EXPIRE
/---------+ |<------------------------\
| | NO_BIND | EVE_DATA_EXPIRE |
EVE_DATA_UNMATCH | /----->| |<----\ (2nd VRF_DELAY) |
| | +-------------+ | |
| | EVE_ENTRY_EXPIRE | |
| | (2nd LQ_DELAY) | |
EVE_ENTRY_EXPIRE | | | EVE_ENTRY_EXPIRE |
(1st DAD_DELAY) | | | (1st LQ_DELAY) |
/------\ | | | /--------\ |
| | | | EVE_DATA_CONFLICT \---\ | | |
| v v | | v | |
| +-------------+ EVE_ENTRY_EXPIRE +------------+ | |
| | | (2nd DAD_DELAY) | | | |
\----+ DETECTION ------------------------>| RECOVERY +--/ |
| | | | |
+-------------+ (To NO_BIND) +------------+ |
^ | |
| EVE_DATA_LEASEQUERY | |
/----------\ | | |
| | | EVE_ENTRY_EXPIRE | |
EVE_DHCP_RENEW| v | v |
EVE_DHCP_REBIND| +-------------+ +-------------+ |
| | | | +--/
\----+ BOUND |<---------------+ VERIFY |
| | EVE_DATA_VERIFY| |<-\
+-------------+ +-------------+ |
| |
\----------/
EVE_DATA_LEASEQUERY
EVE_DATA_EXPIRE
(1st VRF_DELAY)
Figure 14: Diagram of Transit
図14：トランジットの図
LQ_DELAY: MAX_LEASEQUERY_DELAY VRF_DELAY: DETECTION_TIMEOUT
LQ_DELAY：MAX_LEASEQUERY_DELAY VRF_DELAY：DETECTION_TIMEOUT
This section specifies how to use bindings to filter out packets with spoofed source addresses.
このセクションでは、スプーフィングされた送信元アドレスを持つパケットをフィルタリングするためにバインディングを使用する方法を指定します。
Filtering policies are different for data packets and control packets. DHCP, ARP, and Neighbor Discovery Protocol (NDP) [RFC4861] messages are classified as control packets. All other packets are classified as data packets.
フィルタリングポリシーは、データパケットと制御パケットで異なります。 DHCP、ARP、および近隣探索プロトコル（NDP）[RFC4861]メッセージは、制御パケットとして分類されます。他のすべてのパケットはデータパケットとして分類されます。
Data packets from attachments with the Validating attribute TRUE MUST have their source addresses validated. There is one exception to this rule.
Validating属性がTRUEの添付ファイルからのデータパケットは、送信元アドレスが検証されている必要があります。この規則には1つの例外があります。
A packet whose source IP address is a link-local address cannot be checked against DHCP assignments, as it is not assigned using DHCP. Note: as explained in Section 1, a SAVI solution for link-local addresses, e.g., FCFS SAVI [RFC6620], can be enabled to check packets with a link-local source address.
送信元IPアドレスがリンクローカルアドレスであるパケットは、DHCPを使用して割り当てられていないため、DHCP割り当てに対してチェックできません。注：セクション1で説明したように、リンクローカルアドレスのSAVIソリューション（FCFS SAVI [RFC6620]など）を有効にすると、リンクローカルソースアドレスを持つパケットをチェックできます。
If the source IP address of a packet is not a link-local address, but there is not a matching entry in the BST with BOUND state, this packet MUST be discarded. However, the packet may trigger the Data Snooping Process (Section 7) if the Data-Snooping attribute is set on the attachment.
パケットの送信元IPアドレスがリンクローカルアドレスではないが、BOUND状態のBSTに一致するエントリがない場合、このパケットは破棄する必要があります。ただし、添付ファイルにデータスヌーピング属性が設定されている場合、パケットはデータスヌーピングプロセス（セクション7）をトリガーする可能性があります。
Data packets from an attachment with the Validating attribute set FALSE will be forwarded without having their source addresses validated.
Validating属性がFALSEに設定された添付ファイルからのデータパケットは、送信元アドレスが検証されずに転送されます。
The SAVI device MAY log packets that fail source address validation.
SAVIデバイスは、送信元アドレス検証に失敗したパケットをログに記録する場合があります。
For attachments with the Validating attribute:
Validating属性を持つ添付ファイルの場合：
DHCPv4 Client-to-Server messages in which the source IP address is neither all zeros nor bound with the corresponding binding anchor in the BST MUST be discarded.
送信元IPアドレスがすべて0でもなく、BSTの対応するバインディングアンカーにバインドされていないDHCPv4クライアントからサーバーへのメッセージは、破棄する必要があります。
DHCPv6 Client-to-Server messages in which the source IP address is neither a link-local address nor bound with the corresponding binding anchor in the BST MUST be discarded.
送信元IPアドレスがリンクローカルアドレスでも、BSTの対応するバインディングアンカーでバインドされていないDHCPv6クライアントからサーバーへのメッセージは、破棄する必要があります。
NDP messages in which the source IP address is neither a link-local address nor bound with the corresponding binding anchor MUST be discarded.
送信元IPアドレスがリンクローカルアドレスでも、対応するバインディングアンカーでバインドされていないNDPメッセージは破棄する必要があります。
NA messages in which the target address is neither a link-local address nor bound with the corresponding binding anchor MUST be discarded.
ターゲットアドレスがリンクローカルアドレスでも対応するバインディングアンカーでバインドされていないNAメッセージは破棄する必要があります。
ARP messages in which the protocol is IP and the sender protocol address is neither all zeros nor bound with the corresponding binding anchor MUST be discarded.
プロトコルがIPであり、送信側プロトコルアドレスがすべてゼロでなく、対応するバインディングアンカーにバインドされていないARPメッセージは、破棄する必要があります。
ARP Reply messages in which the target protocol address is not bound with the corresponding binding anchor MUST be discarded.
ターゲットプロトコルアドレスが対応するバインディングアンカーにバインドされていないARP応答メッセージは破棄する必要があります。
For attachments with other attributes:
他の属性を持つ添付ファイルの場合：
DHCP Server-to-Client messages not from attachments with the DHCP-Trust attribute or Trust attribute MUST be discarded.
DHCP-Trust属性またはTrust属性を持つ添付ファイルからのDHCPサーバーからクライアントへのメッセージは破棄する必要があります。
For attachments with no attribute:
属性のない添付ファイルの場合：
DHCP Server-to-Client messages from such attachments MUST be discarded.
このような添付ファイルからのDHCPサーバーからクライアントへのメッセージは破棄する必要があります。
The SAVI device MAY record any messages that are discarded.
SAVIデバイスは、破棄されたメッセージを記録してもよい（MAY）。
If a SAVI device reboots, the information kept in volatile memory will be lost. This section specifies the restoration of attribute configuration and the BST.
SAVIデバイスが再起動すると、揮発性メモリに保持されている情報は失われます。このセクションでは、属性構成とBSTの復元について説明します。
The loss of attribute configuration will not break the network: no action will be performed on traffic from attachments with no attribute. However, the loss of attribute configuration makes this SAVI function unable to work.
属性の設定が失われてもネットワークが壊れることはありません。属性のないアタッチメントからのトラフィックに対してアクションは実行されません。ただし、属性構成が失われると、このSAVI機能が機能しなくなります。
To avoid the loss of binding anchor attribute configuration, the configuration MUST be able to be stored in non-volatile storage. After the reboot of the SAVI device, if the configuration of binding anchor attributes is found in non-volatile storage, the configuration MUST be used.
アンカー属性のバインド構成の損失を回避するには、構成を不揮発性ストレージに保存できる必要があります。 SAVIデバイスの再起動後、バインディングアンカー属性の構成が不揮発性ストレージで見つかった場合は、その構成を使用する必要があります。
The loss of binding state will cause the SAVI devices to discard legitimate traffic. Simply using the Data Snooping Process to recover a large number of bindings is a heavy overhead and may cause considerable delay. Thus, recovering bindings from non-volatile storage, as specified below, is RECOMMENDED.
バインディング状態が失われると、SAVIデバイスは正当なトラフィックを破棄します。データスヌーピングプロセスを使用して多数のバインディングを回復するだけでは、オーバーヘッドが大きくなり、かなりの遅延が発生する可能性があります。したがって、以下に示すように、不揮発性ストレージからバインディングを回復することをお勧めします。
Binding entries MAY be saved into non-volatile storage whenever a new binding entry changes to BOUND state. If a binding with BOUND state is removed, the saved entry MUST be removed correspondingly. The time when each binding entry is established is also saved.
バインディングエントリは、新しいバインディングエントリがBOUND状態に変化するたびに、不揮発性ストレージに保存される場合があります。 BOUND状態のバインディングが削除された場合、保存されたエントリもそれに応じて削除する必要があります。各バインディングエントリが確立される時間も保存されます。
If the BST is stored in non-volatile storage, the SAVI device SHOULD restore binding state from the non-volatile storage immediately after reboot. Using the time when each binding entry was saved, the SAVI device should check whether the entry has become obsolete by comparing the saved lifetime and the difference between the current time and time when the binding entry was established. Obsolete entries that would have expired before the reboot MUST be removed.
BSTが不揮発性ストレージに保存されている場合、SAVIデバイスは、再起動直後に不揮発性ストレージからバインディング状態を復元する必要があります（SHOULD）。 SAVIデバイスは、各バインディングエントリが保存された時間を使用して、保存されているライフタイムと現在の時間とバインディングエントリが確立された時間との差を比較することにより、エントリが古くなっているかどうかを確認する必要があります。再起動する前に期限切れになった古いエントリは削除する必要があります。
The following constants are recommended for use in this context:
このコンテキストでは、次の定数を使用することをお勧めします。
o MAX_DHCP_RESPONSE_TIME (120s): Maximum Solicit timeout value (SOL_MAX_RT from [RFC3315])
o MAX_DHCP_RESPONSE_TIME（120秒）：最大要請タイムアウト値（[RFC3315]のSOL_MAX_RT）
o MAX_LEASEQUERY_DELAY (10s): Maximum LEASEQUERY timeout value (LQ_MAX_RT from [RFC5007])
o MAX_LEASEQUERY_DELAY（10秒）：最大LEASEQUERYタイムアウト値（[RFC5007]のLQ_MAX_RT）
o DETECTION_TIMEOUT (0.5s): Maximum duration of a hardware address verification step in the VERIFY state (TENT_LT from [RFC6620])
o DETECTION_TIMEOUT（0.5s）：VERIFY状態でのハードウェアアドレス検証ステップの最大時間（[RFC6620]のTENT_LT）
o DATA_SNOOPING_INTERVAL: Minimum interval between two successive EVE_DATA_UNMATCH events triggered by an attachment. Recommended interval: 60s and configurable
o DATA_SNOOPING_INTERVAL：添付ファイルによってトリガーされる2つの連続するEVE_DATA_UNMATCHイベント間の最小間隔。推奨間隔：60秒および構成可能
o OFFLINK_DELAY: Period after a client is last detected before the binding anchor is being removed. Recommended delay: 30s
o OFFLINK_DELAY：クライアントが最後に検出されてから、バインディングアンカーが削除されるまでの期間。推奨される遅延：30秒
There are two security problems with the Data Snooping Process (Section 7):
データスヌーピングプロセスには、2つのセキュリティ問題があります（セクション7）。
(1) The Data Snooping Process is costly, but an attacker can trigger it simply through sending a number of data packets. To avoid Denial-of-Service attacks against the SAVI device itself, the Data Snooping Process MUST be rate limited. A constant DATA_SNOOPING_INTERVAL is used to control the frequency. Two Data Snooping Processes on one attachment MUST be separated by a minimum interval time of DATA_SNOOPING_INTERVAL. If this value is changed, the value needs to be large enough to minimize DoS attacks.
（1）データスヌーピングプロセスはコストがかかりますが、攻撃者は多数のデータパケットを送信するだけでトリガーできます。 SAVIデバイス自体に対するサービス拒否攻撃を回避するには、データスヌーピングプロセスをレート制限する必要があります。定数DATA_SNOOPING_INTERVALは、頻度を制御するために使用されます。 1つの添付ファイル上の2つのデータスヌーピングプロセスは、DATA_SNOOPING_INTERVALの最小間隔時間で区切られている必要があります。この値を変更する場合は、DoS攻撃を最小限に抑えるのに十分な大きさの値にする必要があります。
(2) The Data Snooping Process may set up incorrect bindings if the clients do not reply to the detection probes (Section 7.6.1). An attack will pass the duplicate detection if the client assigned the target address does not reply to the detection probes. The DHCP Leasequery procedure performed by the SAVI device just tells whether or not the address is assigned in the network. However, the SAVI device cannot determine whether the address is just assigned to the triggering attachment from the DHCPLEASEQUERY Reply.
（2）クライアントが検出プローブに応答しない場合、データスヌーピングプロセスは誤ったバインディングをセットアップすることがあります（セクション7.6.1）。ターゲットアドレスを割り当てられたクライアントが検出プローブに応答しない場合、攻撃は重複検出をパスします。 SAVIデバイスによって実行されるDHCP Leasequeryプロシージャは、アドレスがネットワークに割り当てられているかどうかを通知するだけです。ただし、SAVIデバイスは、アドレスがDHCPLEASEQUERY応答からトリガーしているアタッチメントに割り当てられているかどうかを判断できません。
In [RFC4388] and [RFC5007], the specific case of DHCP Leasequeries originated by "access concentrators" is addressed extensively. SAVI devices are very similar to access concentrators in that they snoop on DHCP traffic and seek to validate source addresses based on the results. Accordingly, the recommendations for securing leasequery operations for access concentrators in Section 7 of [RFC4388] and Section 5 of [RFC5007] MUST be followed when leasequeries are made from SAVI devices. [RFC5007] RECOMMENDS that communications between the querier and the DHCP server are protected with IPsec. It is pointed out that there are relatively few devices involved in a given administrative domain (SAVI devices, DHCP relays, and DHCP servers) so that manual configuration of keying material would not be overly burdensome.
[RFC4388]と[RFC5007]では、「アクセスコンセントレータ」から発信されたDHCPリースの特定のケースが広範囲にわたって扱われています。 SAVIデバイスは、DHCPトラフィックをスヌーピングし、その結果に基づいて送信元アドレスを検証しようとする点で、アクセスコンセントレータと非常に似ています。したがって、[RFC4388]のセクション7と[RFC5007]のセクション5にあるアクセスコンセントレータのリースクエリ操作を保護するための推奨事項は、SAVIデバイスからリースクエリを作成する場合に従う必要があります。 [RFC5007]クエリアとDHCPサーバー間の通信はIPsecで保護されることを推奨します。所定の管理ドメインに含まれるデバイス（SAVIデバイス、DHCPリレー、およびDHCPサーバー）が比較的少ないため、キー情報の手動構成が過度に負担にならないことが指摘されています。
After a binding is set up, the corresponding client may leave its attachment point. It may depart temporarily due to signal fade or permanently by moving to a new attachment point or leaving the network. In the signal fade case, since the client may return shortly, the binding should be kept momentarily, lest legitimate traffic from the client be blocked. However, if the client leaves permanently, keeping the binding can be a security issue. If the binding anchor is a property of the attachment point rather than the client, e.g., the switch port but not incorporating the MAC address, an attacker using the same binding anchor can send packets using IP addresses assigned to the client. Even if the binding anchor is a property of the client, retaining binding state for a departed client for a long time is a waste of resources.
バインディングが設定された後、対応するクライアントは接続点を離れることがあります。信号のフェードのために一時的に、または新しい接続ポイントに移動するか、ネットワークを離れることによって永続的に出発する可能性があります。シグナルフェードの場合、クライアントがまもなく戻る可能性があるため、クライアントからの正当なトラフィックがブロックされないように、バインディングは一時的に維持する必要があります。ただし、クライアントが永続的に離れた場合、バインディングを維持することはセキュリティ上の問題になる可能性があります。バインディングアンカーがクライアントではなく、アタッチメントポイントのプロパティである場合（スイッチポートなど、MACアドレスが組み込まれていない場合）、同じバインディングアンカーを使用する攻撃者は、クライアントに割り当てられたIPアドレスを使用してパケットを送信できます。バインディングアンカーがクライアントのプロパティであっても、離脱したクライアントのバインディング状態を長期間保持することは、リソースの浪費です。
Whenever a direct client departs from the network, a link-down event associated with the binding anchor will be triggered. SAVI-DHCP monitors such events and performs the following mechanism.
直接クライアントがネットワークから離れると、バインディングアンカーに関連付けられたリンクダウンイベントがトリガーされます。 SAVI-DHCPはこのようなイベントを監視し、次のメカニズムを実行します。
(1) Whenever a client with the Validating attribute leaves, a timer of duration OFFLINK_DELAY is set on the corresponding binding entries.
（1）Validating属性を持つクライアントが離れるときは常に、対応するバインディングエントリに期間OFFLINK_DELAYのタイマーが設定されます。
(2) If a DAD Neighbor Solicitation / Gratuitous ARP request is received that targets the address during OFFLINK_DELAY, the entry MAY be removed.
（2）OFFLINK_DELAY中にアドレスをターゲットとするDADネイバー請求/ Gratuitous ARPリクエストが受信された場合、エントリは削除される場合があります。
(3) If the client returns on-link during OFFLINK_DELAY, cancel the timer.
（3）OFFLINK_DELAY中にクライアントがオンリンクに戻った場合は、タイマーをキャンセルします。
In this way, the bindings of a departing client are kept for OFFLINK_DELAY. In cases of link flapping, the client will not be blocked. If the client leaves permanently, the bindings will be removed after OFFLINK_DELAY.
このようにして、離脱するクライアントのバインディングはOFFLINK_DELAYの間保持されます。リンクフラッピングの場合、クライアントはブロックされません。クライアントが完全に離れた場合、バインディングはOFFLINK_DELAYの後で削除されます。
SAVI-DHCP does not handle the departure of indirect clients because it will not be notified of such events. Switches supporting indirect attachment (e.g., through a separate non-SAVI switch) SHOULD use information specific to the client such as its MAC address as part of the binding anchor.
SAVI-DHCPは、そのようなイベントについて通知されないため、間接クライアントの離脱を処理しません。間接的な接続をサポートするスイッチ（別の非SAVIスイッチなど）は、バインディングアンカーの一部としてMACアドレスなどのクライアント固有の情報を使用する必要があります（SHOULD）。
DNA [RFC4436] [RFC6059] is designed to decrease the handover latency after reattachment to the same network. DNA mainly relies on performing a reachability test by sending unicast Neighbor Solicitation / Router Solicitation / ARP Request messages to determine whether a previously configured address is still valid.
DNA [RFC4436] [RFC6059]は、同じネットワークに再接続した後のハンドオーバーレイテンシを減らすように設計されています。 DNAは主に、ユニキャストの近隣要請/ルーター要請/ ARP要求メッセージを送信して到達可能性テストを実行し、以前に構成されたアドレスがまだ有効かどうかを判断します。
Although DNA provides optimization for clients, there is insufficient information for this mechanism to migrate the previous binding or establish a new binding. If a binding is set up only by snooping the reachability test message, the binding may be invalid. For example, an attacker can perform the reachability test with an address bound to another client. If a binding is migrated to the attacker, the attacker can successfully obtain the binding from the victim. Because this mechanism wouldn't set up a binding based on snooping the DNA procedure, it cannot achieve perfect compatibility with DNA. However, it only means the reconfiguration of the interface is slowed but not prevented. Details are discussed as follows.
DNAはクライアントに最適化を提供しますが、このメカニズムが以前のバインディングを移行したり、新しいバインディングを確立したりするには、情報が不十分です。到達可能性テストメッセージをスヌーピングするだけでバインディングが設定されている場合、バインディングが無効である可能性があります。たとえば、攻撃者は別のクライアントにバインドされたアドレスで到達可能性テストを実行できます。バインディングが攻撃者に移行された場合、攻撃者は被害者からバインディングを正常に取得できます。このメカニズムでは、DNAプロシージャのスヌーピングに基づくバインディングが設定されないため、DNAとの完全な互換性を実現できません。ただし、これはインターフェースの再構成が遅くなることを意味するだけで、防止はされません。詳細は以下のとおりです。
In Simple DNAv6 [RFC6059], the probe is sent with the source address set to a link-local address, and such messages will not be discarded by the policy specified in Section 8.2. If a client is reattached to a previous network, the detection will be completed, and the address will be regarded as valid by the client. However, the candidate address is not contained in the probe. Thus, the binding cannot be recovered through snooping the probe. As the client will perform DHCP exchange at the same time, the binding will be recovered from the DHCP Snooping Process. The DHCP Request messages will not be filtered out in this case because they have link-local source addresses. Before the DHCP procedure is completed, packets will be filtered out by the SAVI device. In other words, if this SAVI function is enabled, Simple DNAv6 will not help reduce the handover latency. If the Data-Snooping attribute is configured on the new attachment of the client, the data-triggered procedure may reduce latency.
Simple DNAv6 [RFC6059]では、プローブは送信元アドレスをリンクローカルアドレスに設定して送信され、そのようなメッセージはセクション8.2で指定されたポリシーによって破棄されません。クライアントが以前のネットワークに再接続された場合、検出は完了し、クライアントはアドレスを有効と見なします。ただし、候補アドレスはプローブに含まれていません。したがって、プローブをスヌーピングしてもバインディングを回復できません。クライアントは同時にDHCP交換を実行するため、バインディングはDHCPスヌーピングプロセスから回復されます。 DHCP要求メッセージは、リンクローカルの送信元アドレスを持っているため、この場合は除外されません。 DHCP手順が完了する前に、パケットはSAVIデバイスによってフィルタリングされます。つまり、このSAVI機能が有効になっている場合、Simple DNAv6はハンドオーバーレイテンシの削減に役立ちません。 Data-Snooping属性がクライアントの新しいアタッチメントで構成されている場合、データトリガープロシージャによりレイテンシが短縮される場合があります。
In DNAv4 [RFC4436], the ARP Probe will be discarded because an unbound address is used as the sender protocol address. As a result, the client will regard the address under detection as valid. However, the data traffic will be filtered. The DHCP Request message sent by the client will not be discarded because the source IP address field should be all zeros as required by [RFC2131]. Thus, if the address is still valid, the binding will be recovered from the DHCP Snooping Process.
DNAv4 [RFC4436]では、バインドされていないアドレスが送信側プロトコルアドレスとして使用されるため、ARPプローブは破棄されます。その結果、クライアントは検出中のアドレスを有効と見なします。ただし、データトラフィックはフィルタリングされます。 [RFC2131]で要求されているように、送信元IPアドレスフィールドはすべてゼロであるため、クライアントが送信したDHCP要求メッセージは破棄されません。したがって、アドレスがまだ有効である場合、バインディングはDHCPスヌーピングプロセスから回復されます。
A binding entry will consume certain high-speed memory resources. In general, a SAVI device can afford only a quite limited number of binding entries. In order to prevent an attacker from overloading the resources of the SAVI device, a binding entry limit is set on each attachment. The binding entry limit is the maximum number of bindings supported on each attachment with the Validating attribute. No new binding should be set up after the limit has been reached. If a DHCP Reply assigns more addresses than the remaining binding entry quota of each client, the message will be discarded and no binding will be set up.
バインディングエントリは、特定の高速メモリリソースを消費します。一般に、SAVIデバイスは非常に限られた数のバインディングエントリしか提供できません。攻撃者がSAVIデバイスのリソースに過負荷をかけないようにするために、各エントリにバインディングエントリ制限が設定されています。バインディングエントリ制限は、Validateing属性を持つ各添付ファイルでサポートされるバインディングの最大数です。制限に達した後は、新しいバインディングをセットアップしないでください。 DHCP応答が各クライアントの残りのバインディングエントリクォータよりも多くのアドレスを割り当てる場合、メッセージは破棄され、バインディングはセットアップされません。
A SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), except where there is an identified reason why that information is likely to be involved in the detection, prevention, or tracing of actual source-address spoofing. Information about hosts that never spoof (probably the majority of hosts) SHOULD NOT be logged.
SAVIデバイスは、バインディングアンカー情報をできるだけ早く（つまり、特定のアドレスの状態がNO_BINDに戻るとすぐに）削除する必要があります（ただし、その情報が検出、防止に関与する可能性がある特定の理由がある場合を除く） 、または実際の送信元アドレスのスプーフィングのトレース。なりすましを行わないホスト（おそらくホストの大部分）に関する情報はログに記録すべきではありません。
This specification does not preclude reassembly of fragmented DHCP messages, but it also does not require it. If DHCP fragmentation proves to be an issue, the issue will need to be specified and addressed. (This topic is beyond the scope of this document.)
この仕様は、断片化されたDHCPメッセージの再構成を排除するものではありませんが、それを必要としません。 DHCPフラグメンテーションが問題であることが判明した場合は、問題を特定して対処する必要があります。 （このトピックは、このドキュメントの範囲外です。）
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, DOI 10.17487/RFC4388, February 2006, <http://www.rfc-editor.org/info/rfc4388>.
[RFC4388] Woundy、R。、およびK. Kinnear、「Dynamic Host Configuration Protocol（DHCP）Leasequery」、RFC 4388、DOI 10.17487 / RFC4388、2006年2月、<http://www.rfc-editor.org/info/rfc4388 >。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, DOI 10.17487/RFC4436, March 2006, <http://www.rfc-editor.org/info/rfc4436>.
[RFC4436] Aboba、B.、Carlson、J。、およびS. Cheshire、「Detecting Network Attachment in IPv4（DNAv4）」、RFC 4436、DOI 10.17487 / RFC4436、2006年3月、<http：//www.rfc-editor .org / info / rfc4436>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5007] Brzozowski、J.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPv6 Leasequery」、RFC 5007、DOI 10.17487 / RFC5007、2007年9月、<http：//www.rfc-editor。 org / info / rfc5007>。
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, DOI 10.17487/RFC5227, July 2008, <http://www.rfc-editor.org/info/rfc5227>.
[RFC5227] Cheshire、S。、「IPv4 Address Conflict Detection」、RFC 5227、DOI 10.17487 / RFC5227、2008年7月、<http://www.rfc-editor.org/info/rfc5227>。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <http://www.rfc-editor.org/info/rfc6059>.
[RFC6059] Krishnan、S。およびG. Daley、「IPv6でネットワーク接続を検出するための簡単な手順」、RFC 6059、DOI 10.17487 / RFC6059、2010年11月、<http://www.rfc-editor.org/info/rfc6059 >。
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, <http://www.rfc-editor.org/info/rfc6620>.
[RFC6620] Nordmark、E.、Bagnulo、M。、およびE. Levy-Abegnoli、「FCFS SAVI：First-Come、First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses」、RFC 6620、DOI 10.17487 / RFC6620、 2012年5月、<http://www.rfc-editor.org/info/rfc6620>。
[DHCPv6-SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, draft-ietf-opsec-dhcpv6-shield-07, May 2015.
[DHCPv6-SHIELD] Gont、F.、Liu、W。、およびG. Van de Velde、「DHCPv6-Shield：Protecting Again to Rogue DHCPv6 Servers」、Work in Progress、draft-ietf-opsec-dhcpv6-shield-07、 2015年5月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<http：// www .rfc-editor.org / info / rfc2827>。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004, <http://www.rfc-editor.org/info/rfc3736>.
[RFC3736] Droms、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、DOI 10.17487 / RFC3736、2004年4月、<http://www.rfc-editor.org/info/rfc3736> 。
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <http://www.rfc-editor.org/info/rfc7039>.
[RFC7039] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F。、およびC. Vogt、編、「Source Address Validation Improvement（SAVI）Framework」、RFC 7039、DOI 10.17487 / RFC7039、 2013年10月、<http://www.rfc-editor.org/info/rfc7039>。
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <http://www.rfc-editor.org/info/rfc7341>.
[RFC7341] Sun、Q.、Cui、Y.、Siodelski、M.、Krishnan、S.、I。Farrer、「DHCPv4-over-DHCPv6（DHCP 4o6）Transport」、RFC 7341、DOI 10.17487 / RFC7341、8月2014、<http://www.rfc-editor.org/info/rfc7341>。
Acknowledgments
謝辞
Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms, and Alberto Garcia for careful review and evaluation comments on the mechanism and text.
Jean-Michel Combes、Christian Vogt、Joel M. Halpern、Eric Levy-Abegnoli、Marcelo Bagnulo Braun、Jari Arkko、Elwyn Davies、Barry Leiba、Ted Lemon、Leaf Yeh、Ralph Droms、Alberto Garciaの各氏、メカニズムとテキストに関する評価コメント。
Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil, and Tao Lin for their valuable contributions.
Mark Williams、Erik Nordmark、Mikael Abrahamsson、David Harrington、Pekka Savola、Xing Li、Lixia Zhang、Bingyang Liu、Duanqi Zhou、Robert Raszuk、Greg Daley、John Kaippallimalil、Tao Linの貴重な貢献に感謝します。
Authors' Addresses
著者のアドレス
Jun Bi Network Research Center, Tsinghua University Beijing 100084 China
清華大学北京ジュンビネットワーク研究センター100084中国
EMail: junbi@tsinghua.edu.cn
Jianping Wu Dept. of Computer Science, Tsinghua University Beijing 100084 China
J Ianping W uコンピュータサイエンス学部、ts inghuauniversity北京100084中国
EMail: jianping@cernet.edu.cn
Guang Yao Network Research Center, Tsinghua University Beijing 100084 China
GU Angy AOネットワークリサーチセンター、ts inghuauniversity北京100084中国
EMail: yaoguang@cernet.edu.cn
Fred Baker Cisco Systems Santa Barbara, CA 93117 United States
Fred Baker Cisco Systems Santa Barbara、CA 93117アメリカ合衆国
EMail: fred@cisco.com