[要約] RFC 6603は、DHCPv6ベースのプレフィックスデリゲーションにおけるプレフィックス除外オプションに関する仕様です。このRFCの目的は、ネットワーク管理者が特定のプレフィックスをデリゲートしないようにするためのオプションを提供することです。

Internet Engineering Task Force (IETF)                  J. Korhonen, Ed.
Request for Comments: 6603                        Nokia Siemens Networks
Updates: 3633                                              T. Savolainen
Category: Standards Track                                          Nokia
ISSN: 2070-1721                                              S. Krishnan
                                                                Ericsson
                                                                O. Troan
                                                      Cisco Systems, Inc
                                                                May 2012
        

Prefix Exclude Option for DHCPv6-based Prefix Delegation

DHCPv6ベースのプレフィックス委任のプレフィックス除外オプション

Abstract

概要

This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633.

この仕様は、DHCPv6ベースのプレフィックス委任を使用するときに、委任されたプレフィックスセットから特定の1つのプレフィックスを除外できるようにするオプションのメカニズムを定義します。新しいメカニズムはRFC 3633を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6603.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6603で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Requirements and Terminology ....................................2
   3. Problem Background ..............................................3
   4. Solution ........................................................3
      4.1. Prefix Delegation with Excluded Prefixes ...................3
      4.2. Prefix Exclude Option ......................................4
   5. Delegating Router Solicitation ..................................6
      5.1. Requesting Router ..........................................6
      5.2. Delegating Router ..........................................6
   6. Requesting Router Initiated Prefix Delegation ...................7
      6.1. Requesting Router ..........................................7
      6.2. Delegating Router ..........................................8
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................8
   9. Acknowledgements ................................................8
   10. References .....................................................9
      10.1. Normative References ......................................9
      10.2. Informative References ....................................9
        
1. Introduction
1. はじめに

This specification defines an optional mechanism and the related DHCPv6 option to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation.

この仕様では、オプションのメカニズムと関連するDHCPv6オプションを定義して、DHCPv6ベースのプレフィックス委任を使用するときに、委任されたプレフィックスセットから特定の1つのプレフィックスを除外できるようにしています。

The prefix exclusion mechanism is targeted at deployments where DHCPv6-based prefix delegation is used, but a single aggregated route/prefix has to represent one customer, instead of using one prefix for the link between the delegating router and the requesting router and another prefix for the customer network. The mechanism defined in this specification allows a delegating router to use a prefix out of the delegated prefix set on the link through which it exchanges DHCPv6 messages with the requesting router, and is intended for use in networks where each requesting router is on its own layer-2 domain.

プレフィックス除外メカニズムは、DHCPv6ベースのプレフィックス委任が使用されている展開を対象としていますが、委任ルーターと要求ルーター間のリンクに1つのプレフィックスを使用する代わりに、1つの集約ルート/プレフィックスが1つの顧客を表す必要があります。顧客ネットワーク。この仕様で定義されているメカニズムにより、委任ルーターは、要求ルーターとDHCPv6メッセージを交換するリンクで委任されたプレフィックスセットからのプレフィックスを使用でき、各要求ルーターが独自のレイヤーにあるネットワークでの使用を目的としています-2ドメイン。

2. Requirements and 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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

3. Problem Background
3. 問題の背景

DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit limitation described in Section 12.1 of [RFC3633] that a prefix delegated to a requesting router cannot be used by the delegating router. This restriction implies that the delegating router will have two (non-aggregatable) routes towards a customer: one for the link between the requesting router and the delegating router, and one for the customer site behind the requesting router.

DHCPv6プレフィックス委任(DHCPv6-PD)[RFC3633]には、[RFC3633]のセクション12.1で説明されているように、要求元ルーターに委任されたプレフィックスを委任ルーターで使用できないという明示的な制限があります。この制限は、委任ルーターが顧客への2つの(集約不可能な)ルートを持つことを意味します。1つは要求ルーターと委任ルーター間のリンク用で、もう1つは要求ルーターの背後にある顧客サイト用です。

