[要約] RFC 6607は、DHCPv4およびDHCPv6のための仮想サブネット選択オプションに関する規格です。このRFCの目的は、ネットワーク管理者が仮想サブネットを効果的に選択し、IPアドレスの割り当てを最適化するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) K. Kinnear
Request for Comments: 6607 R. Johnson
Updates: 3046 M. Stapp
Category: Standards Track Cisco Systems
ISSN: 2070-1721 April 2012
Virtual Subnet Selection Options for DHCPv4 and DHCPv6
DHCPv4およびDHCPv6の仮想サブネット選択オプション
Abstract
概要
This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, a DHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options carried in the DHCPv4 Relay Agent Information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place.
このメモは、DHCPv4仮想サブネット選択（VSS）オプション、DHCPv6 VSSオプション、およびDHCPv4リレーエージェント情報オプションに含まれるDHCPv4 VSSおよびVSS-Controlサブオプションを定義します。これらは、適切なアドレスまたはプレフィックスの割り当てを行うためにVSSサーバーにDHCP情報を渡す必要がある状況で、DHCPクライアント、リレーエージェント、およびプロキシクライアントが使用するためのものです。
For the DHCPv4 option and Relay Agent Information sub-options, this memo documents and extends existing usage as per RFC 3942. This memo updates RFC 3046 regarding details relating to the copying of sub-options (see Section 8).
DHCPv4オプションおよびリレーエージェント情報サブオプションについては、このメモはRFC 3942に従って既存の使用法を文書化および拡張します。このメモは、サブオプションのコピーに関する詳細に関してRFC 3046を更新します（セクション8を参照）。
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/rfc6607.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6607で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Virtual Subnet Selection Options and Sub-Options: Definitions ...6
3.1. DHCPv4 Virtual Subnet Selection Option .....................6
3.2. DHCPv4 Virtual Subnet Selection Sub-Option .................6
3.3. DHCPv4 Virtual Subnet Selection Control Sub-Option .........7
3.4. DHCPv6 Virtual Subnet Selection Option .....................7
3.5. Virtual Subnet Selection Type and Information ..............8
4. Overview of Virtual Subnet Selection Usage ......................8
4.1. VPN Assignment by the DHCP Relay Agent .....................9
4.2. VPN Assignment by the DHCP Server .........................12
4.3. Required Support ..........................................14
4.4. Alternative VPN Assignment Approaches .....................14
5. Relay Agent Behavior ...........................................15
5.1. VPN Assignment by the DHCP Server .........................16
5.2. DHCP Leasequery ...........................................17
6. Client Behavior ................................................17
7. Server Behavior ................................................19
7.1. Returning the DHCPv4 or DHCPv6 Option .....................20
7.2. Returning the DHCPv4 Sub-Option ...........................20
7.3. Making Sense of Conflicting VSS Information ...............21
8. Update to RFC 3046 .............................................22
9. Security Considerations ........................................22
10. IANA Considerations ...........................................23
11. Acknowledgments ...............................................24
12. References ....................................................25
12.1. Normative References .....................................25
12.2. Informative References ...................................25
There is a growing use of Virtual Private Network (VPN) configurations. This growth comes from many areas: individual client systems needing to appear to be on the home corporate network even when traveling, ISPs providing extranet connectivity for customer companies, etc. In some of these cases, there is a need for the DHCP server to know the VPN (also called a "Virtual Subnet Selector" or "VSS" in this document) from which an address, and other resources, should be allocated.
仮想プライベートネットワーク（VPN）構成の使用が増加しています。この成長は多くの分野から生じています。個々のクライアントシステムは、旅行中でも自宅の企業ネットワーク上にあるように見える必要があり、ISPは顧客企業にエクストラネット接続を提供しています。これらのケースの一部では、DHCPサーバーが知る必要があります。 VPN（このドキュメントでは「仮想サブネットセレクタ」または「VSS」とも呼ばれます）。アドレスおよびその他のリソースを割り当てる必要があります。
This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, a DHCPv6 VSS option, and two VSS sub-options carried in the DHCPv4 Relay Agent Information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. If the receiving DHCP server understands the VSS option or sub-options, this information may be used in conjunction with other information in determining the subnet on which to select an address, as well as other information such as DNS server, default router, etc.
このメモは、DHCPv4仮想サブネット選択（VSS）オプション、DHCPv6 VSSオプション、およびDHCPv4リレーエージェント情報オプションに含まれる2つのVSSサブオプションを定義します。これらは、適切なアドレスまたはプレフィックスの割り当てを行うためにVSSサーバーにDHCP情報を渡す必要がある状況で、DHCPクライアント、リレーエージェント、およびプロキシクライアントが使用するためのものです。受信DHCPサーバーがVSSオプションまたはサブオプションを理解している場合、この情報は、アドレスを選択するサブネットを決定する際の他の情報、およびDNSサーバー、デフォルトルーターなどの他の情報と組み合わせて使用できます。
If the allocation is being done through a DHCPv4 relay, then the Relay Agent Information sub-options defined here should be included. In some cases, however, an IP address is being sought by a DHCPv4 proxy on behalf of a client (which may be assigned the address via a different protocol). In this case, there is a need to include VSS information relating to the client as a DHCPv4 option.
DHCPv4リレーを介して割り当てが行われている場合、ここで定義されたリレーエージェント情報サブオプションを含める必要があります。ただし、場合によっては、DHCPv4プロキシがクライアントに代わってIPアドレスを求めています（別のプロトコルを介してアドレスが割り当てられる場合があります）。この場合、DHCPv4オプションとしてクライアントに関連するVSS情報を含める必要があります。
If the allocation is being done through a DHCPv6 relay, then the DHCPv6 VSS option defined in this document should be included in the Relay-forward and Relay-reply messages going between the DHCPv6 relay and server. In some cases, addresses or prefixes are being sought by a DHCPv6 proxy on behalf of a client. In this case, there is a need for the client itself to supply the VSS information using the DHCPv6 VSS option in the messages that it sends to the DHCPv6 server.
DHCPv6リレーを介して割り当てが行われている場合、このドキュメントで定義されているDHCPv6 VSSオプションは、DHCPv6リレーとサーバーの間で送信されるリレー転送メッセージとリレー応答メッセージに含める必要があります。場合によっては、クライアントに代わってDHCPv6プロキシがアドレスまたはプレフィックスを検索します。この場合、クライアント自体がDHCPv6サーバーに送信するメッセージでDHCPv6 VSSオプションを使用してVSS情報を提供する必要があります。
In the remaining text of this document, when a DHCPv6 address is indicated, the same information applies to DHCPv6 prefix delegation [RFC3633] as well.
このドキュメントの残りのテキストでは、DHCPv6アドレスが示されている場合、同じ情報がDHCPv6プレフィックス委任[RFC3633]にも適用されます。
In the remaining text of this document, when the term "VSS sub-option" is used, it refers to the VSS sub-option carried in the DHCPv4 Relay Agent Information option.
このドキュメントの残りのテキストでは、「VSSサブオプション」という用語が使用されている場合、それはDHCPv4リレーエージェント情報オプションに含まれるVSSサブオプションを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用します。
o DHCP client
o DHCPクライアント
A DHCP client is a host using DHCP to obtain configuration parameters such as a network address.
DHCPクライアントは、DHCPを使用してネットワークアドレスなどの構成パラメータを取得するホストです。
o DHCP proxy
o DHCPプロキシ
A DHCP proxy is a DHCP client that acquires IP addresses not for its own use but rather on behalf of another entity. There are a variety of ways that a DHCP proxy can supply the addresses it acquires to other entities that need them.
DHCPプロキシは、自分自身ではなく、別のエンティティに代わってIPアドレスを取得するDHCPクライアントです。 DHCPプロキシが取得するアドレスを、それを必要とする他のエンティティに提供する方法はさまざまです。
o DHCP relay agent
o DHCPリレーエージェント
A DHCP relay agent is an agent that transfers BOOTP and DHCP messages between clients and servers residing on different subnets, per [RFC951], [RFC1542], and [RFC3315].
DHCPリレーエージェントは、[RFC951]、[RFC1542]、および[RFC3315]に従って、異なるサブネット上にあるクライアントとサーバー間でBOOTPおよびDHCPメッセージを転送するエージェントです。
o DHCP server
o DHCPサーバー
A DHCP server is a host that returns configuration parameters to DHCP clients.
DHCPサーバーは、構成パラメーターをDHCPクライアントに返すホストです。
o DHCPv4 option
o DHCPv4オプション
A DHCPv4 option is an option used to implement a capability defined by the DHCPv4 RFCs ([RFC2131] [RFC2132]). This option has one-octet code and size fields.
DHCPv4オプションは、DHCPv4 RFC（[RFC2131] [RFC2132]）で定義された機能を実装するために使用されるオプションです。このオプションには、1オクテットのコードとサイズのフィールドがあります。
o DHCPv4 sub-option
o DHCPv4サブオプション
As used in this document, a DHCPv4 sub-option refers to a sub-option of the Relay Agent Information option [RFC3046]. This sub-option has one-octet code and size fields.
このドキュメントで使用されているDHCPv4サブオプションは、リレーエージェント情報オプション[RFC3046]のサブオプションを指します。このサブオプションには、1オクテットのコードとサイズのフィールドがあります。
o DHCPv6 option
o DHCPv6オプション
A DHCPv6 option is an option used to implement a capability defined by the DHCPv6 RFC [RFC3315]. This option has two-octet code and size fields.
DHCPv6オプションは、DHCPv6 RFC [RFC3315]で定義された機能を実装するために使用されるオプションです。このオプションには、2オクテットのコードとサイズのフィールドがあります。
o Global VPN
o グローバルVPN
This term indicates that the address being described belongs to the set of addresses not part of any VPN -- in other words, the normal address space operated on by DHCP. This includes private addresses -- for example, the 10.x.x.x addresses as well as the other private subnets that are not routed on the open Internet.
この用語は、記述されているアドレスが、VPNの一部ではなくアドレスのセットに属していることを示します。つまり、DHCPで操作される通常のアドレス空間です。これにはプライベートアドレスが含まれます。たとえば、10.x.x.xアドレスや、オープンインターネット上でルーティングされない他のプライベートサブネットなどです。
o NVT ASCII identifier
o NVT ASCII識別子
A Network Virtual Terminal (NVT) identifier is an identifier containing only characters from the ASCII repertoire and using the Network Virtual Terminal encoding (see Appendix B of [RFC5198]).
ネットワーク仮想端末（NVT）識別子は、ASCIIレパートリーの文字のみを含み、ネットワーク仮想端末エンコーディングを使用する識別子です（[RFC5198]の付録Bを参照）。
o VSS information
o VSS情報
VSS information provides information about a VPN necessary to allocate an address to a DHCP client on that VPN and necessary to forward a DHCP reply packet to a DHCP client on that VPN.
VSS情報は、VPN上のDHCPクライアントにアドレスを割り当てるため、およびそのVPN上のDHCPクライアントにDHCP応答パケットを転送するために必要なVPNに関する情報を提供します。
o VPN
o VPN
This term refers to a virtual private network. A VPN appears to the client to be a private network.
この用語は、仮想プライベートネットワークを指します。 VPNはクライアントからはプライベートネットワークのように見えます。
o VPN identifier
o VPN識別
The VPN-ID is defined by [RFC2685] to be a sequence of 7 octets.
VPN-IDは、[RFC2685]によって7オクテットのシーケンスであると定義されています。
The VSS options and sub-options contain a generalized way to specify the VSS information about a VPN. There are two options and two sub-options defined in this section. The actual VSS information is identical for both options and for one of the two sub-options.
VSSオプションとサブオプションには、VPNに関するVSS情報を指定する一般的な方法が含まれています。このセクションでは、2つのオプションと2つのサブオプションが定義されています。実際のVSS情報は、両方のオプションと2つのサブオプションのうちの1つと同じです。
The format of the option is shown below.
オプションのフォーマットを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Type | VSS Info. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code The option code (221).
コードオプションコード（221）。
Length The option length, minimum 1 octet.
長さオプションの長さ、最小1オクテット。
Type and VSS Information -- see Section 3.5.
タイプとVSS情報-セクション3.5を参照。
This is a sub-option of the Relay Agent Information option [RFC3046]. The format of the sub-option is shown below.
これは、リレーエージェント情報オプション[RFC3046]のサブオプションです。サブオプションのフォーマットを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Type | VSS Info. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code The sub-option code (151).
コードサブオプションコード（151）。
Length The sub-option length, minimum 1 octet.
長さサブオプションの長さ、最小1オクテット。
Type and VSS Information -- see Section 3.5.
タイプとVSS情報-セクション3.5を参照。
This is a sub-option of the Relay Agent Information option [RFC3046]. The format of the sub-option is shown below.
これは、リレーエージェント情報オプション[RFC3046]のサブオプションです。サブオプションのフォーマットを以下に示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code The sub-option code (152).
コードサブオプションコード（152）。
Length The sub-option length, 0.
長さサブオプションの長さ、0。
This sub-option only appears in the DHCPv4 Relay Agent Information option. In a DHCP request, it indicates that a DHCPv4 VSS sub-option is also present in the Relay Agent Information option. In a DHCP reply, if it appears in the Relay Agent Information option, it indicates that the DHCP server did not understand any DHCPv4 VSS sub-option that also appears in the Relay Agent Information option.
このサブオプションは、DHCPv4リレーエージェント情報オプションにのみ表示されます。 DHCP要求では、DHCPv4 VSSサブオプションがリレーエージェント情報オプションにも存在することを示しています。 DHCP応答で、リレーエージェント情報オプションに表示される場合、それはDHCPサーバーがリレーエージェント情報オプションにも表示されるDHCPv4 VSSサブオプションを認識しなかったことを示します。
The format of the DHCPv6 VSS option is shown below. This option may be included by a client or relay agent (or both).
DHCPv6 VSSオプションのフォーマットを以下に示します。このオプションは、クライアントまたはリレーエージェント（あるいはその両方）に含めることができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VSS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | VSS Information ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VSS (68).
オプションコードOPTION_VSS（68）。
option-len The number of octets in the option, minimum 1.
option-lenオプションのオクテット数、最小1。
Type and VSS Information -- see Section 3.5.
タイプとVSS情報-セクション3.5を参照。
All of the (sub-)options defined above that carry VSS information use identical payloads consisting of a Type value and additional VSS information, as follows:
上記で定義された、VSS情報を伝送するすべての（サブ）オプションは、次のように、Type値と追加のVSS情報で構成される同一のペイロードを使用します。
Type VSS Information Format
------------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
2-254 Unassigned
255 Global, default VPN
o Type 0 -- Network Virtual Terminal (NVT) ASCII VPN identifier
o タイプ0-ネットワーク仮想端末（NVT）ASCII VPN ID
Indicates that the VSS information consists of an NVT ASCII string. It MUST NOT be terminated with a zero byte.
VSS情報がNVT ASCII文字列で構成されることを示します。ゼロバイトで終了してはなりません。
o Type 1 -- RFC 2685 VPN-ID
o タイプ1-RFC 2685 VPN-ID
Indicates that the VSS information consists of an RFC 2685 VPN-ID [RFC2685], which is defined to be 7 octets in length.
VSS情報がRFC 2685 VPN-ID [RFC2685]で構成され、長さが7オクテットであると定義されていることを示します。
o Type 255 -- Global, default VPN
o タイプ255-グローバル、デフォルトVPN
Indicates that there is no explicit, non-default VSS information but rather that this option references the normal, global, default address space. In this case, there MUST NOT be any VSS information included in the VSS option or sub-option, and the length of the option or sub-option MUST be 1.
明示的なデフォルト以外のVSS情報はなく、このオプションは通常のグローバルなデフォルトアドレス空間を参照することを示します。この場合、VSSオプションまたはサブオプションに含まれるVSS情報があってはならず、オプションまたはサブオプションの長さは1でなければなりません。
All other values of the Type field are unassigned.
「タイプ」フィールドの他のすべての値は割り当てられていません。
At the highest level, the VSS option or sub-option determines the VPN on which a DHCP client is supposed to receive an IP address. How the option or sub-option is entered and processed is discussed below, but the point of all of the discussion is to determine the VPN on which the DHCP client resides. This will affect a relay agent, in that it will have to ensure that DHCP packets sent to and received from the DHCP client flow over the correct VPN. This will affect the DHCP server in that it determines the IP address space used for the IP address allocation.
最高レベルでは、VSSオプションまたはサブオプションが、DHCPクライアントがIPアドレスを受信するはずのVPNを決定します。オプションまたはサブオプションの入力方法と処理方法を以下に説明しますが、すべての説明のポイントは、DHCPクライアントが常駐するVPNを決定することです。これはリレーエージェントに影響し、DHCPクライアントとの間で送受信されるDHCPパケットが正しいVPNを介して確実に流れるようにする必要があります。これは、IPアドレスの割り当てに使用されるIPアドレス空間を決定するという点でDHCPサーバーに影響します。
A DHCP server has as part of its configuration some IP address space from which it allocates IP addresses to DHCP clients. These allocations are typically for a limited time, and thus the DHCP client gets a lease on the IP address. In the absence of any VPN information, the IP address space is in the global or default VPN used throughout the Internet. When a DHCP server deals with VPN information, each VPN defines a new address space inside the server, one distinct from the global or default IP address space. A server that supports the VSS option or sub-option thereby supports allocation of IP addresses from multiple different VPNs. Supporting IP address allocation from multiple different VPNs means that the DHCP server must be prepared to configure multiple different address spaces (one per distinct VPN) and allocate IP addresses from these different address spaces.
DHCPサーバーは、構成の一部として、DHCPクライアントにIPアドレスを割り当てるためのIPアドレス空間をいくつか持っています。これらの割り当ては通常、限られた時間のためであり、DHCPクライアントはIPアドレスのリースを取得します。 VPN情報がない場合、IPアドレス空間はインターネット全体で使用されるグローバルまたはデフォルトのVPNにあります。 DHCPサーバーがVPN情報を処理する場合、各VPNはサーバー内に新しいアドレススペースを定義します。これは、グローバルまたはデフォルトのIPアドレススペースとは異なります。これにより、VSSオプションまたはサブオプションをサポートするサーバーは、複数の異なるVPNからのIPアドレスの割り当てをサポートします。複数の異なるVPNからのIPアドレスの割り当てをサポートするには、DHCPサーバーが複数の異なるアドレススペース（個別のVPNごとに1つ）を構成し、これらの異なるアドレススペースからIPアドレスを割り当てるように準備する必要があります。
These address spaces are typically independent, so that the same IP address (consisting of the same string of bytes) could be allocated to one client in the global, default VPN, and to a different client residing in a different VPN. There is no conflict in this allocation, since the clients have essentially different addresses, even though these addresses consist of the same string of bytes, because the IPv4 or IPv6 address is qualified by the VPN.
これらのアドレススペースは通常独立しているため、同じIPアドレス（同じバイト文字列で構成される）をグローバルなデフォルトVPN内の1つのクライアントと、別のVPN内にある別のクライアントに割り当てることができます。 IPv4またはIPv6アドレスはVPNによって修飾されているため、これらのアドレスは同じバイト文字列で構成されていますが、クライアントは本質的に異なるアドレスを持っているため、この割り当てには競合はありません。
Thus, a VSS option or sub-option is a way of signaling the use of a VPN other than the global or default VPN. This brings up the question of who decides what VPN a DHCP client should be using.
したがって、VSSオプションまたはサブオプションは、グローバルVPNまたはデフォルトVPN以外のVPNの使用を通知する方法です。これにより、DHCPクライアントが使用するVPNを誰が決定するかという問題が生じます。
There are three entities that can insert either a VSS option or sub-option into a DHCPv4 packet or DHCPv6 message: a DHCP client, a relay agent, or a DHCPv4 or DHCPv6 server. While all of these entities could include a different VSS option or sub-option in every request or response, this situation is neither typical nor useful. There are two known paradigms for use of the VSS option or sub-option; these are discussed below.
DHCPオプション、サブオプションのいずれかをDHCPv4パケットまたはDHCPv6メッセージに挿入できるエンティティは、DHCPクライアント、リレーエージェント、またはDHCPv4またはDHCPv6サーバーの3つです。これらのエンティティはすべて、すべての要求または応答に異なるVSSオプションまたはサブオプションを含めることができますが、この状況は一般的でも有用でもありません。 VSSオプションまたはサブオプションを使用するための2つの既知のパラダイムがあります。これらについては以下で説明します。
The typical use of the VSS option or sub-option is for the relay agent to know the VPN on which the DHCP client is operating. The DHCP client itself does not, in this approach, know the VPN on which it resides. The relay agent is responsible for mediating the access between the VPN on which the DHCP client resides and the DHCP server. In this situation, the relay agent will insert two DHCPv4 Relay Agent Information sub-options (one VSS sub-option, and one VSS-Control sub-option) into the Relay Agent Information option, or a DHCPv6 VSS option into the Relay-forward message of every request it forwards from the DHCP client. The server will use the DHCPv6 VSS option or DHCPv4 VSS sub-option to determine the VPN on which the client resides and will use that VPN information to select the address space within its configuration from which to allocate an IP address to the DHCP client.
VSSオプションまたはサブオプションの一般的な用途は、リレーエージェントがDHCPクライアントが動作しているVPNを認識することです。このアプローチでは、DHCPクライアント自体は、それが存在するVPNを認識しません。リレーエージェントは、DHCPクライアントが存在するVPNとDHCPサーバー間のアクセスを仲介する役割を果たします。この状況では、リレーエージェントは、2つのDHCPv4リレーエージェント情報サブオプション（1つのVSSサブオプションと1つのVSS-Controlサブオプション）をリレーエージェント情報オプションに挿入するか、DHCPv6 VSSオプションをリレーフォワードに挿入しますDHCPクライアントから転送するすべての要求のメッセージ。サーバーはDHCPv6 VSSオプションまたはDHCPv4 VSSサブオプションを使用して、クライアントが存在するVPNを決定し、そのVPN情報を使用して、DHCPクライアントにIPアドレスを割り当てる構成内のアドレススペースを選択します。
When, using this approach, a DHCPv4 relay agent inserts a VSS sub-option into the Relay Agent Information option, it MUST also insert a VSS-Control sub-option into the Relay Agent Information option. This is to allow the determination of whether or not the DHCPv4 server actually processes the VSS information provided by the DHCPv4 relay agent. If the DHCPv4 server supports the VSS capabilities described in this document, it will remove the VSS-Control sub-option from the Relay Agent Information option that it returns to the DHCPv4 relay agent. See Section 5 for more information.
このアプローチを使用して、DHCPv4リレーエージェントがVSSサブオプションをリレーエージェント情報オプションに挿入する場合、VSS-Controlサブオプションもリレーエージェント情報オプションに挿入する必要があります。これにより、DHCPv4サーバーがDHCPv4リレーエージェントによって提供されるVSS情報を実際に処理するかどうかを決定できます。 DHCPv4サーバーがこのドキュメントで説明されているVSS機能をサポートしている場合は、DHCPv4リレーエージェントに返すリレーエージェント情報オプションからVSS-Controlサブオプションが削除されます。詳細については、セクション5を参照してください。
In this approach, the relay agent might also send a VSS option or sub-option in either a DHCPv4 or DHCPv6 Leasequery request [RFC4388] [RFC5007], but in this case, it would use the VSS option in the Leasequery request to select the correct address space for the Leasequery. In this approach, the relay agent would be acting as a DHCP client from a leasequery standpoint, but it would not be as if a DHCP client were sending in a VSS option in a standard DHCP address allocation request, say a DHCPDISCOVER.
このアプローチでは、リレーエージェントは、DHCPv4またはDHCPv6 Leasequeryリクエストで[VSS]オプションまたはサブオプションを送信することもありますが、この場合、LeasequeryリクエストでVSSオプションを使用して、 Leasequeryの正しいアドレス空間。このアプローチでは、リレーエージェントはリースクエリの観点からはDHCPクライアントとして機能しますが、DHCPクライアントが標準のDHCPアドレス割り当て要求のVSSオプションで送信しているようなものではありません（DHCPDISCOVERなど）。
In this approach, only one relay agent would mediate the VPN access for the DHCP client to the DHCP server, and it would be the relay agent that inserts the VSS information into the request packet and that would remove it prior to forwarding the response packet.
このアプローチでは、1つのリレーエージェントのみがDHCPクライアントからDHCPサーバーへのVPNアクセスを仲介し、VSS情報を要求パケットに挿入し、応答パケットを転送する前にそれを削除するのはリレーエージェントです。
The diagram below shows an example of a DHCPv4 client, DHCPv4 relay agent, and DHCPv4 server. The DHCPv6 situation is similar but uses the DHCPv6 VSS option.
次の図は、DHCPv4クライアント、DHCPv4リレーエージェント、およびDHCPv4サーバーの例を示しています。 DHCPv6の状況も同様ですが、DHCPv6 VSSオプションを使用します。
DHCPv4 DHCPv4 Relay DHCPv4 Client Agent Server
DHCPv4 DHCPv4リレーDHCPv4クライアントエージェントサーバー
| | |
| >--DHCPDISCOVER--> | |
| on VPN "abc" | |
| | >--DHCPDISCOVER----> |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | VSS-Control |
| | |
| | <----DHCPOFFER-----< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPOFFER----< | |
| on VPN "abc" | |
| | |
| >--DHCPREQUEST---> | |
| on VPN "abc" | |
| | >--DHCPREQUEST-----> |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | VSS-Control |
| | |
| | <----DHCPACK-------< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPACK------< | |
| on VPN "abc" | |
| | |
... ... ...
Figure 4.1-1: DHCPv4 - Relay Agent Knows VPN
図4.1-1：DHCPv4-VPNを知っているリレーエージェント
The DHCP server would know that it should respond to VPN information specified in a VSS option or sub-option, and it would be configured with appropriate VPN address spaces to service the projected client requirements. Thus, in this common approach, the DHCP client knows nothing of any VPN access, the relay agent has been configured in some way that allows it to determine the VPN of the DHCP client and transmit that using a VSS option or sub-option to the DHCP server, and the DHCP server responds to the VPN specified by the relay agent. There is no conflict between different entities trying to specify different VSS information -- each entity knows its role through policy or configuration external to this document.
DHCPサーバーは、VSSオプションまたはサブオプションで指定されたVPN情報に応答する必要があることを認識し、適切なVPNアドレススペースで構成され、予測されたクライアント要件に対応します。したがって、この一般的なアプローチでは、DHCPクライアントはVPNアクセスについて何も認識していません。リレーエージェントは、DHCPクライアントのVPNを決定し、VSSオプションまたはサブオプションを使用してそれを送信できるように構成されています。 DHCPサーバー、およびDHCPサーバーは、リレーエージェントによって指定されたVPNに応答します。異なるVSS情報を指定しようとする異なるエンティティ間で競合はありません。各エンティティは、このドキュメントの外部にあるポリシーまたは設定を通じてその役割を認識しています。
If any misconfiguration exists, it SHOULD result in a DHCP client being unable to acquire an IP address. For instance, a relay agent that supports VPN access SHOULD couple transmission of VSS options or sub-options to the configuration of VPN support and not allow one without the other.
誤った設定が存在する場合、DHCPクライアントはIPアドレスを取得できなくなります（SHOULD）。たとえば、VPNアクセスをサポートするリレーエージェントは、VSSオプションまたはサブオプションの送信をVPNサポートの構成に結合し、もう一方なしでは許可しないようにする必要があります（SHOULD）。
It is important to ensure that the relay agent and DHCP server both support the VSS option and sub-options (for DHCPv4) or the VSS option (for DHCPv6). Deploying DHCPv4 relay agents that support and emit VSS sub-options in concert with DHCPv4 servers that do not support the VSS option or sub-option as defined in this document SHOULD NOT be done, as such an ensemble will not operate correctly. Should this situation occur, however, the relay agent can detect the problem (since the VSS-Control sub-option will appear in the packets it receives from the DHCPv4 server, indicating the server did not effectively process the VSS sub-option), and it can issue appropriate diagnostic messages.
リレーエージェントとDHCPサーバーの両方がVSSオプションとサブオプション（DHCPv4の場合）またはVSSオプション（DHCPv6の場合）をサポートしていることを確認することが重要です。このようなアンサンブルが正しく動作しないため、このドキュメントで定義されているVSSオプションまたはサブオプションをサポートしていないDHCPv4サーバーと連携して、VSSサブオプションをサポートおよび発行するDHCPv4リレーエージェントの展開は行わないでください。ただし、この状況が発生した場合、リレーエージェントは問題を検出できます（DHCPv4サーバーから受信したパケットにVSS-Controlサブオプションが表示され、サーバーがVSSサブオプションを効果的に処理しなかったことを示すため）。適切な診断メッセージを発行できます。
In this approach, the DHCP server would be configured in some way to know the VPN on which a particular DHCP client should be given access. The DHCP server would in this case include the VSS sub-option in the Relay Agent Information option for DHCPv4 or the VSS option in the Relay-reply message for DHCPv6. The relay agent responsible for mediating VPN access would use this information to select the correct VPN for the DHCP client. In the unusual event that there were more than one relay agent involved in this transaction, some external configuration or policy would be needed to inform the DHCPv6 server into which Relay-reply message the VSS option should go.
このアプローチでは、DHCPサーバーは、特定のDHCPクライアントにアクセスを許可する必要があるVPNを認識するように何らかの方法で構成されます。この場合、DHCPサーバーは、DHCPv4のリレーエージェント情報オプションにVSSサブオプションを含めるか、DHCPv6のリレー応答メッセージにVSSオプションを含めます。 VPNアクセスの仲介を担当するリレーエージェントは、この情報を使用して、DHCPクライアントに適切なVPNを選択します。このトランザクションに複数のリレーエージェントが関与するという異常なイベントでは、VSSオプションがどのリレー応答メッセージを送信するかをDHCPv6サーバーに通知するために、いくつかの外部構成またはポリシーが必要になります。
Once the relay agent has placed the DHCP client into the proper VPN, it SHOULD begin including VSS information in requests that it forwards to the DHCP server. Since this information does not conflict with the DHCP server's idea of the proper VPN for the client, everything works correctly.
リレーエージェントがDHCPクライアントを適切なVPNに配置すると、DHCPサーバーに転送する要求にVSS情報を含める必要があります（SHOULD）。この情報は、クライアントに適切なVPNを設定するというDHCPサーバーの考えと矛盾しないため、すべてが正しく機能します。
The diagram below shows this approach using DHCPv4. The DHCPv6 situation is similar but uses the DHCPv6 VSS option instead.
次の図は、DHCPv4を使用したこのアプローチを示しています。 DHCPv6の状況も同様ですが、代わりにDHCPv6 VSSオプションを使用します。
DHCPv4 DHCPv4 Relay DHCPv4 Client Agent Server
DHCPv4 DHCPv4リレーDHCPv4クライアントエージェントサーバー
| | |
| >--DHCPDISCOVER--> | |
| on unknown VPN | |
| | >--DHCPDISCOVER----> |
| | |
| | <----DHCPOFFER-----< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPOFFER----< | |
| on VPN "abc" | |
| | |
| >--DHCPREQUEST---> | |
| on VPN "abc" | |
| | >--DHCPREQUEST-----> |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | VSS-Control |
| | |
| | <----DHCPACK-------< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPACK------< | |
| on VPN "abc" | |
| | |
| | |
... ... ...
Figure 4.2-1: DHCPv4 - DHCPv4 Server Knows VPN
図4.2-1：DHCPv4-DHCPv4サーバーはVPNを認識する
In this approach, the DHCP client is again unaware of any VPN activity. In this case, however, the DHCP server knows the VPN for the client, and the relay agent responds to the VSS information specified by the DHCP server. Similar to the previous approach, each entity knows its role through a means external to this document, and no two entities try to specify VSS information in conflict.
このアプローチでは、DHCPクライアントは再びVPNアクティビティを認識しません。ただし、この場合、DHCPサーバーはクライアントのVPNを認識しており、リレーエージェントはDHCPサーバーによって指定されたVSS情報に応答します。前のアプローチと同様に、各エンティティはこのドキュメントの外部の手段を通じてその役割を認識しており、2つのエンティティが競合するVSS情報を指定しようとすることはありません。
It is important that both the relay agent and the DHCP server support the VSS option and sub-options (for DHCPv4) and the VSS option (for DHCPv6). Deploying and configuring VPN support in one element and not in the other is not a practical approach.
リレーエージェントとDHCPサーバーの両方が、VSSオプションとサブオプション（DHCPv4の場合）およびVSSオプション（DHCPv6の場合）をサポートすることが重要です。 1つの要素でVPNサポートを展開して構成することは、実際的なアプローチではありません。
DHCP relay agents and servers MUST support the approach discussed in Section 4.1. DHCP relay agents and servers SHOULD support the approach discussed in Section 4.2. DHCP relay agents and servers SHOULD NOT be configured to operate with both approaches simultaneously.
DHCPリレーエージェントとサーバーは、セクション4.1で説明されているアプローチをサポートする必要があります。 DHCPリレーエージェントとDHCPサーバーは、セクション4.2で説明したアプローチをサポートする必要があります（SHOULD）。 DHCPリレーエージェントとDHCPサーバーは、両方のアプローチで同時に動作するように構成しないでください。
There are many other approaches that can be created with multiple relay agents each inserting VSS information into different Relay-forward messages, relay agent VSS information conflicting with client VSS information, or DHCP server VSS information conflicting with relay agent and client VSS information. Since these approaches do not describe situations that are useful today, specifying precisely how to resolve all of these conflicts is not likely to be valuable in the event that these approaches actually become practical in the future.
さまざまなリレーエージェントがVSS情報をさまざまなリレー転送メッセージに挿入する、リレーエージェントのVSS情報がクライアントのVSS情報と競合する、またはDHCPサーバーのVSS情報がリレーエージェントとクライアントのVSS情報と競合する、他の多くのアプローチを作成できます。これらのアプローチは今日の有用な状況を説明していないため、これらのアプローチのすべてが実際に将来実用的になる場合、これらのすべての競合を解決する方法を正確に指定することは価値がない可能性があります。
The current use of the VSS option and sub-option requires that each entity know the part that it plays in dealing with VPN data. Each entity -- client, relay agent or agents, and server -- SHOULD know through some policy or configuration beyond the scope of this document whether it is responsible for specifying VPN information using the VSS option or sub-option or responsible for responding to VSS information specified by another entity, or whether it should simply ignore any VSS information that it might see.
現在、VSSオプションとサブオプションを使用するには、各エンティティがVPNデータの処理で果たす役割を知っている必要があります。各エンティティ-クライアント、リレーエージェント、サーバー-このドキュメントの範囲を超えたポリシーまたは構成を通じて、VSSオプションまたはサブオプションを使用してVPN情報を指定する責任があるか、VSSに応答する責任があるかを確認する必要があります。別のエンティティによって指定された情報、または表示される可能性のあるVSS情報を単に無視するかどうか。
Some simple conflict-resolution approaches are discussed below, in the hopes that they will cover simple cases that may arise from situations beyond those envisioned today. However, for more complex situations, or simple situations where appropriate conflict-resolution strategies differ from those discussed in this document, a document detailing the usage situations and appropriate conflict-resolution strategies SHOULD be created and submitted for discussion and approval.
いくつかの単純な紛争解決アプローチについて以下で説明します。今日想定されている状況を超えた状況から発生する可能性のある単純なケースがカバーされることを期待しています。ただし、より複雑な状況、または適切な競合解決戦略がこのドキュメントで説明されているものと異なる単純な状況の場合、使用状況と適切な競合解決戦略を詳述したドキュメントを作成し、ディスカッションと承認のために提出する必要があります。
Implementers MAY provide a policy or configuration capability to enable or disable VSS support.
実装者は、VSSサポートを有効または無効にするポリシーまたは構成機能を提供する場合があります。
A relay agent that receives a DHCP request from a DHCP client on a VPN SHOULD include VSS information in the DHCP packet prior to forwarding the packet to the DHCP server unless inhibited from doing so by configuration information or policy to the contrary.
VPN上のDHCPクライアントからDHCP要求を受信するリレーエージェントは、反対の構成情報またはポリシーによって禁止されていない限り、DHCPサーバーにパケットを転送する前に、DHCPパケットにVSS情報を含める必要があります（SHOULD）。
In this situation, a DHCPv4 relay agent MUST include a DHCPv4 VSS sub-option in a Relay Agent Information option [RFC3046], while a DHCPv6 relay agent MUST include a DHCPv6 VSS option in the Relay-forward message.
この状況では、DHCPv4リレーエージェントは、リレーエージェント情報オプション[RFC3046]にDHCPv4 VSSサブオプションを含める必要がありますが、DHCPv6リレーエージェントは、リレー転送メッセージにDHCPv6 VSSオプションを含める必要があります。
The value placed in the VSS sub-option or option would typically be sufficient for the relay agent to properly route any DHCP reply packet returned from the DHCP server to the DHCP client for which it is destined. In some cases, the information in the VSS sub-option or option might be an index to some internal table held in the relay agent, though this document places no requirement on a relay agent to have any such internal state.
VSSサブオプションまたはオプションに指定された値は、通常、リレーエージェントがDHCPサーバーから返されたDHCP応答パケットを宛先のDHCPクライアントに適切にルーティングするのに十分です。場合によっては、VSSサブオプションまたはオプションの情報は、リレーエージェントに保持されている内部テーブルへのインデックスである可能性がありますが、このドキュメントでは、リレーエージェントにそのような内部状態を要求していません。
A DHCPv4 relay agent MUST, in addition, include a DHCPv4 VSS-Control sub-option (which has a length of zero) in the Relay Agent Information option [RFC3046] whenever it includes a VSS sub-option in the Relay Agent Information option. The inclusion of the VSS sub-option and the VSS-Control sub-option in the Relay Agent Information option will allow the DHCPv4 relay agent to determine whether the DHCPv4 server actually processed the information in the VSS sub-option when it receives the Relay Agent Information option in the reply from the DHCPv4 server.
さらに、DHCPv4リレーエージェントは、リレーエージェント情報オプションにVSSサブオプションが含まれている場合は常に、リレーエージェント情報オプション[RFC3046]にDHCPv4 VSS-Controlサブオプション（長さがゼロ）を含める必要があります。リレーエージェント情報オプションにVSSサブオプションとVSS-Controlサブオプションを含めると、DHCPv4リレーエージェントは、リレーエージェントを受信したときにDHCPv4サーバーが実際にVSSサブオプションの情報を処理したかどうかを判断できます。 DHCPv4サーバーからの応答の情報オプション。
The reason to include this additional VSS DHCPv4 sub-option is that [RFC3046] specifies (essentially) that a DHCPv4 server should copy all sub-options that it receives in a Relay Agent Information option in a request into a corresponding Relay Agent Information option in the response. Thus, a server that didn't support the DHCPv4 VSS sub-option would normally just copy it to the response packet, leaving the relay agent to wonder if in fact the DHCPv4 server actually used the VSS information when processing the request.
この追加のVSS DHCPv4サブオプションを含める理由は、[RFC3046]が（本質的に）DHCPv4サーバーがリクエストのリレーエージェント情報オプションで受信するすべてのサブオプションを、対応するリレーエージェント情報オプションにコピーすることを指定するためです応答。したがって、DHCPv4 VSSサブオプションをサポートしていないサーバーは通常、それを応答パケットにコピーするだけで、リレーエージェントは、実際にDHCPv4サーバーが実際に要求を処理するときにVSS情報を使用したのかどうか疑問に思います。
To alleviate this potential confusion, a DHCPv4 relay agent instead sends in two sub-options: one VSS sub-option, and one VSS-Control sub-option. If both sub-options appear in the response from the DHCPv4 server, then the DHCPv4 relay agent MUST assume that the DHCPv4 server did not act on the VSS information in the VSS sub-option. If only the VSS sub-option appears in the response from the DHCPv4 server and no VSS-Control sub-option appears in the response from the DHCPv4 server, then the relay agent SHOULD assume that the DHCPv4 server acted successfully on the VSS sub-option.
この潜在的な混乱を緩和するために、DHCPv4リレーエージェントは、代わりに2つのサブオプション（1つのVSSサブオプションと1つのVSS-Controlサブオプション）で送信します。 DHCPv4サーバーからの応答に両方のサブオプションが表示される場合、DHCPv4リレーエージェントは、DHCPv4サーバーがVSSサブオプションのVSS情報に基づいて動作しなかったと想定する必要があります。 DHCPv4サーバーからの応答にVSSサブオプションのみが表示され、DHCPv4サーバーからの応答にVSS-Controlサブオプションが表示されない場合、リレーエージェントは、DHCPv4サーバーがVSSサブオプションで正常に動作したと想定する必要があります（SHOULD） 。
Any time a relay agent places a VSS option or sub-option in a DHCP request, it SHOULD send it only to a DHCP server that supports the VSS option or sub-option, and it MUST check the response to determine if the DHCP server actually honored the requested VSS information.
リレーエージェントは、VSSオプションまたはサブオプションをDHCPリクエストに配置するときは常に、VSSオプションまたはサブオプションをサポートするDHCPサーバーにのみ送信する必要があり（SHOULD）、DHCPサーバーが実際にDHCPサーバーであるかどうかを判断するために応答をチェックする必要があります。要求されたVSS情報を尊重しました。
In the DHCPv6 case, the appearance of the option in the Relay-reply packet indicates that the DHCPv6 server understood and acted upon the contents of the VSS option in the Relay-forward packet. In the DHCPv4 case, as discussed above, the appearance of the VSS sub-option without the appearance of a VSS-Control sub-option indicates that the DHCPv4 server successfully acted upon the VSS sub-option.
DHCPv6の場合、リレー応答パケットにオプションが表示されることは、DHCPv6サーバーがリレー転送パケットのVSSオプションの内容を理解して操作したことを示しています。前述のように、DHCPv4の場合、VSS-Controlサブオプションが表示されずにVSSサブオプションが表示されることは、DHCPv4サーバーがVSSサブオプションに正常に作用したことを示します。
This document does not create a requirement that a relay agent remember the contents of a VSS DHCPv4 sub-option or VSS DHCPv6 option sent to a DHCP server. In many cases, the relay agent may simply use the value of the VSS option or sub-option returned by the DHCP server to forward the response to the DHCP client. If the VSS information, the IP address allocated, and the VPN capabilities of the relay agent all interoperate correctly, then the DHCP client will receive a working IP address. Alternatively, if any of these items don't interoperate with the others, the DHCP client will not receive a working address.
このドキュメントでは、リレーエージェントが、DHCPサーバーに送信されたVSS DHCPv4サブオプションまたはVSS DHCPv6オプションの内容を記憶するという要件を作成していません。多くの場合、リレーエージェントは、DHCPサーバーから返されたVSSオプションまたはサブオプションの値を使用して、応答をDHCPクライアントに転送します。 VSS情報、割り当てられたIPアドレス、およびリレーエージェントのVPN機能がすべて正しく相互運用されている場合、DHCPクライアントは動作するIPアドレスを受け取ります。または、これらの項目のいずれかが他の項目と相互運用できない場合、DHCPクライアントは有効なアドレスを受け取りません。
Note that in some environments a relay agent may choose to always place a VSS option or sub-option into packets and messages that it forwards in order to forestall any attempt by a relay agent closer to the client or the client itself to specify VSS information. In this case, a Type field of 255 is used to denote the global, default VPN. When the Type field of 255 is used, there MUST NOT be any additional VSS information in the VSS option or sub-option. In the DHCPv4 case, an additional VSS-Control sub-option would be required, as discussed above.
一部の環境では、リレーエージェントは、VSS情報を指定するクライアントまたはクライアント自体に近いリレーエージェントによる試行を未然に防ぐために、転送するパケットおよびメッセージに常にVSSオプションまたはサブオプションを配置することを選択する場合があることに注意してください。この場合、タイプフィールド255は、グローバルなデフォルトVPNを示すために使用されます。タイプフィールド255を使用する場合、VSSオプションまたはサブオプションに追加のVSS情報があってはなりません。 DHCPv4の場合、前述のように、追加のVSS-Controlサブオプションが必要になります。
In some cases, a DHCP server may use the VSS sub-option or option to inform a relay agent that a particular DHCP client is associated with a particular VPN. It does this by sending the VSS sub-option or option with the appropriate information to the relay agent in the Relay Agent Information option for DHCPv4 or the Relay-reply message in DHCPv6. If the relay agent cannot respond correctly to the DHCP server's requirement to place the DHCP client into that VPN (perhaps because it has not been configured with a VPN that matches the VSS information received from the DHCP server), it MUST drop the packet and not send it to the DHCP client.
DHCPサーバーは、VSSサブオプションまたはオプションを使用して、特定のDHCPクライアントが特定のVPNに関連付けられていることをリレーエージェントに通知する場合があります。これは、DHCPv4のリレーエージェント情報オプションまたはDHCPv6のリレー応答メッセージで、適切な情報を含むVSSサブオプションまたはオプションをリレーエージェントに送信することによって行われます。リレーエージェントは、DHCPクライアントをそのVPNに配置するというDHCPサーバーの要件に正しく応答できない場合（おそらく、DHCPサーバーから受信したVSS情報と一致するVPNで構成されていないため）、パケットをドロップせず、 DHCPクライアントに送信します。
In this situation, once the relay agent has placed the DHCP client into the VPN specified by the DHCP server, it will insert a VSS option or sub-option when forwarding packets from the client. The DHCP server in normal operation will echo this VSS information into the outgoing replies.
この状況では、リレーエージェントがDHCPサーバーによって指定されたVPNにDHCPクライアントを配置すると、クライアントからパケットを転送するときに、VSSオプションまたはサブオプションが挿入されます。通常の動作のDHCPサーバーは、このVSS情報を発信応答にエコーします。
In the event that the relay agent doesn't include VSS information on subsequent requests after the DHCP server has included VSS information in a reply to the relay agent, the DHCP server can conclude that the relay agent doesn't support VSS processing, and the DHCP server SHOULD stop processing this transaction and not respond to the request.
DHCPサーバーがリレーエージェントへの応答にVSS情報を含めた後、リレーエージェントが後続の要求にVSS情報を含めない場合、DHCPサーバーは、リレーエージェントがVSS処理をサポートしていないと結論付けることができます。 DHCPサーバーは、このトランザクションの処理を停止し、要求に応答しない必要があります（SHOULD）。
A relay agent sometimes needs to submit a DHCP Leasequery [RFC4388] [RFC5007] packet to the DHCP server in order to recover information about existing DHCP-allocated IP addresses on networks other than the normal, global VPN. In the context of a DHCP Leasequery, the relay agent is a direct client of the DHCP server and is not relaying a packet for another DHCP client. Thus, the instructions in Section 6 ("Client Behavior") should be followed to include the necessary VSS information.
リレーエージェントは、通常のグローバルVPN以外のネットワーク上の既存のDHCP割り当てIPアドレスに関する情報を回復するために、DHCP Leasequery [RFC4388] [RFC5007]パケットをDHCPサーバーに送信する必要がある場合があります。 DHCP Leasequeryのコンテキストでは、リレーエージェントはDHCPサーバーの直接クライアントであり、別のDHCPクライアントのパケットをリレーしていません。したがって、セクション6（「クライアントの動作」）の指示に従って、必要なVSS情報を含める必要があります。
Typically, DHCPv4 and DHCPv6 clients have no interaction with VSS options or sub-options. The VSS information is handled by exchanges between a DHCPv4 or DHCPv6 relay agent and the corresponding DHCPv4 or DHCPv6 server.
通常、DHCPv4およびDHCPv6クライアントは、VSSオプションまたはサブオプションと相互作用しません。 VSS情報は、DHCPv4またはDHCPv6リレーエージェントと対応するDHCPv4またはDHCPv6サーバー間の交換によって処理されます。
However, there are times when an entity is acting as a DHCPv4 or DHCPv6 client in that it is communicating directly with a DHCPv4 or DHCPv6 server. In these instances -- where communication is occurring without employing the DHCPv4 Relay Agent Information option or the DHCPv6 Relay-forward or Relay-reply messages -- the entity is acting as a DHCPv4 or DHCPv6 client with regard to its communication with the DHCPv4 or DHCPv6 server, but not necessarily as a DHCP client that is requesting a DHCPv4 or DHCPv6 address for its own use.
ただし、エンティティがDHCPv4またはDHCPv6サーバーと直接通信しているという点で、エンティティがDHCPv4またはDHCPv6クライアントとして機能している場合があります。これらの場合-DHCPv4リレーエージェント情報オプションまたはDHCPv6リレー転送メッセージまたはリレー応答メッセージを使用せずに通信が行われている場合-エンティティは、DHCPv4またはDHCPv6との通信に関してDHCPv4またはDHCPv6クライアントとして機能していますサーバー、しかし必ずしもそれ自身の使用のためにDHCPv4またはDHCPv6アドレスを要求しているDHCPクライアントとしてではない。
The client, in this context, may be requesting an IP address for another entity, thus acting as a DHCP proxy. The client may be requesting information about another client-to-address binding, using the DHCPv4 [RFC4388] or DHCPv6 [RFC5007] leasequery protocol.
このコンテキストでは、クライアントは別のエンティティのIPアドレスを要求している可能性があり、DHCPプロキシとして機能しています。クライアントは、DHCPv4 [RFC4388]またはDHCPv6 [RFC5007]リースクエリプロトコルを使用して、別のクライアントからアドレスへのバインディングに関する情報を要求している可能性があります。
In the rest of this section, the term "client" refers to an entity communicating VSS information directly to a DHCPv4 or DHCPv6 server without using the DHCPv4 Relay Agent Information option or the DHCPv6 Relay-forward or Relay-reply messages, and there is no requirement that such a client be a traditional DHCPv4 or DHCPv6 client requesting an IP address binding for itself.
このセクションの残りの部分では、「クライアント」という用語は、DHCPv4リレーエージェント情報オプションまたはDHCPv6リレー転送メッセージまたはリレー応答メッセージを使用せずに、VSS情報をDHCPv4またはDHCPv6サーバーに直接通信するエンティティを指し、このようなクライアントは、自身のIPアドレスバインディングを要求する従来のDHCPv4またはDHCPv6クライアントである必要があります。
DHCPv4 or DHCPv6 clients will employ the VSS option to communicate VSS information to their respective servers. This information MUST be included in every message concerning any IP address on a different VPN than the global or default VPN. A DHCPv4 client will place the DHCPv4 VSS option in its packets, and a DHCPv6 client will place the DHCPv6 VSS option in its messages.
DHCPv4またはDHCPv6クライアントは、VSSオプションを使用して、VSS情報をそれぞれのサーバーに通信します。この情報は、グローバルまたはデフォルトのVPNとは異なるVPN上のIPアドレスに関するすべてのメッセージに含める必要があります。 DHCPv4クライアントはDHCPv4 VSSオプションをパケットに入れ、DHCPv6クライアントはDHCPv6 VSSオプションをメッセージに入れます。
A DHCPv6 client that needs to place a VSS option into a DHCPv6 message SHOULD place a single VSS option into the DHCPv6 message at the same level as the Client Identifier option. A DHCPv6 client MUST NOT include different VSS options in the same DHCPv6 message.
VSSvオプションをDHCPv6メッセージに配置する必要があるDHCPv6クライアントは、クライアント識別子オプションと同じレベルで単一のVSSオプションをDHCPv6メッセージに配置する必要があります（SHOULD）。 DHCPv6クライアントは、同じDHCPv6メッセージに異なるVSSオプションを含めてはなりません（MUST NOT）。
Note that -- as mentioned in Section 1 -- throughout this document, when a DHCPv6 address is indicated, the same information applies to DHCPv6 prefix delegation [RFC3633] as well.
このドキュメント全体を通して、セクション1で述べたように、DHCPv6アドレスが示されている場合、同じ情報がDHCPv6プレフィックス委任[RFC3633]にも適用されることに注意してください。
Since this option is placed in the packet in order to change the VPN on which an IP address is allocated for a particular DHCP client, one presumes that an allocation on that VPN is necessary for correct operation. Thus, a client that places this option in a packet and doesn't receive it or receives a different value in a returning packet SHOULD drop the packet, since the IP address that was allocated will not be in the requested VPN.
このオプションは、IPアドレスが特定のDHCPクライアントに割り当てられているVPNを変更するためにパケットに配置されるため、正しい操作にはそのVPNへの割り当てが必要であると推測されます。したがって、割り当てられたIPアドレスは要求されたVPNに含まれないため、このオプションをパケットに入れ、それを受信しないか、返されるパケットで別の値を受信するクライアントは、パケットをドロップする必要があります。
Clients should be aware that some DHCP servers will return a VSS option with different values than the values sent by the client. In addition, a client may receive a response from a DHCP server with a VSS option when none was sent by the client.
クライアントは、一部のDHCPサーバーがクライアントによって送信された値とは異なる値を持つVSSオプションを返すことに注意する必要があります。さらに、クライアントから何も送信されなかった場合、クライアントは、VSSオプションを使用してDHCPサーバーから応答を受信する場合があります。
Note that when sending a DHCP Leasequery request, a relay agent is acting as a DHCP client, and so it SHOULD include the respective DHCPv4 or DHCPv6 VSS option in its DHCPv4 or DHCPv6 Leasequery packet if the DHCP Leasequery request is generated for other than the default, global VPN. It SHOULD NOT include a DHCPv4 sub-option in this case.
DHCP Leasequery要求を送信するとき、リレーエージェントはDHCPクライアントとして機能しているため、デフォルト以外のDHCP Leasequery要求が生成された場合、DHCPv4またはDHCPv6 LeasequeryパケットにそれぞれのDHCPv4またはDHCPv6 VSSオプションを含める必要があります。 、グローバルVPN。この場合、DHCPv4サブオプションを含めないでください。
A DHCP server receiving the VSS option or sub-option SHOULD allocate an IP address (or use the VSS information to access an already allocated IP address) from the VPN specified by the included VSS information.
VSSオプションまたはサブオプションを受信するDHCPサーバーは、含まれているVSS情報で指定されたVPNからIPアドレスを割り当てる（または、VSS情報を使用して既に割り当てられているIPアドレスにアクセスする必要があります）。
In the case where the Type field of the VSS option or sub-option is 255, the VSS option denotes the global, default VPN. In this case, there is no explicit VSS information beyond the Type field.
VSSオプションまたはサブオプションのタイプフィールドが255の場合、VSSオプションはグローバルなデフォルトVPNを示します。この場合、Typeフィールド以外に明示的なVSS情報はありません。
This document does not prescribe any particular address allocation policy. A DHCP server may choose to attempt to allocate an address using the VSS information and, if this is impossible, to not allocate an address. Alternatively, a DHCP server may choose to attempt address allocation based on the VSS information and, if that is not possible, it may fall back to allocating an address on the global or default VPN. This, of course, is also the apparent behavior of any DHCP server that doesn't implement support for the VSS option and sub-option. Thus, DHCP clients and relay agents SHOULD be prepared for either of these alternatives.
このドキュメントでは、特定のアドレス割り当てポリシーを規定していません。 DHCPサーバーは、VSS情報を使用してアドレスを割り当てようとすることも、それが不可能な場合はアドレスを割り当てないこともできます。あるいは、DHCPサーバーは、VSS情報に基づいてアドレス割り当てを試みることを選択でき、それが不可能な場合は、グローバルまたはデフォルトVPNでのアドレス割り当てにフォールバックすることがあります。もちろん、これは、VSSオプションとサブオプションのサポートを実装していないDHCPサーバーの明らかな動作でもあります。したがって、DHCPクライアントとリレーエージェントは、これらの選択肢のいずれかに対して準備する必要があります。
In some cases, a DHCP server may use the VSS sub-option or option to inform a relay agent that a particular DHCP client is associated with a particular VPN. It does this by sending the VSS sub-option or option with the appropriate information to the relay agent in the Relay Agent Information option for DHCPv4 or the Relay-reply message in DHCPv6.
DHCPサーバーは、VSSサブオプションまたはオプションを使用して、特定のDHCPクライアントが特定のVPNに関連付けられていることをリレーエージェントに通知する場合があります。これは、DHCPv4のリレーエージェント情報オプションまたはDHCPv6のリレー応答メッセージで、適切な情報を含むVSSサブオプションまたはオプションをリレーエージェントに送信することによって行われます。
In this situation, the relay agent will place the client in the proper VPN, and then it will insert a VSS option or sub-option in subsequent forwarded requests. The DHCP server will see this VSS information, and since it doesn't conflict in any way with the server's notion of the VPN on which the client is supposed to reside, it will process the requests based on the VPN specified in the VSS option or sub-option, and echo the same VSS information in the outgoing replies.
この場合、リレーエージェントはクライアントを適切なVPNに配置し、その後転送される要求にVSSオプションまたはサブオプションを挿入します。 DHCPサーバーはこのVSS情報を参照し、クライアントが常駐するはずのVPNのサーバーの概念とまったく競合しないため、VSSオプションで指定されたVPNに基づいて要求を処理します。サブオプション、および発信応答で同じVSS情報をエコーします。
The relay agent receiving a reply containing a VSS option should support the VSS option. Otherwise, the relay agent will end up attempting to use the address as though it were a global address. Should this happen, the subsequent DHCPREQUEST will not contain any VSS information, in which case the DHCP server SHOULD NOT respond with a DHCPACK.
VSSオプションを含む応答を受信するリレーエージェントは、VSSオプションをサポートする必要があります。それ以外の場合、リレーエージェントは、あたかもグローバルアドレスであるかのようにアドレスを使用しようとします。これが発生した場合、後続のDHCPREQUESTにはVSS情報が含まれません。その場合、DHCPサーバーはDHCPACKで応答すべきではありません（SHOULD NOT）。
If a server uses a different VPN than what was specified in the VSS option or sub-option, it SHOULD send back the VPN information using the same type as the received type. It MAY send back a different type if it is not possible to use the same type (such as the RFC2685 VPN-ID if no ASCII VPN identifier exists).
サーバーがVSSオプションまたはサブオプションで指定されたものとは異なるVPNを使用する場合、サーバーは受信したタイプと同じタイプを使用してVPN情報を送り返す必要があります（SHOULD）。同じタイプ（ASCII VPN識別子が存在しない場合のRFC2685 VPN-IDなど）を使用できない場合は、別のタイプを返送してもよい（MAY）。
A server that receives a VSS sub-option in the DHCPv4 Relay Agent Information option and does not receive a VSS-Control sub-option in the Relay Agent Information option MUST process the information specified in the VSS sub-option in the same fashion as it would have if it received both sub-options.
DHCPv4リレーエージェント情報オプションでVSSサブオプションを受信し、リレーエージェント情報オプションでVSS-Controlサブオプションを受信しないサーバーは、VSSサブオプションで指定された情報を同じ方法で処理する必要があります両方のサブオプションを受け取った場合に発生します。
DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option processing, see below) MUST return an instance of this option in the reply packet or message if the server successfully uses this option to allocate an IP address, and it MUST NOT include an instance of this option if the server is unable to support, is not configured to support, or does not implement support for VSS information in general or the requested VPN in particular.
サーバーがこのオプションを使用してIPアドレスを割り当てることに成功した場合、VSSオプションを受信するDHCPv4またはDHCPv6サーバー（サブオプション処理については、以下を参照）は、このオプションのインスタンスを応答パケットまたはメッセージで返す必要があり、サーバーがサポートできない、サポートするように構成されていない、または一般的にVSS情報、特に要求されたVPNのサポートを実装していない場合のこのオプションのインスタンス。
If they echo the option (based on the criteria above), servers SHOULD return an exact copy of the option unless they desire to change the VPN on which a client was configured.
（上記の基準に基づいて）オプションをエコーする場合、サーバーは、クライアントが構成されたVPNを変更することを望まない限り、オプションの正確なコピーを返す必要があります（SHOULD）。
The appearance of the DHCPv4 VSS option code in the DHCPv4 Parameter Request List option [RFC2132] should not change the processing or decision to return or not return the VSS option as specified in this document. The appearance of the DHCPv6 VSS option in the OPTION_ORO [RFC3315] or the OPTION_ERO [RFC4994] should not change the processing or decision to return (or not to return) the VSS option as specified in this document.
DHCPv4パラメータ要求リストオプション[RFC2132]にDHCPv4 VSSオプションコードが表示されても、このドキュメントで指定されているように、VSSオプションを返すか返さないかの処理または決定は変更されません。 OPTION_ORO [RFC3315]またはOPTION_ERO [RFC4994]にDHCPv6 VSSオプションが表示されていても、このドキュメントで指定されているように、VSSオプションを返す（または返さない）処理または決定は変更されません。
The case of the DHCPv4 sub-option is a bit more complicated. Note that [RFC3046] specifies that a DHCPv4 server that supports the Relay Agent Information option SHALL copy all sub-options received in a Relay Agent Information option into any outgoing Relay Agent Information option. Thus, the default behavior for any DHCPv4 server is to return any VSS sub-option received to the relay agent whether or not the DHCPv4 server understands the VSS sub-option.
DHCPv4サブオプションの場合は少し複雑です。 [RFC3046]は、リレーエージェント情報オプションをサポートするDHCPv4サーバーが、リレーエージェント情報オプションで受信したすべてのサブオプションを任意の発信リレーエージェント情報オプションにコピーすることを指定することに注意してください。したがって、DHCPv4サーバーがVSSサブオプションを理解しているかどうかに関係なく、DHCPv4サーバーのデフォルトの動作では、受信したVSSサブオプションをリレーエージェントに返します。
In order to distinguish a DHCPv4 server that is simply copying Relay Agent Information option sub-options from an incoming to an outgoing Relay Agent Information option from a DHCPv4 server that successfully acted upon the information in the VSS sub-option, DHCPv4 relay agents MUST include a VSS-Control sub-option in the Relay Agent Information any time that it includes a VSS sub-option in the Relay Agent Information option.
リレーエージェント情報オプションサブオプションを着信リレーエージェント情報オプションから発信リレーエージェント情報オプションにコピーするDHCPv4サーバーを、VSSサブオプションの情報に基づいて正常に機能したDHCPv4サーバーから区別するために、DHCPv4リレーエージェントはリレーエージェント情報のVSS-Controlサブオプションに、リレーエージェント情報のオプションにVSSサブオプションが含まれている場合。
A DHCPv4 server that does not support the VSS sub-option will copy both sub-options into the outgoing Relay Agent Information option, thus signaling to the DHCPv4 relay agent that it did not understand the VSS sub-option.
VSSサブオプションをサポートしないDHCPv4サーバーは、両方のサブオプションを発信リレーエージェント情報オプションにコピーし、VSSサブオプションを理解しなかったことをDHCPv4リレーエージェントに通知します。
A DHCPv4 server that supports the VSS sub-option
VSSサブオプションをサポートするDHCPv4サーバー
o MUST copy the VSS sub-option into the outgoing Relay Agent Information option
o VSSサブオプションを発信リレーエージェント情報オプションにコピーする必要があります
o MUST NOT copy the VSS-Control sub-option into the outgoing Relay Agent Information option
o VSS-Controlサブオプションを発信リレーエージェント情報オプションにコピーしないでください
Moreover, if a server uses different VSS information to allocate an IP address than it receives in a particular DHCPv4 sub-option, it MUST include that alternative VSS information in the VSS sub-option that it returns to the DHCPv4 relay agent instead of the original VSS information it was given.
さらに、サーバーが特定のDHCPv4サブオプションで受信したものとは異なるVSS情報を使用してIPアドレスを割り当てる場合、サーバーは、元の代わりにDHCPv4リレーエージェントに返すVSSサブオプションにその代替VSS情報を含める必要があります。提供されたVSS情報。
If a DHCPv4 server supports this sub-option and for some reason (perhaps administrative control) does not honor this sub-option from the request, then it MUST NOT echo either sub-option into the outgoing Relay Agent Information option.
DHCPv4サーバーがこのサブオプションをサポートし、何らかの理由（おそらく管理制御）が要求からこのサブオプションを受け入れない場合、いずれかのサブオプションを発信リレーエージェント情報オプションにエコーしてはなりません（MUST NOT）。
It is possible for a DHCPv4 server to receive both a VSS option and VSS sub-options in the same packet. Likewise, a DHCPv6 server can receive multiple VSS options in nested Relay-forward messages as well as in the client message itself. In either of these cases, the VSS information from the relay agent closest to the DHCP server SHOULD be used in preference to all other VSS information received. In the DHCPv4 case, this means that the VSS sub-option takes precedence over the VSS option, and in the DHCPv6 case, this means that the VSS option from the outermost Relay-forward message in which a VSS option appears takes precedence.
DHCPv4サーバーが同じパケットでVSSオプションとVSSサブオプションの両方を受信する可能性があります。同様に、DHCPv6サーバーは、ネストされたリレー転送メッセージとクライアントメッセージ自体で複数のVSSオプションを受信できます。これらのいずれの場合でも、DHCPサーバーに最も近いリレーエージェントからのVSS情報を、受信した他のすべてのVSS情報よりも優先して使用する必要があります（SHOULD）。 DHCPv4の場合、これはVSSサブオプションがVSSオプションよりも優先されることを意味し、DHCPv6の場合、これは、VSSオプションが表示される最も外側のリレー転送メッセージからのVSSオプションが優先されることを意味します。
The reasoning behind this approach is that the relay agent closer to the DHCP server is almost certainly more trusted than the DHCP client or more distant relay agents, and therefore information in the Relay Agent Information option or the Relay-forward message is more likely to be correct.
このアプローチの背後にある理由は、DHCPサーバーに近いリレーエージェントは、DHCPクライアントまたはより遠いリレーエージェントよりもほぼ確実に信頼されているため、リレーエージェント情報オプションまたはリレー転送メッセージの情報は、正しい。
In general, relay agents SHOULD be aware through configuration or policy external to this document whether or not they should be including VSS information in packets that they forward, and so these relay agents should not specify any conflicting VSS information.
一般に、リレーエージェントは、このドキュメントの外部にある構成またはポリシーを通じて、転送するパケットにVSS情報を含める必要があるかどうかを認識する必要があります。したがって、これらのリレーエージェントは、競合するVSS情報を指定してはなりません。
In situations where multiple VSS options or sub-options appear in the incoming packet or message, when the DHCP server constructs the response to be sent to the DHCP client or relay agent, all existing VSS options or sub-options MUST be replicated in the appropriate places in the response and MUST contain only the VSS information that was used by the DHCP server to allocate the IP address (with, of course, the exception of a VSS-Control sub-option of a DHCPv4 Relay Agent Information option).
着信パケットまたはメッセージに複数のVSSオプションまたはサブオプションが表示される状況で、DHCPサーバーがDHCPクライアントまたはリレーエージェントに送信される応答を構築する場合、既存のすべてのVSSオプションまたはサブオプションを適切な場所に複製する必要があります。応答に配置し、DHCPサーバーがIPアドレスを割り当てるために使用したVSS情報のみを含める必要があります（もちろん、DHCPv4リレーエージェント情報オプションのVSS-Controlサブオプションを除く）。
This document updates the specification of the Relay Agent Information option in Section 2.2 of RFC 3046, in the first sentence of the second paragraph, as follows:
このドキュメントは、RFC 3046のセクション2.2の2番目の段落の最初の文にあるリレーエージェント情報オプションの仕様を次のように更新します。
o OLD:
o 古い：
DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies.
リレーエージェント情報オプションをサポートすると主張するDHCPサーバーは、すべての応答でリレーエージェント情報オプションの内容全体をエコーする必要があります。
o NEW:
o 新着：
DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies, except if otherwise specified in the definition of specific Relay Agent Information sub-options.
リレーエージェント情報オプションのサポートを要求するDHCPサーバーは、特定のリレーエージェント情報サブオプションの定義で特に指定されていない限り、すべての応答でリレーエージェント情報オプションの内容全体をエコーする必要があります。
Message authentication in DHCPv4 for intradomain use where the out-of-band exchange of a shared secret is feasible is defined in [RFC3118]. Potential exposures to attack are discussed in Section 7 of the DHCP protocol specification [RFC2131].
共有シークレットの帯域外交換が可能なイントラドメイン用のDHCPv4でのメッセージ認証は、[RFC3118]で定義されています。攻撃を受ける可能性については、DHCPプロトコル仕様[RFC2131]のセクション7で説明されています。
Implementations should consider using the DHCPv4 Authentication option [RFC3118] to protect DHCPv4 client access in order to provide a higher level of security if it is deemed necessary in their environment.
実装では、DHCPv4認証オプション[RFC3118]を使用してDHCPv4クライアントアクセスを保護し、環境で必要と思われる場合により高いレベルのセキュリティを提供することを検討する必要があります。
Message authentication in DHCPv4 relay agents as defined in [RFC4030] should be considered for DHCPv4 relay agents employing the sub-options defined in this document. Potential exposures to attack are discussed in Section 7 of the DHCP protocol specification [RFC2131].
[RFC4030]で定義されているDHCPv4リレーエージェントでのメッセージ認証は、このドキュメントで定義されているサブオプションを使用するDHCPv4リレーエージェントで検討する必要があります。攻撃を受ける可能性については、DHCPプロトコル仕様[RFC2131]のセクション7で説明されています。
For use of the VSS option by DHCPv6, the Security Considerations section of [RFC3315] details the general threats to DHCPv6, and thus to messages using the VSS option. The "Authentication of DHCP Messages" section of [RFC3315] describes securing communication between relay agents and servers, as well as clients and servers.
DHCPv6によるVSSオプションの使用については、[RFC3315]のセキュリティに関する考慮事項のセクションで、DHCPv6に対する一般的な脅威、つまり、VSSオプションを使用するメッセージに対する詳細が説明されています。 [RFC3315]の「DHCPメッセージの認証」セクションでは、リレーエージェントとサーバー、およびクライアントとサーバー間の通信のセキュリティ保護について説明しています。
The VSS option could be used by a client in order to obtain an IP address from any VPN. This option would allow a client to perform a more complete address-pool exhaustion attack, since the client would no longer be restricted to attacking address pools on just its local subnet.
クライアントは、VPNからIPアドレスを取得するために、VSSオプションを使用できます。このオプションを使用すると、クライアントはローカルサブネットのみでのアドレスプールの攻撃に制限されなくなるため、クライアントはより完全なアドレスプール枯渇攻撃を実行できます。
A DHCP server that implements these VSS options and the VSS sub-option should be aware of this possibility and use whatever techniques can be devised to prevent such an attack. Information such as the giaddr in DHCPv4 or link address in the Relay-forward DHCPv6 message might be used to detect and prevent this sort of attack.
これらのVSSオプションとVSSサブオプションを実装するDHCPサーバーは、この可能性を認識し、そのような攻撃を防ぐために考案できるあらゆる手法を使用する必要があります。 DHCPv4のgiaddrやRelay-forward DHCPv6メッセージのリンクアドレスなどの情報は、この種の攻撃を検出して防止するために使用される可能性があります。
One possible defense would be for the DHCP relay agent to insert a VSS option or sub-option to override the DHCP client's VSS option.
考えられる防御策の1つは、DHCPリレーエージェントがVSSオプションまたはサブオプションを挿入して、DHCPクライアントのVSSオプションを上書きすることです。
Servers that implement the VSS option and sub-option MUST by default disable use of the feature; it must specifically be enabled through configuration. Moreover, a server SHOULD provide the ability to selectively enable use of the feature under restricted conditions, e.g., by enabling use of the option only from explicitly configured client-ids, enabling its use only by clients on a particular subnet, or restricting the VSSs from which addresses may be requested.
VSSオプションとサブオプションを実装するサーバーは、デフォルトで機能の使用を無効にする必要があります。これは、構成によって具体的に有効にする必要があります。さらに、サーバーは、明示的に構成されたクライアントIDからのみオプションの使用を有効にする、特定のサブネット上のクライアントのみが使用できるようにする、VSSを制限するなど、制限された条件下で機能の使用を選択的に有効にする機能を提供する必要があります（SHOULD）。リクエスト元のアドレス。
IANA has assigned DHCPv4 option number 221 to the DHCPv4 Virtual Subnet Selection option defined in Section 3.1, in accordance with [RFC3942].
[RFC3942]に従い、IANAはセクション3.1で定義されたDHCPv4仮想サブネット選択オプションにDHCPv4オプション番号221を割り当てました。
IANA has assigned sub-option number 151 to the DHCPv4 Virtual Subnet Selection sub-option defined in Section 3.2 from the DHCP Relay Agent Sub-options space [RFC3046], in accordance with the spirit of [RFC3942]. While [RFC3942] doesn't explicitly mention the sub-option space for the DHCP Relay Agent Information option [RFC3046], sub-option 151 is already in use by existing implementations of this sub-option, and this document is essentially upward-compatible with these current implementations.
IANAは、[RFC3942]の精神に従って、DHCPリレーエージェントサブオプションスペース[RFC3046]からセクション3.2で定義されたDHCPv4仮想サブネット選択サブオプションにサブオプション番号151を割り当てました。 [RFC3942]はDHCPリレーエージェント情報オプション[RFC3046]のサブオプションスペースについて明示的に言及していませんが、サブオプション151はこのサブオプションの既存の実装ですでに使用されており、このドキュメントは基本的に上位互換ですこれらの現在の実装。
IANA has assigned the value of 152 to the DHCPv4 Virtual Subnet Selection Control sub-option defined in Section 3.3.
IANAは、セクション3.3で定義されたDHCPv4仮想サブネット選択制御サブオプションに152の値を割り当てました。
IANA has assigned the value of 68 for the DHCPv6 Virtual Subnet Selection option defined in Section 3.4 from the DHCP Option Codes registry.
IANAは、セクション3.4で定義されているDHCPv6仮想サブネット選択オプションに68の値をDHCPオプションコードレジストリから割り当てています。
The Type byte defined in Section 3.5 defines a number space for which IANA has created and will maintain a new sub-registry entitled "VSS Type Options". This sub-registry needs to be related to both the DHCPv4 and DHCPv6 VSS options and the DHCPv4 Relay Agent Information option sub-option (all defined by this document), since the Type byte in these two options and the VSS sub-option MUST have identical definitions.
セクション3.5で定義されたタイプバイトは、IANAが作成した番号スペースを定義し、「VSSタイプオプション」というタイトルの新しいサブレジストリを維持します。このサブレジストリは、DHCPv4とDHCPv6の両方のVSSオプションとDHCPv4リレーエージェント情報オプションサブオプション（すべてこのドキュメントで定義）に関連している必要があります。これらの2つのオプションのタイプバイトとVSSサブオプションには同一の定義。
New values for the Type byte may only be defined by IETF Review, as described in [RFC5226]. Basically, this means that they are defined by RFCs approved by the IESG.
タイプバイトの新しい値は、[RFC5226]で説明されているように、IETFレビューでのみ定義できます。基本的に、これは、それらがIESGによって承認されたRFCによって定義されていることを意味します。
Jay Kumarasamy contributed to earlier versions of this document. Bernie Volz recommended consolidation of the DHCPv4 option and sub-option documents after extensive review of those former documents, and provided valuable assistance in structuring and reviewing this document. Alper Yegin expressed interest in the DHCPv6 VSS option, resulting in this combined document covering all three areas. Alfred Hoenes provided assistance with editorial review and also raised substantive protocol issues. David Hankins and Bernie Volz each raised important protocol issues that resulted in a clarified document. Josh Littlefield provided editorial assistance. Several IESG reviewers took the time to substantially review this document, resulting in much-improved clarity.
Jay Kumarasamyがこのドキュメントの以前のバージョンに貢献しました。バーニーヴォルツは、DHCPv4オプションとサブオプションのドキュメントを統合して、これらの以前のドキュメントを十分に検討した後、このドキュメントの構成とレビューに役立つ情報を提供しました。 Alper YeginはDHCPv6 VSSオプションに関心を示し、この3つの領域すべてをカバーするこの結合されたドキュメントになりました。 Alfred Hoenesは編集レビューを支援し、プロトコルに関する実質的な問題も提起しました。 David HankinsとBernie Volzはそれぞれ、重要なプロトコルの問題を提起し、その結果、ドキュメントが明確になりました。 Josh Littlefieldが編集支援を提供しました。何人かのIESGレビューアが時間をかけてこのドキュメントを大幅にレビューしたため、明確さが大幅に改善されました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999.
[RFC2685] Fox、B。およびB. Gleeson、「Virtual Private Networks Identifier」、RFC 2685、1999年9月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC4994] Zeng, S., Volz, B., Kinnear, K. and J. Brzozowski, "DHCPv6 Relay Agent Echo Request Option", RFC 4994, September 2007.
[RFC4994] Zeng、S.、Volz、B.、Kinnear、K.、J。Brzozowski、「DHCPv6リレーエージェントエコー要求オプション」、RFC 4994、2007年9月。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951] Croft、W. and J. Gilmore、 "Bootstrap Protocol"、RFC 951、September 1985。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[RFC1542] Wimer、W。、「Bootstrap Protocolの説明と拡張」、RFC 1542、1993年10月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、Ed。およびW. Arbaugh、Ed。、「Authentication for DHCP Messages」、RFC 3118、2001年6月。
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC3942] Volz、B。、「Reclassifying Dynamic Host Configuration Protocol version 4（DHCPv4）Options」、RFC 3942、2004年11月。
[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005.
[RFC4030] Stapp、M。およびT. Lemon、「動的ホスト構成プロトコル（DHCP）リレーエージェントオプションの認証サブオプション」、RFC 4030、2005年3月。
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC4388] Woundy、R。、およびK. Kinnear、「Dynamic Host Configuration Protocol（DHCP）Leasequery」、RFC 4388、2006年2月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007] Brzozowski、J.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPv6 Leasequery」、RFC 5007、2007年9月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「Network InterchangeのUnicode形式」、RFC 5198、2008年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
Authors' Addresses
著者のアドレス
Kim Kinnear Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719
きｍ きんえあｒ しｓこ Ｓｙｓてｍｓ １４１４ まっさちゅせっｔｓ あゔぇ。 ぼｘぼろうｇｈ、 ま ０１７１９
Phone: (978) 936-0000 EMail: kkinnear@cisco.com
電話：（978）936-0000メール：kkinnear@cisco.com
Richard Johnson Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134
リチャードジョンソンシスコシステムズ170 W.タスマンDr.サンノゼ、CA 95134
Phone: (408) 526-4000 EMail: raj@cisco.com
電話：（408）526-4000メール：raj@cisco.com
Mark Stapp Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719
Mark Stapp Cisco Systems 1414 Massachusetts Ave. Boxborough、MA 01719
Phone: (978) 936-0000 EMail: mjs@cisco.com
電話：（978）936-0000メール：mjs@cisco.com