RFC3633 日本語訳
3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol(DHCP) version 6. O. Troan, R. Droms. December 2003. (Format: TXT=45308 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group O. Troan
Request for Comments: 3633 R. Droms
Category: Standards Track Cisco Systems
December 2003
Troanがコメントのために要求するワーキンググループO.をネットワークでつないでください: 3633年のR.Dromsカテゴリ: 標準化過程シスコシステムズ2003年12月
IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6
Dynamic Host Configuration Protocol(DHCP)バージョン6のためのIPv6 Prefix Options
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.
Prefix Delegationオプションは、Dynamic Host Configuration Protocol(DHCP)を使用することでIPv6接頭語の自動化された代表団にメカニズムを提供します。 このメカニズムは代表として派遣するルータから要求ルータまで長い送られた接頭語を代表として派遣するために意図します、管理境界の向こう側に代表として派遣するルータが接頭語が配属されるネットワークでリンクのトポロジーに関する知識が必要でない。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DHCPv6 specification dependency . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Model and Applicability . . . . . . . . . . . . . . . . . . 3
5.1. Example network architecture . . . . . . . . . . . . . 4
6. Identity Association for Prefix Delegation . . . . . . . . . 5
7. Overview of DHCP with Prefix Delegation . . . . . . . . . . 6
8. Interface Selection . . . . . . . . . . . . . . . . . . . . 7
9. Identity Association for Prefix Delegation Option . . . . . 7
10. IA_PD Prefix option . . . . . . . . . . . . . . . . . . . . 9
11. Delegating Router Solicitation . . . . . . . . . . . . . . . 11
11.1. Requesting router behavior . . . . . . . . . . . . . . 11
11.2. Delegating router behavior . . . . . . . . . . . . . . 11
12. Requesting router initiated prefix delegation . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 DHCPv6仕様依存. . . . . . . . . . . . . . 3 3。 用語. . . . . . . . . . . . . . . . . . . . . . . . 3 4。 要件. . . . . . . . . . . . . . . . . . . . . . . . 3 5。 モデルと適用性. . . . . . . . . . . . . . . . . . 3 5.1。 例のネットワークアーキテクチャ. . . . . . . . . . . . . 4 6。 接頭語代表団. . . . . . . . . 5 7のためのアイデンティティ協会。 接頭語代表団. . . . . . . . . . 6 8があるDHCPの概観。 選択. . . . . . . . . . . . . . . . . . . . 7 9を連結してください。 接頭語代表団オプション. . . . . 7 10のためのアイデンティティ協会。 アイオワ_PD Prefixオプション. . . . . . . . . . . . . . . . . . . . 9 11。 ルータ懇願. . . . . . . . . . . . . . . 11 11.1を代表として派遣します。 ルータ振舞い. . . . . . . . . . . . . . 11 11.2を要求します。 ルータ振舞い. . . . . . . . . . . . . . 11 12を代表として派遣します。 ルータの開始している接頭語代表団. . . . . . . 12を要求します。
Troan & Droms Standards Track [Page 1] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[1ページ]RFC3633IPv6接頭語オプション
12.1. Requesting router behavior . . . . . . . . . . . . . . 12
12.2. Delegating Router behavior . . . . . . . . . . . . . . 14
13. Prefix Delegation reconfiguration . . . . . . . . . . . . . 15
13.1. Delegating Router behavior . . . . . . . . . . . . . . 15
13.2. Requesting Router behavior . . . . . . . . . . . . . . 15
14. Relay agent behavior . . . . . . . . . . . . . . . . . . . . 15
15. Security Considerations . . . . . . . . . . . . . . . . . . 16
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
17. Intellectual Property Statement. . . . . . . . . . . . . . . 17
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
18.1. Normative References . . . . . . . . . . . . . . . . . 17
18.2. Informative References . . . . . . . . . . . . . . . . 17
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
20. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
21. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
12.1. ルータ振舞い. . . . . . . . . . . . . . 12 12.2を要求します。 Router振舞い. . . . . . . . . . . . . . 14 13を代表として派遣します。 Delegation再構成. . . . . . . . . . . . . 15 13.1を前に置いてください。 Router振舞い. . . . . . . . . . . . . . 15 13.2を代表として派遣します。 Router振舞い. . . . . . . . . . . . . . 15 14を要求します。 エージェント振舞い. . . . . . . . . . . . . . . . . . . . 15 15をリレーしてください。 セキュリティ問題. . . . . . . . . . . . . . . . . . 16 16。 IANA問題. . . . . . . . . . . . . . . . . . . . 16 17。 知的所有権声明。 . . . . . . . . . . . . . . 17 18. 参照. . . . . . . . . . . . . . . . . . . . . . . . . 17 18.1。 引用規格. . . . . . . . . . . . . . . . . 17 18.2。 有益な参照. . . . . . . . . . . . . . . . 17 19。 承認. . . . . . . . . . . . . . . . . . . . . . 18 20。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 18 21。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
This document describes new options for Dynamic Host Configuration Protocol (DHCP) that provide a mechanism for the delegation of IPv6 prefixes [1]. Through these options, a delegating router can delegate prefixes to authorized requesting routers.
このドキュメントはDynamic Host Configuration Protocol(DHCP)のためのIPv6接頭語[1]の代表団にメカニズムを提供する新しいオプションについて説明します。 これらのオプションで、代表として派遣するルータは認可された要求ルータへ接頭語を代表として派遣することができます。
The prefix delegation mechanism described in this document is intended for simple delegation of prefixes from a delegating router to requesting routers. It is appropriate for situations in which the delegating router does not have knowledge about the topology of the networks to which the requesting router is attached, and the delegating router does not require other information aside from the identity of the requesting router to choose a prefix for delegation. For example, these options would be used by a service provider to assign a prefix to a Customer Premise Equipment (CPE) device acting as a router between the subscriber's internal network and the service provider's core network.
本書では説明された接頭語代表団メカニズムは接頭語の簡単な代表団のために代表として派遣するルータからルータを要求するまで意図します。 代表として派遣するルータは要求ルータが付けているネットワークのトポロジーに関して心得がない状況に、それが適切です、そして、要求ルータのアイデンティティは別として、代表として派遣するルータは代表団のための接頭語を選ぶために他の情報を必要としません。 例えば、これらのオプションは、加入者の内部のネットワークとサービスプロバイダーのコアネットワークの間のルータとして作動するCustomer Premise Equipment(CPE)装置に接頭語を割り当てるのにサービスプロバイダーによって使用されるでしょう。
Many applications expect stable addresses. Even though this mechanism makes automatic renumbering easier, it is expected that prefixes have a long lifespan. During renumbering it is expected that the old and the new prefix co-exist for some time.
多くのアプリケーションが安定したアドレスを予想します。 自動番号を付け替えるのはこのメカニズムで、より簡単になりますが、接頭語には長い寿命があると予想されます。 番号を付け替えている間、古い接頭語と新しい接頭語がしばらく共存すると予想されます。
The design of this prefix delegation mechanism meets the requirements for prefix delegation in Requirements for IPv6 prefix delegation [6].
この接頭語代表団メカニズムのデザインは接頭語代表団のためにIPv6接頭語代表団[6]のためのRequirementsで条件を満たします。
Note that this use of DHCP is not bound to the assignment of IP addresses or other configuration information to hosts, and that no mechanism is currently available to communicate delegated prefixes to a DHCP server that serves such a function. This may be an item of future work, should usage warrant.
DHCPのこの使用がホストへのIPアドレスか他の設定情報の課題に縛られないで、またどんなメカニズムも現在そのような機能を果たすDHCPサーバに代表として派遣された接頭語を伝えるために利用可能でないことに注意してください。 用法は、これが今後の活動の項目であるかもしれないことを保証するべきですか?
Troan & Droms Standards Track [Page 2] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[2ページ]RFC3633IPv6接頭語オプション
2. DHCPv6 specification dependency
2. DHCPv6仕様の依存
This document describes new DHCPv6 options for IPv6 prefix delegation. This document should be read in conjunction with the DHCPv6 specification, RFC 3315 [2], for a complete specification of the Prefix Delegation options and mechanism. Definitions for terms and acronyms not specifically defined in this document are defined in RFC 3315.
このドキュメントはIPv6接頭語代表団のために新しいDHCPv6オプションについて説明します。 このドキュメントはDHCPv6仕様、Prefix Delegationオプションとメカニズムの完全な仕様のためのRFC3315[2]に関連して読まれるべきです。 明確に定義されなかった用語と頭文字語のための定義はRFC3315で本書では定義されます。
3. Terminology
3. 用語
This document uses the terminology defined in RFC 2460 [1] and RFC 3315. In addition, this document uses the following terms:
このドキュメントはRFC2460[1]とRFC3315で定義された用語を使用します。 さらに、このドキュメントは次の用語を使用します:
requesting router: The router that acts as a DHCP client and is
requesting prefix(es) to be assigned.
ルータを要求します: DHCPクライアントとして機能して、割り当てられるよう接頭語(es)に要求しているルータ。
delegating router: The router that acts as a DHCP server, and is
responding to the prefix request.
ルータを代表として派遣します: DHCPサーバとして機能して、接頭語要求に応じているルータ。
Identity Association for Prefix Delegation (IA_PD): A collection of
prefixes assigned to the requesting router. Each
IA_PD has an associated IAID. A requesting
router may have more than one IA_PD assigned to
it; for example, one for each of its interfaces.
接頭語代表団(アイオワ_PD)のためのアイデンティティ協会: 要求ルータに割り当てられた接頭語の収集。 各アイオワ_PDには、関連IAIDがあります。 要求ルータで、1アイオワ_PDをそれに割り当てるかもしれません。 例えば、それぞれのインタフェースへの1。
4. Requirements
4. 要件
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [3].
キーワードが解釈しなければならない、本書では現れるとき、BCP14(RFC2119[3])で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりません。
5. Model and Applicability
5. モデルと適用性
The model of operation for prefix delegation is as follows. A delegating router is provided IPv6 prefixes to be delegated to requesting routers. Examples of ways in which the delegating router may be provided these prefixes are given in Section 12.2. A requesting router requests prefix(es) from the delegating router, as described in Section 12.1. The delegating router chooses prefix(es) for delegation, and responds with prefix(es) to the requesting router. The requesting router is then responsible for the delegated prefix(es). For example, the requesting router might assign a subnet from a delegated prefix to one of its interfaces, and begin sending router advertisements for the prefix on that link.
接頭語代表団のための操作のモデルは以下の通りです。 ルータを要求しながら委任されるためにIPv6接頭語を代表として派遣するルータに提供します。 これらの接頭語が代表として派遣するルータに提供されるかもしれない方法に関する例はセクション12.2で出されます。 要求ルータはセクション12.1で説明されるように代表として派遣するルータから接頭語(es)を要求します。 代表として派遣するルータは、接頭語(es)を代表団に選んで、接頭語(es)で要求ルータに応じます。 要求ルータはその時、代表として派遣された接頭語(es)に原因となります。 例えば、要求ルータは、代表として派遣された接頭語からインタフェースの1つまでサブネットを割り当てて、そのリンクの上の接頭語のためにルータ通知を送り始めるかもしれません。
Troan & Droms Standards Track [Page 3] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[3ページ]RFC3633IPv6接頭語オプション
Each prefix has an associated valid and preferred lifetime, which constitutes an agreement about the length of time over which the requesting router is allowed to use the prefix. A requesting router can request an extension of the lifetimes on a delegated prefix and is required to terminate the use of a delegated prefix if the valid lifetime of the prefix expires.
各接頭語には、関連有効で都合のよい寿命があります。(それは、要求ルータが接頭語を使用できるタイム・オーバーの長さに関する協定を成立させます)。 要求ルータが、代表として派遣された接頭語における生涯の拡大を要求できて、接頭語の有効な寿命が期限が切れるなら、代表として派遣された接頭語の使用を終えるのに必要です。
This prefix delegation mechanism would be appropriate for use by an ISP to delegate a prefix to a subscriber, where the delegated prefix would possibly be subnetted and assigned to the links within the subscriber's network.
この接頭語代表団メカニズムはISPによる使用が加入者への接頭語を代表として派遣するのが、適切でしょう。(そこでは、代表として派遣された接頭語は、ことによると加入者のネットワークの中でリンクに「副-網で覆」われて、割り当てられるでしょう)。
5.1. Example network architecture
5.1. 例のネットワークアーキテクチャ
Figure 1 illustrates a network architecture in which prefix delegation could be used.
図1は接頭語代表団を使用できたネットワークアーキテクチャを例証します。
______________________ \
/ \ \
| ISP core network | \
\__________ ___________/ |
| |
+-------+-------+ |
| Aggregation | | ISP
| device | | network
| (delegating | |
| router) | |
+-------+-------+ |
| /
|DSL to subscriber /
|premises /
|
+------+------+ \
| CPE | \
| (requesting | \
| router) | |
+----+---+----+ |
| | | Subscriber
---+-------------+-----+- -+-----+-------------+--- | network
| | | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+ |
|Subscriber| |Subscriber| |Subscriber| |Subscriber| /
| PC | | PC | | PC | | PC | /
+----------+ +----------+ +----------+ +----------+ /
______________________ \ / \ \ | ISPコアネットワーク| \ \__________ ___________/ | | | +-------+-------+ | | 集合| | ISP| 装置| | ネットワーク| (|代表として派遣します| | ルータ) | | +-------+-------+ | | / |加入者/へのDSL|構内/| +------+------+ \ | CPE| \ | (要求|\|ルータ) | | +----+---+----+ | | | | 加入者---+-------------+-----+- -+-----+-------------+--- | ネットワーク| | | | | +----+-----+ +-----+----+ +----+-----+ +-----+----+ | |加入者| |加入者| |加入者| |加入者| / | PC| | PC| | PC| | PC| / +----------+ +----------+ +----------+ +----------+ /
Figure 1: An example of prefix delegation.
図1: 接頭語代表団に関する例。
Troan & Droms Standards Track [Page 4] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[4ページ]RFC3633IPv6接頭語オプション
In this example, the delegating router is configured with a set of prefixes to be used for assignment to customers at the time of each customer's first connection to the ISP service. The prefix delegation process begins when the requesting router requests configuration information through DHCP. The DHCP messages from the requesting router are received by the delegating router in the aggregation device. When the delegating router receives the request, it selects an available prefix or prefixes for delegation to the requesting router. The delegating router then returns the prefix or prefixes to the requesting router.
この例では、代表として派遣するルータは1セットの接頭語によって構成されて、ISPサービスとの各顧客の最初の接続時点課題に顧客に使用されます。 要求ルータがDHCPを通して設定情報を要求するとき、接頭語代表団の過程は始まります。 代表として派遣するルータは集合装置に要求ルータからのDHCPメッセージを受け取ります。 代表として派遣するルータが要求を受け取るとき、それは代表団のために利用可能な接頭語か接頭語を要求ルータに選択します。 そして、代表として派遣するルータは接頭語か接頭語を要求ルータに返します。
The requesting router subnets the delegated prefix and assigns the longer prefixes to links in the subscriber's network. In a typical scenario based on the network shown in Figure 1, the requesting router subnets a single delegated /48 prefix into /64 prefixes and assigns one /64 prefix to each of the links in the subscriber network.
代表として派遣するのが前に置く要求しているルータサブネットと加入者のところのリンクへの、より長い接頭語がネットワークでつなぐ案配。 ネットワークに基づいた典型的なシナリオでは、図1、要求ルータでは、シングルが/48接頭語を/64接頭語へ代表として派遣して、加入者ネットワークでone /64接頭語をそれぞれのリンクに割り当てるのをサブネットに示します。
The prefix delegation options can be used in conjunction with other DHCP options carrying other configuration information to the requesting router. The requesting router may, in turn, then provide DHCP service to hosts attached to the internal network. For example, the requesting router may obtain the addresses of DNS and NTP servers from the ISP delegating router, and then pass that configuration information on to the subscriber hosts through a DHCP server in the requesting router.
要求ルータまで他の設定情報を運ぶ他のDHCPオプションに関連して接頭語代表団オプションを使用できます。 そして、要求ルータは順番に内部のネットワークに配属されるホストに対するサービスをDHCPに供給するかもしれません。 例えば、要求ルータは、ルータを代表として派遣するISPからDNSとNTPサーバのアドレスを得て、次に、要求ルータにおけるDHCPサーバを通して加入者ホストにその設定情報を移るかもしれません。
6. Identity Association for Prefix Delegation
6. 接頭語代表団のためのアイデンティティ協会
An IA_PD is a construct through which a delegating router and a requesting router can identify, group and manage a set of related IPv6 prefixes. Each IA_PD consists of an IAID and associated configuration information. An IA_PD for prefixes is the equivalent of an IA (described in RFC 3315) for addresses.
アイオワ_PDは代表として派遣するルータと要求ルータが1セットの関連するIPv6接頭語を特定して、分類して、対処できる構造物です。 各アイオワ_PDはIAIDと関連設定情報から成ります。 接頭語のためのアイオワ_PDはアドレスのためのアイオワ(RFC3315では、説明される)の同等物です。
An IA_PD is different from an IA, in that it does not need to be associated with exactly one interface. One IA_PD can be associated with the requesting router, with a set of interfaces or with exactly one interface. A requesting router must create at least one distinct IA_PD. It may associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to obtain a prefix for that interface from the delegating router.
アイオワ_PDはアイオワとちょうど1つのインタフェースに関連している必要はないという点において異なっています。 要求ルータ、1セットのインタフェースまたはまさに1つのインタフェースに1アイオワ_PDを関連づけることができます。 要求ルータは少なくとも1異なったアイオワ_PDを作成しなければなりません。 それは、異なったアイオワ_PDをそれぞれの川下のネットワーク・インターフェースに関連づけて、代表として派遣するルータから接頭語をそのインタフェースに得るのにそのアイオワ_PDを使用するかもしれません。
The IAID uniquely identifies the IA_PD and must be chosen to be unique among the IA_PD IAIDs on the requesting router. The IAID is chosen by the requesting router. For any given use of an IA_PD by the requesting router, the IAID for that IA_PD MUST be consistent across restarts of the requesting router. The requesting router may
要求ルータでIAIDを唯一アイオワ_PDを特定して、アイオワ_PD IAIDsの中で特有になるように選ばなければなりません。 IAIDは要求ルータによって選ばれています。 いずれに関してはも、要求ルータ、そのアイオワ_PD MUSTのためのIAIDによるアイオワ_PDの使用を考えて、要求ルータの再開の向こう側に一貫してください。 要求ルータはそうするかもしれません。
Troan & Droms Standards Track [Page 5] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[5ページ]RFC3633IPv6接頭語オプション
maintain consistency either by storing the IAID in non-volatile storage or by using an algorithm that will consistently produce the same IAID as long as the configuration of the requesting router has not changed. If the requesting router uses only one IAID, it can use a well-known value, e.g., zero.
要求ルータの構成が変化していない限り、非揮発性記憶装置にIAIDを格納するか、または一貫して同じIAIDを生産するアルゴリズムを使用することによって、一貫性を維持してください。 要求ルータが1IAIDだけを使用するなら、それは周知の値、例えばゼロを使用できます。
The configuration information in an IA_PD consists of one or more IPv6 prefixes along with the times T1 and T2 for the IA_PD. See section 9 for the representation of an IA_PD in a DHCP message.
アイオワ_PDの設定情報はアイオワ_PDのための回のT1とT2に伴う1つ以上のIPv6接頭語から成ります。 DHCPメッセージにおける、アイオワ_PDの表現に関してセクション9を見てください。
7. Overview of DHCP with Prefix Delegation
7. 接頭語代表団があるDHCPの概観
Prefix delegation with DHCP is independent of address assignment with DHCP. A requesting router can use DHCP for just prefix delegation or for prefix delegation along with address assignment and other configuration information.
DHCPがある接頭語代表団はDHCPとのアドレス課題から独立しています。 要求ルータはまさしく接頭語代表団か接頭語代表団にアドレス課題と他の設定情報と共にDHCPを使用できます。
A requesting router first creates an IA_PD and assigns it an IAID. The requesting router then transmits a Solicit message containing an IA_PD option describing the IA_PD. Delegating routers that can delegate prefixes to the IA_PD respond to the requesting router with an Advertise message.
要求ルータは、最初に、アイオワ_PDを作成して、IAIDをそれに割り当てます。 そして、要求ルータはアイオワ_PDについて説明するアイオワ_PDオプションを含むSolicitメッセージを送ります。 _接頭語をアイオワへ代表として派遣することができるルータを代表として派遣して、PDは広告で要求ルータにメッセージを反応させます。
The requesting router may include prefixes in the IA_PDs as a hint to the delegating router about specific prefixes for which the requesting router has a preference.
要求ルータはヒントとして要求ルータには優先がある特定の接頭語に関してアイオワ_PDsの接頭語を代表として派遣するルータに含むかもしれません。
When the requesting router has identified a delegating router, the requesting router uses a Request message to populate the IA_PDs with prefixes. The requesting router includes one or more IA_PD options in the Request message. The delegating router returns prefixes and other information about the IA_PDs to the requesting router in IA_PD options in a Reply message. The requesting router records the lifetimes for the delegated prefix(es) and uses the prefix(es) as described in the previous section.
要求ルータが代表として派遣するルータを特定したとき、要求ルータは接頭語でアイオワ_PDsに居住するRequestメッセージを使用します。 要求ルータはRequestメッセージにおける1つ以上のアイオワ_PDオプションを含んでいます。 代表として派遣するルータはReplyメッセージにおけるアイオワ_PDオプションにおける要求ルータにアイオワ_PDsの接頭語と他の情報を返します。 要求ルータは、代表として派遣された接頭語(es)のために生涯を記録して、前項で説明されるように接頭語(es)を使用します。
Before the valid lifetime on each delegated prefix expires, the requesting router includes the prefix in an IA_PD option sent in a Renew message to the delegating router. The delegating router responds by returning the prefix with updated lifetimes to the requesting router.
それぞれの代表として派遣された接頭語の有効な寿命が期限が切れる前に、要求ルータはRenewメッセージで代表として派遣するルータに送られたアイオワ_PDオプションに接頭語を含んでいます。 代表として派遣するルータは、要求ルータへの最終更新日生涯で接頭語を返すことによって、応じます。
Troan & Droms Standards Track [Page 6] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[6ページ]RFC3633IPv6接頭語オプション
8. Interface Selection
8. インタフェース選択
Delegated prefixes are not associated with a particular interface in the same way as addresses are for address assignment, and the rules described in section 16, "Client Source Address and Interface Selection" of RFC 3315 do not apply.
代表として派遣された接頭語はRFC3315の「クライアントソースアドレスとインタフェース選択」がアドレスがアドレス課題、およびセクション16で説明された規則のためのものであって適用されない同じように特定のインタフェースに関連づけられません。
When a requesting router sends a DHCP message, it SHOULD be sent on the interface associated with the upstream router (ISP network). The upstream interface is typically determined by configuration. This rule applies even in the case where a separate IA_PD is used for each downstream interface.
要求ルータが発信するとき、a DHCPは通信して、それはSHOULDです。上流ルータ(ISPネットワーク)に関連しているインタフェースでは、送ります。 上流のインタフェースは構成で通常断固としています。 この規則は別々のアイオワ_PDがそれぞれの川下のインタフェースに使用される場合でさえ適用されます。
When a requesting router sends a DHCP message directly to a delegating router using unicast (after receiving the Server Unicast option from that delegating router), the source address SHOULD be an address from the upstream interface and which is suitable for use by the delegating router in responding to the requesting router.
上流のインタフェースとどれがあるかからアドレスが代表として派遣するルータで要求ルータに応じる際に使用に適していたなら要求ルータがユニキャスト(ルータを代表として派遣しながらそれからServer Unicastオプションを受け取った後の)、ソースアドレスSHOULDを使用することで直接代表として派遣するルータにDHCPメッセージを送るとき。
9. Identity Association for Prefix Delegation Option
9. 接頭語代表団オプションのためのアイデンティティ協会
The IA_PD option is used to carry a prefix delegation identity association, the parameters associated with the IA_PD and the prefixes associated with it.
アイオワ_PDオプションは、接頭語代表団アイデンティティ協会、アイオワ_PDに関連しているパラメタ、およびそれに関連している接頭語を運ぶのに使用されます。
The format of the IA_PD option is:
アイオワ_PDオプションの形式は以下の通りです。
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_IA_PD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_PD-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _オプション_アイオワPD| オプション長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID(4つの八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2| アイオワ..オプション
option-code: OPTION_IA_PD (25)
オプションコード: _オプション_アイオワPD(25)
option-length: 12 + length of IA_PD-options field.
オプション長さ: 12 + PD-オプションがさばくアイオワ_の長さ。
Troan & Droms Standards Track [Page 7] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[7ページ]RFC3633IPv6接頭語オプション
IAID: The unique identifier for this IA_PD; the IAID must
be unique among the identifiers for all of this
requesting router's IA_PDs.
IAID: このアイオワ_PDに、ユニークな識別子。 IAIDは、ルータのアイオワ_PDsを要求しながら、このすべてのための識別子の中でユニークであるに違いありません。
T1: The time at which the requesting router should
contact the delegating router from which the
prefixes in the IA_PD were obtained to extend the
lifetimes of the prefixes delegated to the IA_PD;
T1 is a time duration relative to the current time
expressed in units of seconds.
T1: 要求ルータがアイオワ_PDの接頭語が接頭語の生涯を広げるために得られた代表として派遣するルータに連絡するべきである時はアイオワ_PDに委任しました。 T1はユニットの秒に言い表された現在の時間に比例した時間持続時間です。
T2: The time at which the requesting router should
contact any available delegating router to extend
the lifetimes of the prefixes assigned to the
IA_PD; T2 is a time duration relative to the
current time expressed in units of seconds.
T2: 要求ルータが接頭語の生涯を広げるためにどんな利用可能な代表として派遣するルータにも連絡するべきである時は_PDをアイオワに割り当てました。 T2はユニットの秒に言い表された現在の時間に比例した時間持続時間です。
IA_PD-options: Options associated with this IA_PD.
アイオワの_PD-オプション: オプションはこのアイオワ_PDと交際しました。
The IA_PD-options field encapsulates those options that are specific to this IA_PD. For example, all of the IA_PD Prefix Options carrying the prefixes associated with this IA_PD are in the IA_PD-options field.
PD-オプションがさばくアイオワ_はこのアイオワ_PDに特定のそれらのオプションを要約します。 例えば、このアイオワ_PDに関連している接頭語を運ぶアイオワ_PD Prefix OptionsのすべてがPD-オプションがさばくアイオワ_にあります。
An IA_PD option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_PD options.
アイオワ_PDオプションはDHCPメッセージのオプション部門に現れるだけであるかもしれません。 DHCPメッセージは複数のアイオワ_PDオプションを含むかもしれません。
The status of any operations involving this IA_PD is indicated in a Status Code option in the IA_PD-options field.
このアイオワ_PDにかかわるどんな操作の状態もPD-オプションがさばくアイオワ_のStatus Codeオプションで示されます。
Note that an IA_PD has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the prefixes in a IA_PD have expired, the IA_PD can be considered as having expired. T1 and T2 are included to give delegating routers explicit control over when a requesting router should contact the delegating router about a specific IA_PD.
アイオワ_PDにはそれ自身の明白な「生涯」か「リースの長さ」が全くないことに注意してください。 アイオワ_PDの接頭語のすべての有効な寿命が期限が切れたとき、期限が切れて、アイオワ_PDをみなすことができます。 要求ルータが特定のアイオワ_PDの周りで代表として派遣するルータに連絡すると、T1とT2は、明白な支配力を代表として派遣するルータに与えるために含まれています。
In a message sent by a requesting router to a delegating router, values in the T1 and T2 fields indicate the requesting router's preference for those parameters. The requesting router sets T1 and T2 to zero if it has no preference for those values. In a message sent by a delegating router to a requesting router, the requesting router MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. The values in the T1 and T2 fields are the number of seconds until T1 and T2.
要求ルータによって代表として派遣するルータに送られたメッセージでは、T1とT2分野の値はそれらのパラメタのための要求ルータの好みを示します。 それらの値のためにどちらでもよいなら、要求ルータはT1とT2をゼロに設定します。 代表として派遣するルータによって要求ルータに送られたメッセージでは、要求ルータはT1とT2パラメタにT1とT2分野で値を使用しなければなりません。 T1とT2までT1とT2分野の値は秒数です。
The delegating router selects the T1 and T2 times to allow the requesting router to extend the lifetimes of any prefixes in the
代表として派遣するルータは、要求ルータが中でどんな接頭語の生涯も広げるのを許容するためにT1とT2回を選択します。
Troan & Droms Standards Track [Page 8] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[8ページ]RFC3633IPv6接頭語オプション
IA_PD before the lifetimes expire, even if the delegating router is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the prefixes in the IA_PD that the delegating router is willing to extend, respectively. If the time at which the prefixes in an IA_PD are to be renewed is to be left to the discretion of the requesting router, the delegating router sets T1 and T2 to 0.
代表として派遣するルータがいつかの短期間を入手できなくても、生涯の前のアイオワ_PDは期限が切れます。 T1とT2のための推奨値はアイオワ_PDの接頭語の代表として派遣するルータが、広がっても構わないと思う最も短い都合のよい生涯、それぞれ.5と.8回です。 更新されるアイオワ_PDの接頭語がことである時が要求ルータの裁量に任せることであるなら、代表として派遣するルータはT1とT2を0に設定します。
If a delegating router receives an IA_PD with T1 greater than T2, and both T1 and T2 are greater than 0, the delegating router ignores the invalid values of T1 and T2 and processes the IA_PD as though the delegating router had set T1 and T2 to 0.
T1がT2よりすばらしい状態で代表として派遣するルータがアイオワ_PDを受けて、T1とT2の両方が0以上であるなら、代表として派遣するルータは、T1とT2の無効の値を無視して、まるで代表として派遣するルータがT1とT2を0に設定したかのようにアイオワ_PDを処理します。
If a requesting router receives an IA_PD with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_PD option and processes the remainder of the message as though the delegating router had not included the IA_PD option.
T1がT2よりすばらしい状態で要求ルータがアイオワ_PDを受けて、T1とT2の両方が0以上であるなら、まるで代表として派遣するルータがアイオワ_PDオプションを含んでいないかのように、クライアントは、アイオワ_PDオプションを捨てて、メッセージの残りを処理します。
10. IA_PD Prefix option
10. アイオワ_PD Prefixオプション
The IA_PD Prefix option is used to specify IPv6 address prefixes associated with an IA_PD. The IA_PD Prefix option must be encapsulated in the IA_PD-options field of an IA_PD option.
アイオワ_PD Prefixオプションは、アイオワ_PDに関連しているIPv6アドレス接頭語を指定するのに使用されます。 PD-オプションがさばくアイオワ_PDオプションのアイオワ_でアイオワ_PD Prefixオプションを要約しなければなりません。
The format of the IA_PD Prefix option is:
アイオワ_PD Prefixオプションの形式は以下の通りです。
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_IAPREFIX | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-length | |
+-+-+-+-+-+-+-+-+ IPv6 prefix |
| (16 octets) |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. IAprefix-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_IAPREFIX| オプション長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 都合のよい生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効な生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 接頭語長さ| | +++++++++IPv6接頭語| | (16の八重奏) | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . +++++++++、…+++++++++++++++++++++++++++++++++をIAprefixゆだねます。
Troan & Droms Standards Track [Page 9] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[9ページ]RFC3633IPv6接頭語オプション
option-code: OPTION_IAPREFIX (26)
オプションコード: オプション_IAPREFIX(26)
option-length: 25 + length of IAprefix-options field
オプション長さ: 25 + IAprefix-オプション分野の長さ
preferred-lifetime: The recommended preferred lifetime for the IPv6
prefix in the option, expressed in units of
seconds. A value of 0xFFFFFFFF represents
infinity.
都合のよい生涯: ユニットの秒に表されたオプションにおけるIPv6接頭語のためのお勧めの都合のよい生涯。 0xFFFFFFFFの値は無限を表します。
valid-lifetime: The valid lifetime for the IPv6 prefix in the
option, expressed in units of seconds. A value of
0xFFFFFFFF represents infinity.
有効な生涯: ユニットの秒に表されたオプションにおけるIPv6接頭語のための有効な生涯。 0xFFFFFFFFの値は無限を表します。
prefix-length: Length for this prefix in bits
接頭語長さ: ビットのこの接頭語のための長さ
IPv6-prefix: An IPv6 prefix
IPv6-接頭語: IPv6接頭語
IAprefix-options: Options associated with this prefix
IAprefix-オプション: この接頭語に関連しているオプション
In a message sent by a requesting router to a delegating router, the values in the fields can be used to indicate the requesting router's preference for those values. The requesting router may send a value of zero to indicate no preference. A requesting router may set the IPv6 prefix field to zero and a given value in the prefix-length field to indicate a preference for the size of the prefix to be delegated.
要求ルータによって代表として派遣するルータに送られたメッセージでは、それらの値のための要求ルータの好みを示すのにその分野の値を使用できます。 要求ルータは、好みを全く示さないようにゼロの値を送るかもしれません。 要求ルータは接頭語のサイズを代表として派遣するために優先を示す接頭語長さの分野にゼロと与えられた値にIPv6接頭語分野を位置させるかもしれません。
In a message sent by a delegating router the preferred and valid lifetimes should be set to the values of AdvPreferredLifetime and AdvValidLifetime as specified in section 6.2.1, "Router Configuration Variables" of RFC 2461 [4], unless administratively configured.
代表として派遣するルータによって送られたメッセージでは、都合のよくて有効な寿命はセクション6.2.1、RFC2461[4]の「ルータ構成変数」で指定されるようにAdvPreferredLifetimeとAdvValidLifetimeの値に決められるべきです、行政上構成されない場合。
A requesting router discards any prefixes for which the preferred lifetime is greater than the valid lifetime. A delegating router ignores the lifetimes set by the requesting router if the preferred lifetime is greater than the valid lifetime and ignores the values for T1 and T2 set by the requesting router if those values are greater than the preferred lifetime.
要求ルータは都合のよい寿命が有効な生涯より長いどんな接頭語も捨てます。 代表として派遣するルータは、都合のよい寿命が有効な生涯より大きいなら要求ルータによって決められた生涯を無視して、それらの値が都合のよい生涯より大きいなら要求ルータで用意ができているT1とT2のために値を無視します。
The values in the preferred and valid lifetimes are the number of seconds remaining for each lifetime.
都合のよくて有効な生涯の値は各生涯残っている秒数です。
An IA_PD Prefix option may appear only in an IA_PD option. More than one IA_PD Prefix Option can appear in a single IA_PD option.
アイオワ_PD Prefixオプションはアイオワ_PDオプションだけに現れるかもしれません。 1アイオワ_PD Prefix Optionがただ一つのアイオワ_PDオプションに現れることができます。
The status of any operations involving this IA_PD Prefix option is indicated in a Status Code option in the IAprefix-options field.
このアイオワ_PD Prefixオプションにかかわるどんな操作の状態もIAprefix-オプション分野でのStatus Codeオプションで示されます。
Troan & Droms Standards Track [Page 10] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[10ページ]RFC3633IPv6接頭語オプション
11. Delegating Router Solicitation
11. ルータ懇願を代表として派遣します。
The requesting router locates and selects a delegating router in the same way as described in section 17, "DHCP Server Solicitation" of RFC 3315. The details of the solicitation process are described in this section.
同様に、要求ルータは、セクション17、RFC3315の「DHCPサーバ懇願」で説明されるように代表として派遣するルータを場所を見つけて、選択します。 懇願の過程の詳細はこのセクションで説明されます。
11.1. Requesting router behavior
11.1. ルータの振舞いを要求します。
The requesting router creates and transmits a Solicit message as described in sections 17.1.1, "Creation of Solicit Messages" and 17.1.2, "Transmission of Solicit Messages" of RFC 3315. The requesting router creates an IA_PD and assigns it an IAID. The requesting router MUST include the IA_PD option in the Solicit message.
要求ルータは、RFC3315についてセクション17.1.1、「請求メッセージの創造」に17.1に.2、「請求メッセージの伝達」について説明するので、Solicitメッセージを作成して、送ります。 要求ルータは、アイオワ_PDを作成して、IAIDをそれに割り当てます。 要求ルータはSolicitメッセージにアイオワ_PDオプションを含まなければなりません。
The requesting router processes any received Advertise messages as described in section 17.1.3, "Receipt of Advertise Messages" of RFC 3315. The requesting router MAY choose to consider the presence of advertised prefixes in its decision about which delegating router to respond to.
メッセージの広告を出してください。ルータの過程を要求して、いずれも、広告を受けた、セクション17.1.3で説明されるメッセージ、「領収書、」 RFC3315について。 要求ルータは、どの代表として派遣するルータを反応させたらよいかに関する決定における、広告を出している接頭語の存在がそうすると考えるのを選ぶかもしれません。
The requesting router MUST ignore any Advertise message that includes a Status Code option containing the value NoPrefixAvail, with the exception that the requesting router MAY display the associated status message to the user.
要求ルータがいずれも無視しなければならない、広告、値のNoPrefixAvailを含むa Status Codeがゆだねるそのインクルードを通信させてください、そして、要求ルータがそうする例外と共に関連ステータスメッセージをユーザに表示してください。
11.2. Delegating router behavior
11.2. ルータの振舞いを代表として派遣します。
The delegating router sends an Advertise message to the requesting router in the same way as described in section 17.2.2, "Creation and transmission of Advertise messages" of RFC 3315. If the message contains an IA_PD option and the delegating router is configured to delegate prefix(es) to the requesting router, the delegating router selects the prefix(es) to be delegated to the requesting router. The mechanism through which the delegating router selects prefix(es) for delegation is not specified in this document. Examples of ways in which the delegating router might select prefix(es) for a requesting router include: static assignment based on subscription to an ISP; dynamic assignment from a pool of available prefixes; selection based on an external authority such as a RADIUS server using the Framed- IPv6-Prefix option as described in RFC 3162 [5].
代表として派遣するルータがずっとセクション17.2.2で説明されるように中で同じように要求ルータへのメッセージを広告に送る、「創造とトランスミッション、広告、メッセージ、」 RFC3315について。 メッセージがアイオワ_PDオプションを含んでいて、代表として派遣するルータが接頭語(es)を要求ルータへ代表として派遣するために構成されるなら、代表として派遣するルータは、接頭語(es)が要求ルータへ代表として派遣されるのを選択します。 代表として派遣するルータが代表団のために接頭語(es)を選択するメカニズムは本書では指定されません。 代表として派遣するルータが要求ルータのために接頭語(es)を選択するかもしれない方法に関する例は: 静的な課題はISPの購読を基礎づけました。 利用可能な接頭語のプールからのダイナミックな課題。 RFC3162[5]で説明されるようにFramed- IPv6-接頭語オプションを使用することでRADIUSサーバなどの外部の大家に基づく選択。
If the requesting router includes an IA_PD Prefix option in the IA_PD option in its Solicit message, the delegating router MAY choose to use the information in that option to select the prefix(es) or prefix size to be delegated to the requesting router.
要求ルータがSolicitメッセージにおけるアイオワ_PDオプションにおけるアイオワ_PD Prefixオプションを含んでいるなら、代表として派遣するルータは、接頭語(es)か接頭語サイズが要求ルータへ代表として派遣されるのを選択するのにそのオプションに情報を使用するのを選ぶかもしれません。
Troan & Droms Standards Track [Page 11] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[11ページ]RFC3633IPv6接頭語オプション
The delegating router sends an Advertise message to the requesting router in the same way as described in section, "Creation and transmission of Advertise messages" of RFC 3315. The delegating router MUST include an IA_PD option, identifying any prefix(es) that the delegating router will delegate to the requesting router.
代表として派遣するルータがずっとセクションで説明されるように中で同じように要求ルータへのメッセージを広告に送る、「創造とトランスミッション、広告、メッセージ、」 RFC3315について。 代表として派遣するルータはアイオワ_PDオプションを含まなければなりません、代表として派遣するルータが要求ルータへ代表として派遣するどんな接頭語(es)も特定して。
If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail and a status message for the user, a Server Identifier option with the delegating router's DUID and a Client Identifier option with the requesting router's DUID.
代表として派遣するルータがどんな接頭語も要求ルータからその後のRequestのどんなアイオワ_PDsにも割り当てないなら、代表として派遣するルータは、ユーザ、代表として派遣するルータのDUIDとのServer Identifierオプション、および要求ルータのDUIDとのClient Identifierオプションのためにアイオワ_PDの接頭語なしでアイオワ_PDを含んでいる要求ルータへのメッセージを広告に送って、_アイオワのステータスコードNoPrefixAvailを含むPDとステータスメッセージをStatus Codeオプションに送らなければなりません。
12. Requesting router initiated prefix delegation
12. ルータの開始している接頭語代表団を要求します。
A requesting router uses the same message exchanges as described in section 18, "DHCP Client-Initiated Configuration Exchange" of RFC 3315 to obtain or update prefix(es) from a delegating router. The requesting router and the delegating router use the IA_PD Prefix option to exchange information about prefix(es) in much the same way IA Address options are used for assigned addresses.
要求ルータは、代表として派遣するルータから接頭語(es)を得るか、またはアップデートするのにセクション18、RFC3315について「DHCPは構成交換をクライアントと同じくらい起こしたところ」で説明されるのと同じ交換処理を使用します。 要求ルータと代表として派遣するルータは、接頭語(es)に関してアイオワのAddressオプションが割り当てられたアドレスに使用される似たり寄ったりの方法で情報交換するのにアイオワ_PD Prefixオプションを使用します。
12.1. Requesting router behavior
12.1. ルータの振舞いを要求します。
The requesting router uses a Request message to populate IA_PDs with prefixes. The requesting router includes one or more IA_PD options in the Request message. The delegating router then returns the prefixes for the IA_PDs to the requesting router in IA_PD options in a Reply message.
要求ルータは接頭語でアイオワ_PDsに居住するRequestメッセージを使用します。 要求ルータはRequestメッセージにおける1つ以上のアイオワ_PDオプションを含んでいます。 そして、代表として派遣するルータはアイオワ_PDsのためにReplyメッセージにおけるアイオワ_PDオプションにおける要求ルータに接頭語を返します。
The requesting router includes IA_PD options in any Renew, or Rebind messages sent by the requesting router. The IA_PD option includes all of the prefixes the requesting router currently has associated with that IA_PD.
要求ルータはいずれもRenew、または要求ルータによって送られたRebindメッセージにアイオワ_PDオプションを含んでいます。 アイオワ_PDオプションは要求ルータが現在そのアイオワ_PDに関連づけた接頭語のすべてを含んでいます。
In some circumstances the requesting router may need verification that the delegating router still has a valid binding for the requesting router. Examples of times when a requesting router may ask for such verification include:
いくつかの事情では、要求ルータは代表として派遣するルータがまだa有効にしている要求ルータで付く検証を必要とするかもしれません。 要求ルータがそのような検証を求めるかもしれない回に関する例は:
o The requesting router reboots.
o 要求ルータはリブートされます。
o The requesting router's upstream link flaps.
o 要求ルータの上流のリンクはばたつきます。
o The requesting router is physically disconnected from a wired
connection.
o 要求ルータはワイヤードな接続から物理的に外されます。
Troan & Droms Standards Track [Page 12] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[12ページ]RFC3633IPv6接頭語オプション
If such verification is needed the requesting router MUST initiate a Rebind/Reply message exchange as described in section 18.1.4, "Creation and Transmission of Rebind Messages" of RFC 3315, with the exception that the retransmission parameters should be set as for the Confirm message, described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The requesting router includes any IA_PDs, along with prefixes associated with those IA_PDs in its Rebind message.
そのような検証が必要であるなら要求ルータがセクション18.1.4で説明されるようにRebind/回答交換処理に着手しなければならない、「創造とトランスミッション、」 RFCでは、3315が「再-トランスミッション」パラメタがConfirmメッセージに設定されるべきである例外でセクション18.1で.2について説明した、「創造とトランスミッション、」 RFC3315について。メッセージを縛り直してください。メッセージを確認してください。 要求ルータはRebindメッセージのそれらのアイオワ_PDsに関連している接頭語に伴うどんなアイオワ_PDsも含んでいます。
Each prefix has valid and preferred lifetimes whose durations are specified in the IA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request the extension of the lifetimes of a delegated prefix.
各接頭語には、持続時間がその接頭語のためのアイオワ_PD Prefixオプションで指定される有効で都合のよい寿命があります。 要求ルータはRenewと代表として派遣された接頭語の生涯の拡大を要求するRebindメッセージを使用します。
The requesting router uses a Release message to return a delegated prefix to a delegating router. The prefixes to be released MUST be included in the IA_PDs.
要求ルータは代表として派遣された接頭語を代表として派遣するルータに返すReleaseメッセージを使用します。 アイオワ_PDsにリリースされるべき接頭語を含まなければなりません。
The Confirm and Decline message types are not used with Prefix Delegation.
ConfirmとDeclineメッセージタイプはPrefix Delegationと共に使用されません。
Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.
有効なReplyメッセージの領収書に、各アイオワ_PDに関して、要求ルータはそれぞれの代表として派遣された接頭語から関連インタフェースが以下の例外で付けられているそれぞれのリンクまでサブネットを割り当てます: 要求ルータは代表として派遣された接頭語(es)からそれが代表として派遣するルータからDHCPメッセージを受け取ったリンクまで少しの代表として派遣された接頭語やサブネットも割り当ててはいけません。
When a requesting router subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes. For example, if the requesting router in Figure 1 were delegated 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber network. If the requesting router were delegated 3FFE:FFFF:0::/48 and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and 3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and 3FFE:FFFF:5:2::/64 for assignment to the other link.
要求ルータサブネットaが接頭語を代表として派遣したとき、それは、ユニークで、より長い接頭語を発生させるように追加ビットを接頭語に割り当てなければなりません。 以下のこと、代表として派遣された3FFE: FFFF: 図1の要求ルータが例えば0であるなら:/、48 それは3FFE: FFFF: 0:1を発生させるかもしれません:、:/64と3FFE: FFFF: 0:2:、:2への課題のための/64は加入者ネットワークでリンクされます。 以下のこと、代表として派遣された3FFE: FFFF: 要求ルータが0であるなら:/48と3FFE:FFFF:5:、:/、48 それは3FFE: FFFF: 0:1を割り当てるかもしれません:、:/64と3FFE: FFFF: 5:1:、:3FFE: FFFF: リンクの/64〜1、および0:2:、:/64と3FFE: FFFF: 5:2:、:もう片方への課題のための/64はリンクされます。
If the requesting router assigns a delegated prefix to a link to which the router is attached, and begins to send router advertisements for the prefix on the link, the requesting router MUST set the valid lifetime in those advertisements to be no later than the valid lifetime specified in the IA_PD Prefix option. A requesting router MAY use the preferred lifetime specified in the IA_PD Prefix option.
要求ルータがルータが付けているリンクに代表として派遣された接頭語を割り当てて、リンクの上の接頭語のためにルータ通知を送り始めるなら、要求ルータは、それらの広告における有効な生涯にアイオワ_PD Prefixオプションで指定された有効な生涯までにいるように設定しなければなりません。 要求ルータはアイオワ_PD Prefixオプションで指定された都合のよい生涯を費やすかもしれません。
Troan & Droms Standards Track [Page 13] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[13ページ]RFC3633IPv6接頭語オプション
Handling of Status Codes options in received Reply messages is described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315. The NoPrefixAvail Status Code is handled in the same manner as the NoAddrsAvail Status Code.
受信されたReplyメッセージにおけるStatus Codesオプションの取り扱いは.8、「応答メッセージの領収書」というRFC3315のセクション18.1で説明されます。 NoPrefixAvail Status CodeはNoAddrsAvail Status Codeと同じ方法で扱われます。
12.2. Delegating Router behavior
12.2. Routerの振舞いを代表として派遣します。
When a delegating router receives a Request message from a requesting router that contains an IA_PD option, and the delegating router is authorized to delegate prefix(es) to the requesting router, the delegating router selects the prefix(es) to be delegated to the requesting router. The mechanism through which the delegating router selects prefix(es) for delegation is not specified in this document. Section 11.2 gives examples of ways in which a delegating router might select the prefix(es) to be delegated to a requesting router.
代表として派遣するルータがアイオワ_PDオプションを含む要求ルータからRequestメッセージを受け取って、代表として派遣するルータが接頭語(es)を要求ルータへ代表として派遣するのが認可されるとき、代表として派遣するルータは、接頭語(es)が要求ルータへ代表として派遣されるのを選択します。 代表として派遣するルータが代表団のために接頭語(es)を選択するメカニズムは本書では指定されません。 セクション11.2は代表として派遣するルータが、接頭語(es)が要求ルータへ代表として派遣されるのを選択するかもしれない方法に関する例を出します。
A delegating router examines the prefix(es) identified in IA_PD Prefix options (in an IA_PD option) in Renew and Rebind messages and responds according to the current status of the prefix(es). The delegating router returns IA_PD Prefix options (within an IA_PD option) with updated lifetimes for each valid prefix in the message from the requesting router. If the delegating router finds that any of the prefixes are not in the requesting router's binding entry, the delegating router returns the prefix to the requesting router with lifetimes of 0.
代表として派遣するルータは、RenewとRebindメッセージでアイオワ_PD Prefixオプションで特定された接頭語(es)を調べて(アイオワ_PDオプションで)、接頭語(es)の現在の状態に従って、応じます。 代表として派遣するルータはメッセージのそれぞれの有効な接頭語のために最終更新日生涯と共に要求ルータからアイオワ_PD Prefixオプションを返します(アイオワ_PDオプションの中で)。 接頭語のいずれも要求ルータの拘束力があるエントリーにないのが代表として派遣するルータによってわかるなら、代表として派遣するルータは0の生涯がある要求ルータに接頭語を返します。
The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD:
要求ルータのアイオワ_PDに関して結合を見つけることができないとき、代表として派遣するルータは以下の通り振る舞います:
Renew message: If the delegating router cannot find a binding
for the requesting router's IA_PD the delegating
router returns the IA_PD containing no prefixes
with a Status Code option set to NoBinding in the
Reply message.
メッセージを更新してください: 代表として派遣するルータが代表として派遣するルータが返す要求ルータのアイオワ_PDに関して結合を見つけることができないなら、Status Codeオプションがある接頭語を全く含まないアイオワ_PDはReplyメッセージにNoBindingにセットしました。
Rebind message: If the delegating router cannot find a binding
for the requesting router's IA_PD and the
delegating router determines that the prefixes in
the IA_PD are not appropriate for the link to
which the requesting router's interface is
attached according to the delegating routers
explicit configuration, the delegating router MAY
send a Reply message to the requesting router
containing the IA_PD with the lifetimes of the
prefixes in the IA_PD set to zero. This Reply
constitutes an explicit notification to the
requesting router that the prefixes in the IA_PD
are no longer valid. If the delegating router is
メッセージを縛り直してください: 代表として派遣するルータが要求ルータのアイオワ_PDに関して結合を見つけることができないで、代表として派遣するルータが、明白な構成、代表として派遣するルータがそうする代表として派遣するルータに従って要求ルータのインタフェースが付けられているリンクには、アイオワ_PDの接頭語が適切でないことを決定するなら、PDがゼロに設定するアイオワ_に接頭語の生涯があるアイオワ_PDを含む要求ルータにReplyメッセージを送ってください。 このReplyはアイオワ_PDの接頭語がもう有効でないという要求ルータへの明白な通知を構成します。 代表として派遣するルータがそうなら
Troan & Droms Standards Track [Page 14] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[14ページ]RFC3633IPv6接頭語オプション
unable to determine if the prefix is not
appropriate for the link, the Rebind message is
discarded.
リンクには、接頭語が適切でないかどうか決定できないで、Rebindメッセージは捨てられます。
A delegating router may mark any prefix(es) in IA_PD Prefix options in a Release message from a requesting router as "available", dependent on the mechanism used to acquire the prefix, e.g., in the case of a dynamic pool.
代表として派遣するルータは、「利用可能である」として要求ルータからのReleaseメッセージにおけるアイオワ_PD Prefixオプションでどんな接頭語も(es)であるとマークするかもしれません、接頭語を習得するのに使用されるメカニズムに依存しています、例えば、ダイナミックなプールの場合で。
The delegating router MUST include an IA_PD Prefix option or options (in an IA_PD option) in Reply messages sent to a requesting router.
代表として派遣するルータは要求ルータに送られたReplyメッセージにアイオワ_PD Prefixオプションかオプション(アイオワ_PDオプションにおける)を含まなければなりません。
13. Prefix Delegation reconfiguration
13. 接頭語Delegation再構成
This section describes prefix delegation in Reconfigure message exchanges.
このセクションはReconfigure交換処理で接頭語代表団について説明します。
13.1. Delegating Router behavior
13.1. Routerの振舞いを代表として派遣します。
The delegating router initiates a configuration message exchange with a requesting router, as described in section 19, "DHCP Server- Initiated Configuration Exchange" of RFC 3315, by sending a Reconfigure message (acting as a DHCP server) to the requesting router, as described in section 19.1, "Server Behavior" of RFC 3315. The delegating router specifies the IA_PD option in the Option Request option to cause the requesting router to include an IA_PD option to obtain new information about delegated prefix(es).
代表として派遣するルータは要求ルータで構成交換処理に着手します、セクション19、RFC3315について「DHCPサーバは構成交換を起こしたところ」で説明されるように、Reconfigureメッセージ(DHCPサーバとして、機能する)を要求ルータに送ることによって、セクション19.1、RFC3315の「サーバの振舞い」で説明されるように。 代表として派遣するルータは、要求ルータが代表として派遣された接頭語(es)に関する新情報を得るためにアイオワ_PDオプションを含んでいることを引き起こすためにOption Requestオプションにおけるアイオワ_PDオプションを指定します。
13.2. Requesting Router behavior
13.2. Routerの振舞いを要求します。
The requesting router responds to a Reconfigure message, acting as a DHCP client, received from a delegating router as described in section 19.4, "Client Behavior" of RFC 3315. The requesting router MUST include the IA_PD Prefix option(s) (in an IA_PD option) for prefix(es) that have been delegated to the requesting router by the delegating router from which the Reconfigure message was received.
要求ルータはReconfigureメッセージに応じます、DHCPクライアントとして機能して、セクション19.4で説明される代表として派遣するルータ、RFC3315の「クライアントの振舞い」によって、受け取られています。 要求ルータはReconfigureメッセージが受け取られた代表として派遣するルータによって要求ルータへ代表として派遣された接頭語(es)のためにアイオワ_PD Prefixオプションを含まなければなりません(アイオワ_PDオプションで)。
14. Relay agent behavior
14. 中継エージェントの振舞い
A relay agent forwards messages containing Prefix Delegation options in the same way as described in section 20, "Relay Agent Behavior" of RFC 3315.
中継エージェントは同様に、セクション20、RFC3315の「中継エージェントの振舞い」で説明されるようにPrefix Delegationオプションを含むメッセージを転送します。
If a delegating router communicates with a requesting router through a relay agent, the delegating router may need a protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router.
代表として派遣するルータが中継エージェントを通って要求ルータで交信するなら、代表として派遣するルータは、代表として派遣された接頭語のためのルーティング情報をプロバイダー縁のルータに加えるためにプロトコルか他のバンドで出ているコミュニケーションを必要とするかもしれません。
Troan & Droms Standards Track [Page 15] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[15ページ]RFC3633IPv6接頭語オプション
15. Security Considerations
15. セキュリティ問題
Security considerations in DHCP are described in section 23, "Security Considerations" of RFC 3315.
DHCPのセキュリティ問題はセクション23、RFC3315の「セキュリティ問題」で説明されます。
A rogue delegating router can issue bogus prefixes to a requesting router. This may cause denial of service due to unreachability.
ルータを代表として派遣する悪党は要求ルータににせの接頭語を発行できます。 これは「非-可到達性」によるサービスの否定を引き起こすかもしれません。
A malicious requesting router may be able to mount a denial of service attack by repeated requests for delegated prefixes that exhaust the delegating router's available prefixes.
悪意がある要求ルータは代表として派遣するルータの利用可能な接頭語がくたくたになる代表として派遣された接頭語を求める再三の要求でサービス不能攻撃を仕掛けることができるかもしれません。
To guard against attacks through prefix delegation, requesting routers and delegating routers SHOULD use DHCP authentication as described in section 21, "Authentication of DHCP messages" of RFC 3315. For point to point links, where one trusts that there is no man in the middle, or one trusts layer two authentication, DHCP authentication or IPsec may not be necessary. Because a requesting router and delegating routers must each have at least one assigned IPv6 address, the routers may be able to use IPsec for authentication of DHCPv6 messages. The details of using IPsec for DHCPv6 are under development.
接頭語代表団を通した攻撃に用心するために、ルータを要求して、ルータSHOULDを代表として派遣すると、DHCP認証は21、「DHCPメッセージの認証」というRFC3315のセクションで説明されるように使用されます。 ポイントがリンクを指すように、中央、または1つの受託には男性が全くいない1つの受託がどこで2認証、DHCP認証またはIPsecを層にするかは必要でないかもしれません。 要求ルータとルータを代表として派遣するのがIPv6アドレスを少なくとも1つにそれぞれ割り当てさせなければならないので、ルータはDHCPv6メッセージの認証にIPsecを使用できるかもしれません。 DHCPv6にIPsecを使用する詳細は開発中です。
Networks configured with delegated prefixes should be configured to preclude intentional or inadvertent inappropriate advertisement of these prefixes.
代表として派遣された接頭語によって構成されたネットワークは、これらの接頭語の意図的であるか不注意な不適切な広告を排除するために構成されるべきです。
16. IANA Considerations
16. IANA問題
IANA has assigned option codes to:
IANAは以下のことのためにオプションコードを割り当てました。
OPTION_IA_PD (25)
_オプション_アイオワPD(25)
OPTION_IAPREFIX (26)
オプション_IAPREFIX(26)
from the option-code space as defined in section 24.3, "DHCP Options" of RFC 3315.
セクション24.3で定義されるオプションコードスペース、RFC3315の「DHCPオプション」から。
IANA has assigned status code 6 to:
IANAは以下のことのためにステータスコード6を割り当てました。
NoPrefixAvail: Delegating router has no prefixes available to
assign to the IAPD(s)
NoPrefixAvail: ルータを代表として派遣するのにおいて、IAPDに割り当てるために利用可能などんな接頭語もありません。(s)
from the status-code space as defined in section 24.4, "Status Codes" of RFC 3315.
セクション24.4、RFC3315の「ステータスコード」で定義されるステータスコードスペースから。
Troan & Droms Standards Track [Page 16] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[16ページ]RFC3633IPv6接頭語オプション
17. Intellectual Property Statement
17. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
18. References
18. 参照
18.1. Normative References
18.1. 引用規格
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[1] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[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.)はバウンドしています、J.、フォルツ、B.、レモン、T.、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、2003年7月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[4]NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[5] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162,
August 2001.
[5]AbobaとB.とゾルンとG.とD.ミットンと「半径とIPv6"、RFC3162、2001年8月。」
18.2. Informative References
18.2. 有益な参照
[6] Miyakawa, S. and R. Droms, "Requirements for IPv6 prefix
delegation", Work in Progress, August 2003.
[6]MiyakawaとS.とR.Droms、「IPv6接頭語代表団のための要件」、Progress、2003年8月のWork。
Troan & Droms Standards Track [Page 17] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[17ページ]RFC3633IPv6接頭語オプション
19. Acknowledgements
19. 承認
Thanks for the input and review by (in alphabetical order) Steve Deering, Dave Forster, Brian Haberman, Tatuya Jinmei, Shin Miyakawa, Pekka Savola, Bernie Volz, Trevor Warwick and Toshi Yamasaki.
(アルファベット順に)スティーブ・デアリング、デーヴ・フォルスター、ブライアン・ハーバーマン、Tatuya Jinmei、Shin Miyakawa、ペッカSavola、バーニー・フォルツ、トレバー・ウォリック、およびToshi山崎による入力とレビューをありがとうございます。
20. Authors' Addresses
20. 作者のアドレス
Ole Troan Cisco Systems 250 Longwater Avenue Reading RG2 6GB United Kingdom
Ole Troanシスコシステムズ250Longwaterアベニュー読書RG2 6GBイギリス
Phone: +44 20 8824 8666 EMail: ot@cisco.com
以下に電話をしてください。 +44 20 8824 8666はメールされます: ot@cisco.com
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
ラルフDromsシスコシステムズ1414マサチューセッツ通りBoxborough、MA01719米国
Phone: +1 978 936 1674 EMail: rdroms@cisco.com
以下に電話をしてください。 +1 1674年の978 936メール: rdroms@cisco.com
Troan & Droms Standards Track [Page 18] RFC 3633 IPv6 Prefix Options for DHCPv6 December 2003
DHCPv6 December 2003のためのTroan&Droms標準化過程[18ページ]RFC3633IPv6接頭語オプション
21. Full Copyright Statement
21. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Troan & Droms Standards Track [Page 19]
Troan&Droms標準化過程[19ページ]
一覧
スポンサーリンク