There are architectures and link models where a host (e.g., a mobile router, also acting as a requesting router) always has a single (/64) prefix configured on its uplink interface and the delegating router is also the requesting router's first-hop router. Furthermore, it may be required that the prefix configured on the uplink interface has to be aggregatable with the delegated prefixes. This introduces a problem in how to use DHCPv6-PD together with stateless [RFC4862] or stateful [RFC3315] address autoconfiguration on a link where the /64 advertised is also part of the prefix delegated (e.g., /56) to the requesting router.

ホスト(たとえば、要求ルーターとしても機能するモバイルルーター)が常に1つの(/ 64)プレフィックスをそのアップリンクインターフェイスに構成し、委任ルーターが要求ルーターの最初のホップルーターでもあるアーキテクチャとリンクモデルがあります。 。さらに、アップリンクインターフェイスで設定されたプレフィックスは、委任されたプレフィックスと集約可能でなければならない場合があります。これにより、/ 64がアドバタイズされたリンク上で、ステートレス[RFC4862]またはステートフル[RFC3315]アドレスの自動構成とともにDHCPv6-PDを使用する方法に問題が生じ、要求元ルーターに委任されたプレフィックス(/ 56など)の一部にもなります。

4. Solution
4. 解決
4.1. Prefix Delegation with Excluded Prefixes
4.1. プレフィックスが除外されたプレフィックス委任

This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE (67), that is used to exclude exactly one prefix from a delegated prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option allows prefix delegation where a requesting router is delegated a prefix (e.g., /56) and the delegating router uses one prefix (e.g., /64) on the link through which it exchanges DHCPv6 messages with the requesting router with a prefix out of the same delegated prefix set.

この仕様は、新しいDHCPv6オプションOPTION_PD_EXCLUDE(67)を定義します。これは、委任されたプレフィックスから1つのプレフィックスを除外するために使用されます。 OPTION_PD_EXCLUDEは、OPTION_IAPREFIX IAprefix-optionsフィールドに含まれています。 1つのOPTION_IAPREFIXオプションに含めることができるOPTION_PD_EXCLUDEオプションは1つだけです。 OPTION_PD_EXCLUDEオプションを使用すると、要求側ルーターにプレフィックス(/ 56など)が委任され、委任ルーターがDHCPv6メッセージをプレフィックス付きの要求側ルーターと交換するリンクで1つのプレフィックス(たとえば/ 64)を使用するプレフィックス委任が可能になります。同じ委任されたプレフィックスセットの。

A requesting router includes an OPTION_ORO option with the OPTION_PD_EXCLUDE option code in a Solicit, Request, Renew, or Rebind message to inform the delegating router about the support for the prefix delegation functionality defined in this specification. A delegating router may include the OPTION_PD_EXCLUDE option code in an OPTION_ORO option in a Reconfigure message to indicate that the requesting router should request OPTION_PD_EXCLUDE from the delegating router.

要求側ルーターは、要請、要求、更新、または再バインドメッセージにOPTION_PD_EXCLUDEオプションコードを含むOPTION_OROオプションを含め、この仕様で定義されているプレフィックス委任機能のサポートについて委任ルーターに通知します。委任ルーターは、再構成メッセージのOPTION_OROオプションにOPTION_PD_EXCLUDEオプションコードを含めて、要求ルーターが委任ルーターからOPTION_PD_EXCLUDEを要求する必要があることを示すことができます。

The delegating router includes the prefix in the OPTION_PD_EXCLUDE option that is excluded from the delegated prefix set. The requesting router MUST NOT assign the excluded prefix to any of its downstream interfaces.

委任ルーターは、委任されたプレフィックスセットから除外されるOPTION_PD_EXCLUDEオプションにプレフィックスを含めます。要求側ルーターは、除外されたプレフィックスをそのダウンストリームインターフェイスのいずれにも割り当ててはなりません(MUST NOT)。

4.2. Prefix Exclude Option
4.2. 接頭辞除外オプション
    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_PD_EXCLUDE       |         option-len            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  prefix-len   | IPv6 subnet ID (1 to 16 octets)               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Prefix Exclude Option

接頭辞除外オプション

o option-code: OPTION_PD_EXCLUDE (67).

o オプションコード:OPTION_PD_EXCLUDE(67)。

