[要約] RFC 4994は、DHCPv6リレーエージェントエコーリクエストオプションに関する仕様です。このRFCの目的は、DHCPv6リレーエージェントがエコーリクエストを送信し、サーバーの可用性を確認するためのオプションを提供することです。

Network Working Group                                            S. Zeng
Request for Comments: 4994                                       B. Volz
Category: Standards Track                                     K. Kinnear
                                                     Cisco Systems, Inc.
                                                           J. Brzozowski
                                                           Comcast Cable
                                                          September 2007
        

DHCPv6 Relay Agent Echo Request Option

DHCPV6リレーエージェントエコーリクエストオプション

Status of This Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Abstract

概要

This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent.

このメモは、IPv6(DHCPV6)の動的ホスト構成プロトコルのリレーエージェントエコーリクエストオプションを定義します。このオプションにより、DHCPV6リレーエージェントは、サーバーがリレーエージェントにエコーするリレーエージェントオプションのリストを要求できます。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Requirements Terminology ........................................2
   3. The Relay Agent Echo Request Option .............................2
   4. DHCPv6 Relay Agent Behavior .....................................3
   5. DHCPv6 Server Behavior ..........................................3
   6. Security Considerations .........................................4
   7. IANA Considerations .............................................4
   8. Acknowledgements ................................................4
   9. References ......................................................4
      9.1. Normative References .......................................4
      9.2. Informative References .....................................4
        
1. Introduction
1. はじめに

DHCPv6 [2] provides a framework for configuring IPv6 clients with addresses and other network parameters. It includes a relay agent capability. A relay agent is an intermediary node that delivers DHCP messages between clients and servers. The relay agent and the server exchange information using options in relay agent messages. The relay agent may add relay agent options to the client DHCP message before forwarding it.

DHCPV6 [2]は、アドレスやその他のネットワークパラメーターを使用してIPv6クライアントを構成するためのフレームワークを提供します。リレーエージェント機能が含まれています。リレーエージェントは、クライアントとサーバー間でDHCPメッセージを配信する中間ノードです。リレーエージェントとサーバーは、リレーエージェントメッセージのオプションを使用して情報を交換します。リレーエージェントは、リレーエージェントオプションをクライアントDHCPメッセージに転送する前に追加する場合があります。

The information that relay agents supply can be used in the server's decision making about the addresses, delegated prefixes, and configuration parameters that the client is to receive. Likewise, the relay may need some of the information to efficiently return replies to clients.

リレーエージェントが提供する情報は、クライアントが受信するアドレス、委任されたプレフィックス、および構成パラメーターに関するサーバーの意思決定で使用できます。同様に、リレーには、クライアントへの返信を効率的に返すための情報の一部が必要になる場合があります。

In DHCPv4, the server generally echoes the relay agent option back verbatim to the relay agent in server-to-client replies [3]. However, DHCPv6 [2] does not require the server to do so. This could be problematic, as the relay agent may need to use some relay options even if the server does not recognize them.

DHCPV4では、サーバーは通常、サーバーからクライアントの応答でリレーエージェントにリレーエージェントオプションをバックバックバックします[3]。ただし、DHCPV6 [2]では、サーバーにそうする必要はありません。リレーエージェントは、サーバーがそれらを認識していなくても、リレーオプションを使用する必要がある場合があるため、これは問題がある可能性があります。

This memo defines a relay agent echo request option that the relay agent uses to explicitly request a list of options that the server echoes back to the relay agent.

このメモは、リレーエージェントが使用するリレーエージェントエコーリクエストオプションを定義し、サーバーがリレーエージェントにエコーするオプションのリストを明示的に要求します。

2. Requirements Terminology
2. 要件用語

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 [1].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[1]に記載されているとおりに解釈される。

3. The Relay Agent Echo Request Option
3. リレーエージェントエコーリクエストオプション

The relay agent adds options in the Relay Forward message that the server uses to guide its decision making with regard to address assignment, prefix delegation, and configuration parameters. The relay agent also knows which of these options that it will need to efficiently return replies to the client. It uses the relay agent Echo Request option to inform the server of the list of relay agent options that the server must echo back.

リレーエージェントは、アドレスの割り当て、プレフィックス委任、および構成パラメーターに関して、サーバーが意思決定をガイドするために使用するリレーフォワードメッセージにオプションを追加します。リレーエージェントは、クライアントへの返信を効率的に返すために必要なこれらのオプションのどれを知っています。リレーエージェントエコーリクエストオプションを使用して、サーバーがエコーしなければならないリレーエージェントオプションのリストをサーバーに通知します。

The format of the DHCPv6 Relay Agent Echo Request option is shown below:

DHCPV6リレーエージェントエコーリクエストオプションの形式を以下に示します。

    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_ERO          |           option-len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    requested-option-code-1    |    requested-option-code-2    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
   option-code              OPTION_ERO (43).
   option-len               2 * number of requested options.
   requested-option-code-n  The option code for an option requested by
                            the relay agent.
        
