[要約] RFC 8213は、サーバーとリレーエージェント間で交換されるメッセージのセキュリティに関するガイドラインです。目的は、メッセージの機密性と整合性を確保し、攻撃やデータの改ざんから保護することです。
Internet Engineering Task Force (IETF) B. Volz
Request for Comments: 8213 Y. Pal
Category: Standards Track Cisco Systems
ISSN: 2070-1721 August 2017
Security of Messages Exchanged between Servers and Relay Agents
サーバーとリレーエージェント間で交換されるメッセージのセキュリティ
Abstract
概要
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.
IPv4の動的ホスト構成プロトコル（DHCPv4）には、サーバーとリレーエージェント間で交換されるメッセージを保護する方法に関するガイダンスがありません。 IPv6の動的ホスト構成プロトコル（DHCPv6）では、サーバーとリレーエージェント間で交換されるメッセージを保護するためにIPsecを使用する必要があるが、暗号化は不要であると述べています。広範囲にわたる監視やその他の攻撃に関する最近の懸念により、DHCPv6の場合はリレーとリレー間、サーバーとの通信はセキュアに、DHCPv4の場合はリレーとサーバー間の通信をセキュリティで保護する必要があります。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8213.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8213で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 ....................................................2
2. Requirements Language and Terminology ...........................3
3. Security of Messages Exchanged between Servers and Relay
Agents ..........................................................3
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
Acknowledgments ....................................................8
Authors' Addresses .................................................8
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) [RFC2131] and the Bootstrap Protocol [RFC1542] have no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] states that IPsec should be used to secure messages exchanged between servers and relay agents but does not recommend encryption. With recent concerns about pervasive monitoring [RFC7258], it is appropriate to require use of IPsec with encryption for relay-to-server communication for DHCPv4 and require use of IPsec with encryption for relay-to-relay and relay-to-server communication for DHCPv6.
IPv4の動的ホスト構成プロトコル（DHCPv4）[RFC2131]およびブートストラッププロトコル[RFC1542]には、サーバーとリレーエージェント間で交換されるメッセージを保護する方法に関するガイダンスがありません。 IPv6の動的ホスト構成プロトコル（DHCPv6）[RFC3315]は、IPsecを使用してサーバーとリレーエージェント間で交換されるメッセージを保護する必要があると述べていますが、暗号化は推奨していません。パーベイシブモニタリング[RFC7258]に関する最近の懸念から、DHCPv4のリレーからサーバーへの通信には暗号化を伴うIPsecの使用を要求し、リレーからリレーおよびリレーからサーバーへの通信には暗号化を伴うIPsecの使用を要求することが適切DHCPv6。
This document specifies the optional requirements for relay agent and server implementations to support IPsec authentication and encryption and recommends that operators enable this IPsec support.
このドキュメントでは、IPsec認証と暗号化をサポートするためのリレーエージェントとサーバー実装のオプションの要件を指定し、オペレーターがこのIPsecサポートを有効にすることを推奨しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses terminology from [RFC1542], [RFC2131], and [RFC3315].
このドキュメントでは、[RFC1542]、[RFC2131]、および[RFC3315]の用語を使用しています。
For DHCPv6 [RFC3315], this specification REQUIRES relay and server implementations to support IPsec encryption of relay-to-relay and relay-to-server communication as documented below. The remainder of this section replaces the text in Section 21.1 of [RFC3315] when this specification is followed.
DHCPv6 [RFC3315]の場合、この仕様では、リレーとサーバーの実装で、リレーとリレー間の通信とリレーとサーバー間の通信のIPsec暗号化をサポートする必要があります。このセクションの残りの部分は、この仕様に従うと、[RFC3315]のセクション21.1のテキストを置き換えます。
For DHCPv4 [RFC2131], this specification REQUIRES relay and server implementations to support IPsec encryption of relay-to-server communication as documented below.
DHCPv4 [RFC2131]の場合、この仕様では、リレーとサーバーの実装でリレーとサーバー間の通信のIPsec暗号化をサポートする必要があります。
This specification RECOMMENDS that operators enable IPsec for this communication.
この仕様は、オペレーターがこの通信に対してIPsecを有効にすることを推奨します。
By using IPsec with encryption for this communication, potentially sensitive client message and relay included information, such as the DHCPv4 Relay Agent Information option (82) [RFC3046], vendor-specific information (for example, the options defined in [CableLabs-DHCP]), and Access-Network-Identifier option(s) [RFC7839], are protected from pervasive monitoring and other attacks.
この通信にIPsecと暗号化を使用することにより、機密性の高いクライアントメッセージとリレーにDHCPv4リレーエージェント情報オプション（82）[RFC3046]、ベンダー固有の情報（[CableLabs-DHCP]で定義されているオプションなど）が含まれます。 ）、およびAccess-Network-Identifierオプション（複数可）[RFC7839]は、広範囲にわたる監視やその他の攻撃から保護されています。
Relay agents and servers MUST be able to exchange messages using the IPsec mechanisms described in [RFC4301] with the conditions below. If a client message is relayed through multiple relay agents (relay chain), each of the relay agents MUST have established independent, pairwise trust relationships. That is, if messages from client C will be relayed by relay agent A to relay agent B and then to the server, relay agents A and B MUST be configured to use IPsec for the messages they exchange, and relay agent B and the server MUST be configured to use IPsec for the messages they exchange.
リレーエージェントとサーバーは、[RFC4301]で説明されているIPsecメカニズムを使用して、以下の条件でメッセージを交換できる必要があります。クライアントメッセージが複数のリレーエージェント（リレーチェーン）を介してリレーされる場合、各リレーエージェントは独立したペアごとの信頼関係を確立している必要があります。つまり、クライアントCからのメッセージがリレーエージェントAからリレーエージェントBに、次にサーバーにリレーされる場合、リレーエージェントAとBは、交換するメッセージにIPsecを使用するように構成する必要があり、リレーエージェントBとサーバーは交換するメッセージにIPsecを使用するように構成する。
Relay agents and servers use IPsec with the following conditions:
リレーエージェントとリレーサーバーは、次の条件でIPsecを使用します。
Selectors Relay agents are manually configured with the addresses of the relay agent or server to which DHCP messages are to be forwarded. Each relay agent and server that will be using IPsec for securing DHCP messages MUST also be configured with a list of the relay agents to which messages will be returned. The selectors for the relay agents and servers will be the pairs of addresses defining relay agents and servers and the direction of DHCP message exchange on DHCPv4 UDP port 67 or DHCPv6 UDP port 547.
セレクターリレーエージェントは、DHCPメッセージの転送先のリレーエージェントまたはサーバーのアドレスを使用して手動で構成されます。 DHCPメッセージを保護するためにIPsecを使用する各リレーエージェントとサーバーも、メッセージが返されるリレーエージェントのリストで構成する必要があります。リレーエージェントとサーバーのセレクタは、リレーエージェントとサーバーを定義するアドレスのペアと、DHCPv4 UDPポート67またはDHCPv6 UDPポート547でのDHCPメッセージ交換の方向になります。
Mode Relay agents and servers MUST use IPsec in transport mode and use Encapsulating Security Payload (ESP).
モードリレーエージェントとサーバーは、トランスポートモードでIPsecを使用し、カプセル化セキュリティペイロード（ESP）を使用する必要があります。
Encryption and authentication algorithms This document REQUIRES combined mode algorithms for ESP authenticated encryption, ESP encryption algorithms, and ESP authentication algorithms as per Sections 2.1, 2.2, and 2.3 of [RFC7321], respectively. Encryption is required as relay agents may forward unencrypted client messages as well as include additional sensitive information, such as vendor-specific information (for example, the options defined in [CableLabs-DHCP]) and the Access-Network-Identifier Option defined in [RFC7839].
暗号化および認証アルゴリズムこのドキュメントでは、[RFC7321]のセクション2.1、2.2、2.3にそれぞれ準拠した、ESP認証暗号化、ESP暗号化アルゴリズム、およびESP認証アルゴリズムの複合モードアルゴリズムが必要です。リレーエージェントは暗号化されていないクライアントメッセージを転送するだけでなく、ベンダー固有の情報（[CableLabs-DHCP]で定義されているオプションなど）や[で定義されているAccess-Network-Identifier Option RFC7839]。
Key management Because both relay agents and servers tend to be managed by a single organizational entity, public key schemes MAY be optional. Manually configured key management MAY suffice but does not provide defense against replayed messages. Accordingly, Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] with pre-shared secrets SHOULD be supported. IKEv2 with public keys MAY be supported. Additional information on manual vs. automated key management and when one should be used over the other can be found in [RFC4107].
キー管理リレーエージェントとサーバーの両方が単一の組織エンティティによって管理される傾向があるため、公開キースキームはオプションの場合があります。手動で構成された鍵管理で十分かもしれませんが、再生されたメッセージに対する防御を提供しません。したがって、事前共有秘密を備えたインターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC7296]をサポートする必要があります（SHOULD）。公開鍵付きのIKEv2がサポートされる場合があります。手動と自動のキー管理に関する追加情報、および一方を他方に対して使用する必要がある場合については、[RFC4107]を参照してください。
Security policy DHCP messages between relay agents and servers MUST only be accepted from DHCP peers as identified in the local configuration.
セキュリティポリシーリレーエージェントとサーバー間のDHCPメッセージは、ローカル構成で識別されているDHCPピアからのみ受け入れる必要があります。
Authentication Shared keys, indexed to the source IP address of the received DHCP message, are adequate in this application.
このアプリケーションでは、受信したDHCPメッセージの送信元IPアドレスにインデックスが付けられた認証共有キーで十分です。
Note: As using IPsec with multicast has additional complexities (see [RFC5374]), relay agents SHOULD be configured to forward DHCP messages to unicast addresses.
注：マルチキャストでIPsecを使用するとさらに複雑になるため（[RFC5374]を参照）、リレーエージェントはDHCPメッセージをユニキャストアドレスに転送するように構成する必要があります（SHOULD）。
The security model specified in this document is hop by hop. For DHCPv6, there could be multiple relay agents between a client and server, and each of these hops needs to be secured. For DHCPv4, there is no support for multiple relays.
このドキュメントで指定されているセキュリティモデルはホップバイホップです。 DHCPv6の場合、クライアントとサーバーの間に複数のリレーエージェントが存在する可能性があり、これらの各ホップを保護する必要があります。 DHCPv4の場合、複数のリレーはサポートされません。
As this document only mandates securing messages exchanged between relay agents and servers, the message exchanges between clients and the first-hop relay agent or server are not secured. Clients may follow the recommendations in [RFC7844] to minimize what information they expose or make use of secure DHCPv6 [SEC-DHCPv6] to secure communication between the client and server.
このドキュメントでは、リレーエージェントとサーバー間で交換されるメッセージのセキュリティ保護のみを義務付けているため、クライアントとファーストホップリレーエージェントまたはサーバー間のメッセージ交換は保護されません。クライアントは、[RFC7844]の推奨事項に従って、公開する情報を最小限にするか、クライアントとサーバー間の通信を保護するために安全なDHCPv6 [SEC-DHCPv6]を利用することができます。
As mentioned in Section 14 of [RFC4552], the following are known limitations of the usage of manual keys:
[RFC4552]のセクション14で述べたように、手動キーの使用に関する既知の制限は次のとおりです。
o As the sequence numbers cannot be negotiated, replay protection cannot be provided. This leaves DHCP insecure against all the attacks that can be performed by replaying DHCP packets.
o シーケンス番号をネゴシエートできないため、リプレイ保護を提供できません。これにより、DHCPパケットを再生することで実行できるすべての攻撃に対してDHCPの安全性が失われます。
o Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
o 手動キーは通常、長寿命です（多くの場合、それらを変更するのは面倒な作業です）。これにより、攻撃者はキーを発見するのに十分な時間を確保できます。
It should be noted that if the requirements in this document are followed, while the DHCP traffic on the wire between relays and servers is encrypted, the unencrypted data may still be available through other attacks on the DHCP servers, relays, and related systems. Securing these systems and the data in databases and logs also needs to be considered on both the systems themselves and when transferred over a network (i.e., to network attached storage for backups or to operational support systems).
このドキュメントの要件が満たされている場合、リレーとサーバー間のワイヤー上のDHCPトラフィックは暗号化されますが、DHCPサーバー、リレー、および関連システムに対する他の攻撃を通じて、暗号化されていないデータが引き続き利用できる可能性があることに注意してください。これらのシステムとデータベースおよびログのデータを保護することは、システム自体と、ネットワーク経由で転送されるとき（つまり、バックアップ用のネットワーク接続ストレージまたは運用サポートシステム）の両方で考慮する必要があります。
Use of IPsec as described herein is also applicable to Lightweight DHCPv6 Relay Agents [RFC6221], as they have a link-local address that can be used to secure communication with their next-hop relay(s).
ここに記載されているIPsecの使用は、ネクストホップリレーとの通信をセキュリティで保護するために使用できるリンクローカルアドレスを持っているため、軽量DHCPv6リレーエージェント[RFC6221]にも適用できます。
This document makes no request of IANA.
このドキュメントは、IANAの要求を行いません。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, October 1993, <http://www.rfc-editor.org/info/rfc1542>.
[RFC1542] Wimer、W。、「ブートストラッププロトコルの説明と拡張」、RFC 1542、DOI 10.17487 / RFC1542、1993年10月、<http://www.rfc-editor.org/info/rfc1542>。
[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>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, <http://www.rfc-editor.org/info/rfc7321>.
[RFC7321] McGrew、D。およびP. Hoffman、「暗号化アルゴリズムの実装要件およびカプセル化セキュリティペイロード（ESP）および認証ヘッダー（AH）の使用ガイダンス」、RFC 7321、DOI 10.17487 / RFC7321、2014年8月、<http：/ /www.rfc-editor.org/info/rfc7321>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[CableLabs-DHCP] CableLabs, "CableLabs' DHCP Options Registry", <https://apps.cablelabs.com/specification/CL-SP-CANN-DHCP-Reg>.
[CableLabs-DHCP] CableLabs、「CableLabsのDHCPオプションレジストリ」、<https://apps.cablelabs.com/specification/CL-SP-CANN-DHCP-Reg>。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, <http://www.rfc-editor.org/info/rfc3046>.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、DOI 10.17487 / RFC3046、2001年1月、<http://www.rfc-editor.org/info/rfc3046>。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <http://www.rfc-editor.org/info/rfc4107>.
[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、DOI 10.17487 / RFC4107、2005年6月、<http://www.rfc-editor.org/info/rfc4107 >。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <http://www.rfc-editor.org/info/rfc4552>.
[RFC4552] Gupta、M。およびN. Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、DOI 10.17487 / RFC4552、2006年6月、<http://www.rfc-editor.org/info/rfc4552>。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, <http://www.rfc-editor.org/info/rfc5374>.
[RFC5374] Weis、B.、Gross、G。、およびD. Ignjatic、「インターネットプロトコルのセキュリティアーキテクチャに対するマルチキャスト拡張機能」、RFC 5374、DOI 10.17487 / RFC5374、2008年11月、<http：//www.rfc -editor.org/info/rfc5374>。
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <http://www.rfc-editor.org/info/rfc6221>.
[RFC6221] Miles、D.、Ed。、Ooghe、S.、Dec、W.、Krishnan、S.、and A. Kavanagh、 "Lightweight DHCPv6 Relay Agent"、RFC 6221、DOI 10.17487 / RFC6221、May 2011、< http://www.rfc-editor.org/info/rfc6221>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC7839] Bhandari, S., Gundavelli, S., Grayson, M., Volz, B., and J. Korhonen, "Access-Network-Identifier Option in DHCP", RFC 7839, DOI 10.17487/RFC7839, June 2016, <http://www.rfc-editor.org/info/rfc7839>.
[RFC7839] Bhandari、S.、Gundavelli、S.、Grayson、M.、Volz、B。、およびJ. Korhonen、「DHCPのAccess-Network-Identifier Option」、RFC 7839、DOI 10.17487 / RFC7839、2016年6月、 <http://www.rfc-editor.org/info/rfc7839>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T。、およびS. Krishnan、「DHCPクライアントの匿名プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<http://www.rfc-editor.org/ info / rfc7844>。
[SEC-DHCPv6] Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. Zhang, "Secure DHCPv6", Work in Progress, draft-ietf-dhc-sedhcpv6-21, February 2017.
[SEC-DHCPv6] Li、L.、Jiang、S.、Cui、Y.、Jinmei、T.、Lemon、T。、およびD. Zhang、「Secure DHCPv6」、Work in Progress、draft-ietf-dhc- sedhcpv6-21、2017年2月。
Acknowledgments
謝辞
The motivation for this document was several IESG DISCUSSes on recent DHCP relay agent options.
このドキュメントの動機は、最近のDHCPリレーエージェントオプションに関するいくつかのIESG DISCUSSでした。
Thanks to Kim Kinnear, Jinmei Tatuya, Francis Dupont, and Tomek Mrugalski for reviewing and helping to improve the document. Thanks to the authors of [RFC3315] for the original Section 21.1 text.
このドキュメントのレビューと改善にご協力いただいた、Kim Kinnear、Jinmei Tatuya、Francis Dupont、およびTomek Mrugalskiに感謝します。 [RFC3315]の作者に、元のセクション21.1のテキストをありがとう。
Authors' Addresses
著者のアドレス
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States of America
Bernie Volz Cisco Systems、Inc. 1414 Massachusetts Ave Boxborough、MA 01719アメリカ合衆国
Email: volz@cisco.com
Yogendra Pal Cisco Systems Cessna Business Park Varthur Hobli, Outer Ring Road Bangalore, Karnataka 560103 India
Yogendra Pal Cisco Systems Sasna Business Park Varthur Hobli、Outer Ring Road Bangalore、Karnatakaインド
Email: yogpal@cisco.com