o option-len: 1 + length of IPv6 subnet ID in octets. A valid option-len is between 2 and 17.

o option-len:1 +オクテット単位のIPv6サブネットIDの長さ。有効なoption-lenは2〜17です。

o prefix-len: The length of the excluded prefix in bits. The prefix-len MUST be between 'OPTION_IAPREFIX prefix-length'+1 and 128.

o prefix-len:除外されるプレフィックスの長さ(ビット単位)。 prefix-lenは 'OPTION_IAPREFIX prefix-length' + 1から128の間でなければなりません。

o IPv6 subnet ID: A variable-length IPv6 subnet ID up to 128 bits.

o IPv6サブネットID:最大128ビットの可変長IPv6サブネットID。

The IPv6 subnet ID contains prefix-len minus 'OPTION_IAPREFIX prefix-length' bits extracted from the excluded prefix starting from the bit position 'OPTION_IAPREFIX prefix-length'. The extracted subnet ID MUST be left-shifted to start from a full octet boundary, i.e., left-shift of 'OPTION_IAPREFIX prefix-length' mod 8 bits. The subnet ID MUST be zero-padded to the next full octet boundary.

IPv6サブネットIDには、ビット位置「OPTION_IAPREFIX prefix-length」から始まる除外されたプレフィックスから抽出されたprefix-lenマイナス「OPTION_IAPREFIX prefix-length」ビットが含まれています。抽出されたサブネットIDは、完全なオクテット境界から開始するように左シフトする必要があります。つまり、「OPTION_IAPREFIXプレフィックス長」mod 8ビットの左シフトです。サブネットIDは、次の完全なオクテット境界までゼロが埋め込まれる必要があります。

The encoding of the IPv6 subnet ID can be expressed in a C-like pseudocode as shown below:

IPv6サブネットIDのエンコーディングは、以下に示すようにCのような擬似コードで表すことができます。

     uint128_t p1;           // the delegated IPv6 prefix
     uint128_t p2;           // the excluded IPv6 prefix
     uint16_t a;             // the OPTION_IAPREFIX prefix-length
     uint8_t b;              // the excluded IPv6 prefix length
     uint8_t s;
        

// sanity checks

//健全性チェック

     s = 128-a;              // size of non-prefix bits
     assert(b>a);            // b must be at least a+1
     assert(p1>>s == p2>>s); // p1 and p2 must share a common
                             // prefix of 'a' bits
        

// calculate the option content

//オプションの内容を計算します

     uint16_t c = b-a-1;     // the IPv6_subnet_ID_length-1 in bits
     uint16_t d = (c/8)+1;   // the IPv6_subnet_ID_length in octets
     uint128_t p = p2<<a;    // p is the IPv6 subnet ID that has the
                             // common p1 prefix left-shifted out to
                             // a full octet boundary (trailing bits
                             // are zeroed)
        

// populate the option

//オプションを入力します

     uint8_t* id = &OPTION_PD_EXCLUDE.IPv6_subnet_ID;
     OPTION_PD_EXCLUDE.option_len = d+1;
     OPTION_PD_EXCLUDE.prefix_len = b;
        
     while (d-- > 0) {
       *id++ = p>>120;
       p <<= 8;
     }
        

The OPTION_PD_EXCLUDE option MUST only be included in the OPTION_IAPREFIX IAprefix-options [RFC3633] field.

OPTION_PD_EXCLUDEオプションは、OPTION_IAPREFIX IAprefix-options [RFC3633]フィールドにのみ含める必要があります。

Any prefix excluded from the delegated prefix MUST be contained in OPTION_PD_EXCLUDE options within the corresponding OPTION_IAPREFIX.

委任されたプレフィックスから除外されたプレフィックスは、対応するOPTION_IAPREFIX内のOPTION_PD_EXCLUDEオプションに含まれている必要があります。

The prefix included in the OPTION_PD_EXCLUDE option shares the same preferred-lifetime and valid-lifetime as the delegated prefix in the encapsulating OPTION_IAPREFIX option.

OPTION_PD_EXCLUDEオプションに含まれるプレフィックスは、カプセル化するOPTION_IAPREFIXオプションの委任されたプレフィックスと同じpreferred-lifetimeおよびvalid-lifetimeを共有します。