4. DHCPv6 Relay Agent Behavior
4. DHCPV6リレーエージェントの動作

A relay agent MAY include an Echo Request option in a Relay Forward message to inform the server about options the relay agent wants the server to echo back to the relay agent. If the relay agent takes different actions based on whether an option is echoed back or not, then the relay agent SHOULD NOT include such an option in the Echo Request option. Note that the relay uses the OPTION_ORO [2] to request the server to return options (e.g., [4]) other than relay agent options in the Relay Forward message.

リレーエージェントには、リレーフォワードメッセージにエコーリクエストオプションを含めることができ、リレーエージェントがサーバーにリレーエージェントにエコーしたいオプションについてサーバーに通知することができます。リレーエージェントがオプションが後ろにエコーされるかどうかに基づいて異なるアクションを実行する場合、リレーエージェントはEcho要求オプションにそのようなオプションを含めるべきではありません。リレーはOption_oro [2]を使用して、リレーフォワードメッセージのリレーエージェントオプション以外のオプション([4]など)を返すようにサーバーに要求することに注意してください。

5. DHCPv6 Server Behavior
5. DHCPV6サーバーの動作

When a server creates a Relay-Reply, it SHOULD perform ERO processing after processing the ORO and other options processing. For each option in the ERO:

サーバーがリレーのリレーを作成すると、OROおよびその他のオプション処理を処理した後、ERO処理を実行する必要があります。EROの各オプションについて:

a. If the option is already in the Relay-Reply, the server MUST ignore that option and continue to process any remaining options in the ERO.

a. オプションが既にリレーの範囲にある場合、サーバーはそのオプションを無視し、EROの残りのオプションを処理し続ける必要があります。

b. If the option was not in the received Relay-Forward, the server MUST ignore that option and continue to process any remaining options in the ERO.

b. オプションが受信したリレーフォワードにない場合、サーバーはそのオプションを無視し、EROの残りのオプションを処理し続ける必要があります。

c. Otherwise, the server MUST copy the option, verbatim, from the received Relay-Forward to the Relay-Reply, even if the server does not otherwise recognize that option.

c. それ以外の場合、サーバーがそのオプションを認識していなくても、サーバーは、受信したリレーから受信したリレーフォワードからリレーのオプションをコピーする必要があります。

6. Security Considerations
6. セキュリティに関する考慮事項

As the Echo Request option is only exchanged between relay agents and DHCPv6 servers, section 21.1 of [2] provides details on securing DHCPv6 messages sent between servers and relay agents. And, section 23 of [2] provides general DHCPv6 security considerations.

エコー要求オプションはリレーエージェントとDHCPV6サーバーの間でのみ交換されるため、[2]のセクション21.1は、サーバーとリレーエージェント間で送信されるDHCPV6メッセージのセキュリティに関する詳細を提供します。また、[2]のセクション23は、一般的なDHCPV6セキュリティに関する考慮事項を提供します。

7. IANA Considerations
7. IANAの考慮事項

IANA has assigned a DHCPv6 option code for the OPTION_ERO (Relay Agent Echo Request) Option (43).

IANAは、option_ero(リレーエージェントエコーリクエスト)オプションにDHCPV6オプションコードを割り当てました(43)。

8. Acknowledgements
8. 謝辞

Thanks to Ralph Droms, Josh Littlefield, Richard Johnson, and Hemant Singh for their consistent input, ideas, and review during the production of this document.

Ralph Droms、Josh Littlefield、Richard Johnson、Hemant Singhに、この文書の作成中に一貫したインプット、アイデア、レビューをしてくれたことに感謝します。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[2] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6(DHCPV6)の動的ホスト構成プロトコル」、RFC 3315、2003年7月。

[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.

[3] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。

9.2. Informative References
9.2. 参考引用

[4] Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", Work in Progress, November 2006.

[4] DROMS、R.、Volz、B。、およびO. Troan、「DHCPV6リレーエージェント割り当て通知(RAAN)オプション」、2006年11月、Work in Progress。

Authors' Addresses

著者のアドレス

Shengyou Zeng Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA

Shengyou Zeng Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719 USA

   Phone: +1 978 936 0000
   EMail: szeng@cisco.com
        

Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA

Bernard Volz Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719 USA

   Phone: +1 978 936 0000
   EMail: volz@cisco.com
        

Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA

Kim Kinnear Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719 USA

   Phone: +1 978 936 0000
   EMail: kkinnear@cisco.com
        

John Jason Brzozowski Comcast Cable 1800 Bishops Gate Boulevard Mt. Laurel, NJ 08054 USA

ジョン・ジェイソン・ブルゾーゾフスキー・コムキャストケーブル1800司教ゲート・ブルバード・マタ

   Phone: +1 856 324 2671
   EMail: john_brzozowski@cable.comcast.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2007).

著作権(c)The IETF Trust(2007)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織(もしあれば)、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。