RFC 6334 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite 日本語訳

URL : https://tools.ietf.org/html/rfc6334
タイトル : RFC 6334 - IPv6の動的ホスト構成プロトコルデュアルスタックLiteの（DHCPv6の）オプション
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                        D. Hankins
Request for Comments: 6334                                        Google
Category: Standards Track                                   T. Mrugalski
ISSN: 2070-1721                          Gdansk University of Technology
                                                             August 2011

      Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option
                          for Dual-Stack Lite

Abstract

抽象

This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR).

このドキュメントは、それに対応するアドレスファミリ移行ルータ（AFTR）のIPv6アドレスを発見するためにデュアルスタックLiteの基本的なブリッジングブロードバンド（B4）の要素によって使用されることを意味しているのDHCPv6オプションを指定します。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

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）の製品です。これは、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/rfc6334.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6334で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................2
   2. Requirements Language ...........................................2
   3. The AFTR-Name DHCPv6 Option .....................................2
   4. DHCPv6 Server Behavior ..........................................4
   5. DHCPv6 Client Behavior ..........................................4
   6. Security Considerations .........................................5
   7. IANA Considerations .............................................6
   8. Acknowledgements ................................................6
   9. Normative References ............................................6

1. Introduction

1. はじめに

Dual-Stack Lite [RFC6333] is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix (no IPv4 address is assigned to the attachment device). One of its key components is an IPv4-over-IPv6 tunnel, commonly referred to as a softwire. A DS-Lite "Basic Bridging BroadBand" (B4) device will not know if the network it is attached to offers Dual-Stack Lite service, and if it did would not know the remote endpoint of the tunnel to establish a softwire.

デュアルスタックライト[RFC6333]は唯一のIPv6プレフィックス（無IPv4アドレスが取り付け装置に割り当てられていない）を用いてアドレス指定される顧客にIPv4とIPv6接続の両方を提供するソリューションです。その主要な構成要素の一つは、一般softwireと呼ばれるIPv4のオーバーのIPv6トンネルです。それはsoftwireを確立するために、トンネルのリモートエンドポイントを知ることはできませんでした場合はDS-Liteの「基本的なブリッジングブロードバンド」（B4）デバイスは、それが接続されているネットワークは、デュアルスタックLiteのサービスを提供していますかどうかを知り、そしてません。

To inform the B4 of the Address Family Transition Router's (AFTR) location, a DNS [RFC1035] hostname may be used. Once this information is conveyed, the presence of the configuration indicating the AFTR's location also informs a host to initiate Dual-Stack Lite (DS-Lite) service and become a softwire initiator.

アドレスファミリ移行ルータの（AFTR）場所のB4に通知するために、DNS [RFC1035]ホスト名を使用することができます。この情報が搬送されると、AFTRの位置を示す構成の存在はまた、デュアルスタックライト（DS-Liteの）サービスを開始し、softwire開始剤になることをホストに通知します。

To provide the conveyance of the configuration information, a single DHCPv6 [RFC3315] option is used, expressing the AFTR's Fully Qualified Domain Name (FQDN) to the B4 element.

設定情報の搬送を提供するために、単一のDHCPv6 [RFC3315]オプションはB4要素にAFTRの完全修飾ドメイン名（FQDN）を発現する、使用されています。

The details of how the B4 establishes an IPv4-in-IPv6 softwire to the AFTR are out of scope for this document.

B4がAFTRへのIPv4-IPv6の中-softwireを確立する方法の詳細は、このドキュメントの範囲外です。

2. Requirements Language

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 RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

3. The AFTR-Name DHCPv6 Option

3. AFTR-名前DHCPv6のオプション

The AFTR-Name option consists of option-code and option-len fields (as all DHCPv6 options have), and a variable-length tunnel-endpoint-name field containing a fully qualified domain name that refers to the AFTR to which the client MAY connect.

（すべてのDHCPv6オプションを持っているように）AFTR-nameオプションは、オプションコードとオプションLENフィールドで構成され、可変長トンネルエンドポイント名フィールドには、へAFTRを指す完全修飾ドメイン名を含むクライアントMAY接続します。

The AFTR-Name option SHOULD NOT appear in any DHCPv6 messages other than the following: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.

AFTR-nameオプションには、次の以外の任意のDHCPv6メッセージに表示されません：、勧誘広告、リクエスト、更新、再バインド、情報リクエスト、および返信。

The format of the AFTR-Name option is shown in the following figure:

AFTR-nameオプションの形式は、次の図に示します。

      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_AFTR_NAME: 64       |          option-len           |
     +-------------------------------+-------------------------------+
     |                                                               |
     |                  tunnel-endpoint-name (FQDN)                  |
     |                                                               |
     +---------------------------------------------------------------+

OPTION_AFTR_NAME: 64

OPTION_AFTR_NAME：64

               option-len: Length of the tunnel-endpoint-name field in
                           octets.

tunnel-endpoint-name: A fully qualified domain name of the AFTR tunnel endpoint.

トンネルのエンドポイント名：AFTRトンネルエンドポイントの完全修飾ドメイン名。

Figure 1: AFTR-Name DHCPv6 Option Format

図1：AFTR-名前のDHCPv6オプションフォーマット

The tunnel-endpoint-name field is formatted as required in DHCPv6 [RFC3315] Section 8 ("Representation and Use of Domain Names"). Briefly, the format described is using a single octet noting the length of one DNS label (limited to at most 63 octets), followed by the label contents. This repeats until all labels in the FQDN are exhausted, including a terminating zero-length label. Any updates to Section 8 of DHCPv6 [RFC3315] also apply to encoding of this field. An example format for this option is shown in Figure 2, which conveys the FQDN "aftr.example.com.".

トンネルエンドポイント名フィールドは必須のDHCPv6に[RFC3315]セクション8（「ドメイン名の表現と使用」）としてフォーマットされます。簡潔には、1つのDNSラベルの長さを指摘単一のオクテットを使用して説明した形式は、ラベルの内容、続いて、（最大で63個のオクテットに限定されるもの）。 FQDNですべてのラベルが終了する長さゼロのラベルを含め、排出されるまで、これが繰り返されます。 DHCPv6の[RFC3315]のセクション8への更新も、このフィールドの符号化に適用されます。このオプションのフォーマット例は、FQDN搬送する図2に示されている「aftr.example.comを」。

      +------+------+------+------+------+------+------+------+------+
      | 0x04 |   a  |   f  |   t  |   r  | 0x07 |   e  |   x  |   a  |
      +------+------+------+------+------+------+------+------+------+
      |   m  |   p  |   l  |   e  | 0x03 |   c  |   o  |   m  | 0x00 |
      +------+------+------+------+------+------+------+------+------+

Figure 2: Example tunnel-endpoint-name

図2：例のトンネルエンドポイント名

Note that in the specific case of the example tunnel-endpoint-name (Figure 2), the length of the tunnel-endpoint-name is 18 octets, and so an option-len field value of 18 would be used.

例えば、トンネルエンドポイント名の特定の場合においてなお（図2）は、トンネルエンドポイントの名前の長さは18オクテットであるので18のオプションLENフィールドの値が使用されるであろう。

The option is validated by confirming that all of the following conditions are met:

オプションは、次のすべての条件が満たされていることを確認することで検証されています。

1. the option-len is greater than 3;

1.オプション-lenが3よりも大きいです。

2. the option-len is less than or equal to the remaining number of octets in the DHCPv6 packet;

2.オプション-lenはDHCPv6のパケットのオクテットの残りの数以下です。

3. the individual label lengths do not exceed the option length;

3.個々のラベルの長さは、オプションの長さを超えないようにしてください。

4. the tunnel-endpoint-name is of valid format as described in DHCPv6 Section 8 [RFC3315];

DHCPv6のセクション8 [RFC3315]で説明されるように前記トンネルエンドポイント名は、有効なフォーマットです。

5. there are no compression tags;

5.非圧縮タグはありません。

6. there is at least one label of nonzero length.

前記ゼロでない長さの少なくとも一方のラベルがあります。

4. DHCPv6 Server Behavior

4. DHCPv6のサーバーの動作

A DHCPv6 server SHOULD NOT send more than one AFTR-Name option. It SHOULD NOT permit the configuration of multiple names within one AFTR-Name option. Both of these conditions are handled as exceptions by the client, so an operator using software that does not perform these validations should be careful not to configure multiple domain names.

DHCPv6サーバは、複数のAFTR-nameオプションを送るべきではありません。これは、1つAFTR-nameオプション内の複数の名前の設定を可能とすべきではありません。これらの条件の両方がクライアントによって例外として扱われるので、これらの検証を行っていないソフトウェアを使用して、オペレータは、複数のドメイン名を設定しないように注意する必要があります。

RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and server negotiate configuration values using the Option Request option (OPTION_ORO). As a convenience to the reader, we mention here that a server will not reply with an AFTR-Name option if the client has not explicitly enumerated it on its Option Request option.

RFC 3315のセクション17.2.2 [RFC3315]はDHCPv6クライアントとサーバがオプション要求オプション（OPTION_ORO）を使用して、設定値を交渉する方法を説明します。読者の便宜のために、私たちは、クライアントが明示的にオプション要求オプションでそれを列挙していない場合、サーバーはAFTR-nameオプションを使用して返信しないことをここで言及します。

5. DHCPv6 Client Behavior

5. DHCPv6のクライアントの動作

A client that supports the B4 functionality of DS-Lite (defined in [RFC6333]) and conforms to this specification MUST include OPTION_AFTR_NAME on its OPTION_ORO.

（[RFC6333]で定義された）DS-LiteののB4の機能をサポートし、この仕様に準拠したクライアントは、そのOPTION_OROにOPTION_AFTR_NAMEを含まなければなりません。

Because it requires a DNS name for address resolution, the client MAY also wish to include the OPTION_DNS_SERVERS [RFC3646] option on its OPTION_ORO.

それはアドレス解決のためのDNS名を必要とするため、クライアントはそのOPTION_OROにOPTION_DNS_SERVERS [RFC3646]のオプションを含めることを望むかもしれません。

If the client receives the AFTR-Name option, it MUST verify the option contents as described in Section 3.

クライアントがAFTR-nameオプションを受信した場合は第3節で説明したように、それはオプションの内容を確かめなければなりません。

Note that in different environments, the B4 element and DHCPv6 client may be integrated, joined, or separated by a third piece of software. For the purpose of this specification, we refer to the "B4 system" when specifying implementation steps that may be processed at any stage of integration between the DHCPv6 client software and the B4 element it is configuring.

異なる環境で、B4要素とDHCPv6クライアントが統合されてもよいことに留意されたい、接合、またはソフトウェアの第三の部分によって分離されます。 DHCPv6クライアントソフトウェアとそれが設定されたB4要素間の統合のいずれかの段階で処理することができる実装手順を指定するときは、この明細書の目的のために、私たちは「B4システム」を参照してください。

If the B4 system receives more than one AFTR-Name option, it MUST use only the first instance of that option.

B4システムは、複数のAFTR-nameオプションを受信した場合、そのオプションの最初のインスタンスのみを使用しなければなりません。

If the AFTR-Name option contains more than one FQDN, as distinguished by the presence of multiple root labels, the B4 system MUST use only the first FQDN listed in the configuration.

AFTR-nameオプションは、複数のFQDNが含まれている場合は、複数のルートのラベルの存在によって区別されるよう、B4システムは、最初のFQDNが、構成に記載されている使用しなければなりません。

The B4 system performs standard DNS resolution using the provided FQDN to resolve a AAAA Resource Record, as defined in [RFC3596] and STD 13 ([RFC1034], [RFC1035]).

B4システムは、標準的な[RFC3596]で定義されるようにAAAAリソースレコードを解決するために設けられたFQDNを用いてDNS解決、およびSTD 13（[RFC1034]、[RFC1035]）を行います。

If any DNS response contains more than one IPv6 address, the B4 system picks only one IPv6 address and uses it as a remote tunnel endpoint for the interface being configured in the current message exchange. The B4 system MUST NOT establish more than one DS-Lite tunnel at the same time per interface. For a redundancy and high-availability discussion, see Appendix A.3 ("High Availability") of [RFC6333].

任意のDNS応答が複数のIPv6アドレスが含まれている場合、B4システムは、1つのIPv6アドレスを選び、インターフェイス用のリモートトンネルエンドポイントは、現在のメッセージ交換に構成されているようにそれを使用します。 B4システムは、インターフェイスごとに同時に複数のDS-Liteのトンネルを確立してはなりません。冗長性と高可用性については、[RFC6333]の付録A.3（「高可用性」を参照してください）。

Note that a B4 system may have multiple network interfaces, and these interfaces may be configured differently; some may be connected to networks that call for DS-Lite, and some may be connected to networks that are using normal dual stack or other means. The B4 system should approach this specification on an interface-by-interface basis. For example, if the B4 system is attached to multiple networks that provide the AFTR-Name option, then the B4 system MUST configure a tunnel for each interface separately, as each DS-Lite tunnel provides IPv4 connectivity for each distinct interface. Means to bind an AFTR-Name and DS-Lite tunnel configuration to a given interface in a multiple-interface device are out of scope of this document.