The prefix in the OPTION_PD_EXCLUDE option MUST be part of the delegated prefix in the OPTION_IAPREFIX. For example, the requesting router has earlier been assigned a 2001:db8:dead:beef::/64 prefix by the delegating router, and the delegated prefix in the OPTION_IAPREFIX is 2001:db8:dead:bee0::/59. In this case, 2001:db8: dead:beef::/64 is a valid prefix to be used in the OPTION_PD_EXCLUDE option. The OPTION_PD_EXCLUDE option would be encoded as follows:

OPTION_PD_EXCLUDEオプションのプレフィックスは、OPTION_IAPREFIXの委任されたプレフィックスの一部である必要があります。たとえば、要求元ルーターには、委任元ルーターによって2001:db8:dead:beef :: / 64プレフィックスが以前に割り当てられており、OPTION_IAPREFIXの委任されたプレフィックスは2001:db8:dead:bee0 :: / 59です。この場合、2001:db8:dead:beef :: / 64は、OPTION_PD_EXCLUDEオプションで使用される有効なプレフィックスです。 OPTION_PD_EXCLUDEオプションは、次のようにエンコードされます。

    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_PD_EXCLUDE       |               2               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       64      |0|1|1|1|1|0|0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   ^         ^
                   |         |
                   |         +- 3 zero-padded bits follow
                   |
                   +- using C syntax: 0xef << (59 % 8)
                      Note: 59 mod 8 = 3
        
5. Delegating Router Solicitation
5. ルーター要請の委任

The requesting router locates and selects a delegating router in the same way as described in Section 11 [RFC3633]. This specification only describes the additional steps required by the use of the OPTION_PD_EXCLUDE option.

リクエストを行うルーターは、第11条[RFC3633]で説明されているのと同じ方法で、委任ルーターを見つけて選択します。この仕様では、OPTION_PD_EXCLUDEオプションの使用に必要な追加の手順のみを説明しています。

5.1. Requesting Router
5.1. リクエストルーター

If the requesting router implements the solution described in Section 4.1, then the requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option in Solicit messages.

要求側ルーターがセクション4.1で説明されているソリューションを実装している場合、要求側ルーターは、要請メッセージのOPTION_OROオプションにOPTION_PD_EXCLUDEオプションコードを含める必要があります(SHOULD)。

Once receiving Advertise message(s), the requesting router uses the prefix(es) received in OPTION_PD_EXCLUDE, in addition to the advertised prefixes, to choose the delegating router. The requesting router MUST proceed to the Prefix Delegation procedure described in Section 6.1. If the Advertise message did not include the OPTION_PD_EXCLUDE option, then the requesting router MUST fall back to normal behavior, as described in Section 11.1 of [RFC3633].

アドバタイズメッセージを受信すると、要求元ルーターは、アドバタイズされたプレフィックスに加えて、OPTION_PD_EXCLUDEで受信したプレフィックスを使用して、委任ルーターを選択します。要求側ルーターは、セクション6.1で説明されているプレフィックス委任手順に進む必要があります。 [RFC3633]のセクション11.1で説明されているように、アドバタイズメッセージにOPTION_PD_EXCLUDEオプションが含まれていない場合、要求元のルーターは通常の動作にフォールバックする必要があります。

5.2. Delegating Router
5.2. 委任ルーター

If the OPTION_ORO option in the Solicit message includes the OPTION_PD_EXCLUDE option code, then the delegating router knows that the requesting router supports the solution defined in this specification. If the Solicit message also contains an IA_PD option, the delegating router can delegate to the requesting router a prefix that includes the prefix already assigned to the requesting router's uplink interface. The delegating router includes the prefix originally, or to be, assigned to the requesting router in the OPTION_PD_EXCLUDE option within the OPTION_IAPREFIX IAprefix-option in the Advertise message.

要請メッセージのOPTION_OROオプションにOPTION_PD_EXCLUDEオプションコードが含まれている場合、委任元ルーターは、要求元ルーターがこの仕様で定義されているソリューションをサポートしていることを認識しています。要請メッセージにIA_PDオプションも含まれている場合、委任ルーターは、要求ルーターのアップリンクインターフェイスに既に割り当てられているプレフィックスを含むプレフィックスを要求ルーターに委任できます。委任ルーターには、アドバタイズメッセージのOPTION_IAPREFIX IAprefix-option内のOPTION_PD_EXCLUDEオプションで要求元ルーターに割り当てられている、または割り当てられる予定のプレフィックスが含まれています。

If the OPTION_ORO option in the Solicit message does not include the OPTION_PD_EXCLUDE option code, then the delegating router MUST fall back to normal behavior, as described in Section 11.2 of [RFC3633].

[RFC3633]のセクション11.2で説明されているように、要請メッセージのOPTION_OROオプションにOPTION_PD_EXCLUDEオプションコードが含まれていない場合、委任ルーターは通常の動作にフォールバックする必要があります。

If the OPTION_ORO option in the Solicit message includes the OPTION_PD_EXCLUDE option code but the delegating router does not support the solution described in this specification, then the delegating router acts as specified in [RFC3633].

要請メッセージのOPTION_OROオプションにOPTION_PD_EXCLUDEオプションコードが含まれているが、委任ルーターがこの仕様で説明されているソリューションをサポートしていない場合、委任ルーターは[RFC3633]で指定されているように動作します。

6. Requesting Router-Initiated Prefix Delegation
6. ルーター開始のプレフィックス委任の要求

The procedures described in the following sections are aligned with Section 12 of [RFC3633]. In this specification, we only describe the additional steps required by the use of the OPTION_PD_EXCLUDE option.

以下のセクションで説明する手順は、[RFC3633]のセクション12に沿っています。この仕様では、OPTION_PD_EXCLUDEオプションの使用に必要な追加の手順についてのみ説明します。

6.1. Requesting Router
6.1. リクエストルーター

The requesting router behavior regarding the use of the OPTION_PD_EXCLUDE option is mostly identical to the steps described in Section 5.1, with the difference being the use of a DHCPv6 Request instead of an Solicit message. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315]. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315].

OPTION_PD_EXCLUDEオプションの使用に関するルーターの要求動作は、5.1で説明した手順とほとんど同じですが、SolicitメッセージではなくDHCPv6要求を使用する点が異なります。 [RFC3315]のセクション22.7で説明されているように、リクエストしているルーターはDHCPv6メッセージのOPTION_OROオプションにOPTION_PD_EXCLUDEオプションコードを含める必要があります(SHOULD)。 [RFC3315]のセクション22.7で説明されているように、リクエストしているルーターはDHCPv6メッセージのOPTION_OROオプションにOPTION_PD_EXCLUDEオプションコードを含める必要があります(SHOULD)。

The requesting router uses a Release message to return the delegated prefix(es) to a delegating router. The prefix(es) to be released MUST be included in the IA_PDs along with the excluded prefix included in the OPTION_PD_EXCLUDE option. The requesting router MUST NOT use the OPTION_PD_EXCLUDE option to introduce an additional excluded prefix in the Release message for which it originally got a valid binding.

要求元ルーターは、R​​eleaseメッセージを使用して、委任されたプレフィックスを委任ルーターに返します。リリースされる接頭辞は、OPTION_PD_EXCLUDEオプションに含まれる除外された接頭辞とともにIA_PDに含まれている必要があります。要求側ルーターは、OPTION_PD_EXCLUDEオプションを使用して、最初に有効なバインディングを取得したReleaseメッセージに追加の除外プレフィックスを導入してはなりません(MUST NOT)。

The requesting router must create sink routes for the delegated prefixes, minus the excluded prefixes. This may be done by creating sink routes for delegated prefixes and more specific routes for the excluded prefixes.

要求側ルーターは、委任されたプレフィックスから除外されたプレフィックスを除いたシンクルートを作成する必要があります。これは、委任されたプレフィックスのシンクルートと、除外されたプレフィックスのより具体的なルートを作成することで実行できます。

6.2. Delegating Router
6.2. 委任ルーター

The delegating router behavior regarding the use of the OPTION_PD_EXCLUDE option is more or less identical to the step described in Section 5.2. The only difference is the DHCPv6 messages used to carry the OPTION_PD_EXCLUDE option.