B4システムは複数のネットワークインタフェースを有していてもよく、これらのインタフェースは、異なって構成されてもよいことに留意されたいです。いくつかは、DS-Liteのために呼び出すネットワークに接続することができ、そしていくつかは、通常のデュアルスタックまたは他の手段を使用しているネットワークに接続することができます。 B4システムは、インターフェイスごとに、本明細書に近づくべきです。 B4システムはAFTR-nameオプションを提供する複数のネットワークに接続されている場合、各DS-Liteのトンネルはそれぞれ別個のインターフェイスのIPv4接続を提供するように、例えば、その後B4システムは、個別に各インターフェイスのためのトンネルを設定する必要があります。この文書の範囲外である複数のインターフェース装置に与えられたインターフェイスにAFTR名およびDS-Liteのトンネル設定を結合することを意味します。

6. Security Considerations

6.セキュリティの考慮事項

This document does not present any new security issues, but as with all DHCPv6-derived configuration state, it is completely possible that the configuration is being delivered by a third party (Man in the Middle). As such, there is no basis for trusting the access level represented by the DS-Lite softwire connection, and DS-Lite should therefore not bypass any security mechanisms such as IP firewalls.

このドキュメントは、どんな新しいセキュリティ問題を提示していないが、すべてのDHCPv6由来の構成状態と同じように、設定が第三者（中間者）によって配信されていることは完全に可能です。このように、DS-ライトsoftwire接続で表されるアクセスレベルを信頼するための根拠が存在しない、およびDS-Liteは、したがって、このようなIPファイアウォールのような任意のセキュリティメカニズムをバイパスしてはなりません。

[RFC3315] discusses DHCPv6-related security issues.

[RFC3315]はDHCPv6の関連のセキュリティ問題について説明します。

[RFC6333] discusses DS-Lite-related security issues.

[RFC6333]はDS-Liteの関連のセキュリティ問題について説明します。

7. IANA Considerations

7. IANAの考慮事項

IANA has allocated a single DHCPv6 option code, 64, referencing this document, delineating OPTION_AFTR_NAME.

IANAはOPTION_AFTR_NAMEの輪郭を描く、この文書を参照する、単一のDHCPv6オプションコード、64を割り当てています。

8. Acknowledgements

8.謝辞

The authors would like to thank Alain Durand, Rob Austein, Dave Thaler, Paul Selkirk, Ralph Droms, Mohamed Boucadair, Roberta Maglione, and Shawn Routhier for their valuable feedback and suggestions. The authors acknowledge significant support for this work, provided by Internet Systems Consortium, Inc.

著者は、彼らの貴重なフィードバックや提案のためにアラン・デュラン、ロブAusteinと、デーブターラー、ポール・セルカーク、ラルフDroms、モハメドBoucadair、ロベルタマリオーネ、そしてショーンRouthierに感謝したいと思います。著者は、インターネットシステムコンソーシアム株式会社が提供する、この作業のための重要なサポートを認めます

This work has been partially supported by the Polish Ministry of Science and Higher Education under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future Internet Engineering Project).

この作品は、部分的に欧州地域開発基金、認可番号POIG.01.01.02-00-045 / 09-00（今後のインターネット・エンジニアリング・プロジェクト）の下でポーランド科学省高等教育によって支えられてきました。

9. Normative References

9.引用規格

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。

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

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[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.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.

[RFC3596]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。

[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.

[RFC3646] Droms、R.、エド。、RFC 3646、2003年12月、 "IPv6の動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.

[RFC6333]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "IPv4の枯渇後デュアルスタックLiteのブロードバンドの展開"、RFC 6333、2011年8月。

Authors' Addresses

著者のアドレス

David W. Hankins Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA

デビッドW.ハンキンズグーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043 USA

EMail: dhankins@google.com

メールアドレス：dhankins@google.com

Tomasz Mrugalski Gdansk University of Technology ul. Storczykowa 22B/12 Gdansk 80-177 Poland

技術ULのトーマスMrugalskiグダニスク大学。オーキッド22B / 12 80から177グダニスクポーランド

Phone: +48 698 088 272 EMail: tomasz.mrugalski@eti.pg.gda.pl

電話：+48 698 088 272 Eメール：tomasz.mrugalski@eti.pg.gda.pl