OPTION_PD_EXCLUDEオプションの使用に関する委任ルーターの動作は、セクション5.2で説明されている手順とほぼ同じです。唯一の違いは、OPTION_PD_EXCLUDEオプションの伝達に使用されるDHCPv6メッセージです。

The delegating router may mark any prefix(es) in the IA_PD Prefix options in a Release message from a requesting router as 'available', excluding the prefix included in the OPTION_PD_EXCLUDE options. If the Release message contains a 'new' excluded prefix in any OPTION_PD_EXCLUDE option, the delegating router MUST send a Reply message with the Status Code set to NoBinding for that IA_PD option.

委任するルーターは、OPTION_PD_EXCLUDEオプションに含まれるプレフィックスを除いて、要求側ルーターからのリリースメッセージのIA_PDプレフィックスオプションのプレフィックスを「使用可能」としてマークできます。リリースメッセージのOPTION_PD_EXCLUDEオプションに「新しい」除外されたプレフィックスが含まれている場合、委任するルーターは、そのIA_PDオプションのステータスコードをNoBindingに設定して返信メッセージを送信する必要があります。

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

Security considerations for DHCPv6 are described in Section 23 of [RFC3315]. For DHCPv6 Prefix Delegation, they are described in Section 15 of [RFC3633]. In particular, RFC 3633 provides recommendations for protection against prefix delegation attacks. This specification does not add any new security considerations beyond those provided by RFC 3633.

DHCPv6のセキュリティに関する考慮事項は、[RFC3315]のセクション23で説明されています。 DHCPv6プレフィックス委任については、[RFC3633]のセクション15で説明されています。特に、RFC 3633は、プレフィックス委任攻撃に対する保護に関する推奨事項を提供しています。この仕様は、RFC 3633によって提供されるものを超える新しいセキュリティの考慮事項を追加しません。

8. IANA Considerations
8. IANAに関する考慮事項

A new DHCPv6 Option Code has been reserved from the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry for DHCP Option Codes.

新しいDHCPv6オプションコードは、DHCPオプションコードの「IPv6の動的ホスト構成プロトコル(DHCPv6)」レジストリから予約されています。

OPTION_PD_EXCLUDE (67)

OPTION_PD_EXCLUDE(67)

9. Acknowledgements
9. 謝辞

The authors would like to thank Ralph Droms, Frank Brockners, Ted Lemon, Julien Laganier, Fredrik Garneij, Sri Gundavelli, Mikael Abrahamsson, Behcet Sarikaya, Jyrki Soini, Deng Hui, Stephen Jacob, Hemant Singh, Gaurav Halwasia, Lorenzo Colitti, and Tomasz Mrugalski for their valuable comments and discussions.

著者は、ラルフ・ドロムス、フランク・ブロックナーズ、テッド・レモン、ジュリアン・ラガニア、フレドリク・ガルネイ、スリ・グンダヴェリ、ミカエル・アブラハムソン、ベーチェット・サリカヤ、ジルキ・ソイニ、デング・ホイ、スティーブン・ジェイコブ、ヘマント・シン、ガウラフ・ハルワティア、ロレンツ・コリッツ、ロゾ・コリッツ彼らの貴重なコメントと議論のためのムルガルスキ。

10. References
10. 参考文献
10.1. Normative References
10.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6(DHCPv6)"、RFC 3315 、2003年7月。

[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル(DHCP)バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。

10.2. Informative References
10.2. 参考引用

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。

Authors' Addresses

著者のアドレス

Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland

Jouni Korhonen(編集者)Nokia Siemens Networks Linnoitustie 6 FI-02600 Espooフィンランド

   EMail: jouni.nospam@gmail.com
        

Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland

Teemu Savolainen Nokia Hermiankatu 12 D FI-33720タンペレフィンランド

   EMail: teemu.savolainen@nokia.com
        

Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada

Suresh Krishnan Ericsson 8400 Decarie Blvd.マウントロイヤルの町、QCカナダ

   EMail: suresh.krishnan@ericsson.com
        

Ole Troan Cisco Systems, Inc Oslo Norway

Ole Troan Cisco Systems、Incオスロノルウェー

   EMail: ot@cisco.com