Network Working Group G. Van de Velde
Request for Comments: 5375 C. Popoviciu
Category: Informational Cisco Systems
T. Chown
University of Southampton
O. Bonness
C. Hahn
T-Systems Enterprise Services GmbH
December 2008
IPv6 Unicast Address Assignment Considerations
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network.
任意のIP通信インフラの1つの基本的な側面は、そのアドレス計画です。その新しいアドレスアーキテクチャおよび割り当てポリシーでは、ネットワークへのIPv6の導入は、ネットワーク設計者と事業者が取り組むネットワークへの既存のアプローチを再考する必要があることを意味します。ネットワーク設計のこの局面の取り扱いに関するガイドラインの欠如は、IPv6の展開と統合を遅らせることができます。この文書は、IPv6展開のアドレッシング側面を計画に関連する情報や推奨事項を提供することを目的とします。文書はまた、IPv6が企業やISPネットワークの両方のためのケーススタディをアドレッシング提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network-Level Addressing Design Considerations . . . . . . . . 4
2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 4
2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5
2.3. 6bone Address Space . . . . . . . . . . . . . . . . . . . 6
2.4. Network-Level Design Considerations . . . . . . . . . . . 6
2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8
2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8
3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8
3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10
4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 10
4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 10
4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 10
4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 16
A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 16
A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16
A.1.2. Forming an Address (Subnet) Allocation Plan . . . . . 17
A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 18
A.1.4. Node Configuration Considerations . . . . . . . . . . 18
A.2. Service Provider Considerations . . . . . . . . . . . . . 19
A.2.1. Investigation of Objective Requirements for an
IPv6 Addressing Schema of a Service Provider . . . . . 19
A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider . . . . . . . . . . . . . . . . . . . 23
A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 28
Appendix B. Considerations for Subnet Prefixes Different than
/64 . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Considerations for Subnet Prefixes Shorter than /64 . . . 30
B.2. Considerations for Subnet Prefixes Longer than /64 . . . . 31
B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 31
B.2.4. EUI-64 'u' and 'g' Bits . . . . . . . . . . . . . . . 31
B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 32
B.2.6. Addresses Used by Embedded-RP (RFC 3956) . . . . . . . 33
B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 34
The Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC4291] defines three main types of addresses: unicast, anycast, and multicast. This document focuses on unicast addresses, for which there are currently two principal allocated types: Globally Unique Addresses ('globals') [RFC3587] and Unique Local IPv6 Addresses (ULAs) [RFC4193]. In addition, until recently there has been the 'experimental' 6bone address space [RFC3701], though its use has been deprecated since June 2006 [RFC3701].
ユニキャスト、エニーキャスト、及びマルチキャストインターネットプロトコルバージョン6（IPv6）のアドレス体系[RFC4291]はアドレスの3つのタイプを定義します。グローバルに一意なアドレス（「グローバル」）[RFC3587]と一意のローカルIPv6アドレス（ULAs）[RFC4193]：この文書は、現在、2つの主要な割り当てタイプがあるれるユニキャストアドレス、に焦点を当てています。その使用は、2006年6月[RFC3701]以降廃止されているもののほか、最近まで、「実験」の6boneアドレス空間[RFC3701]がありました。
The document covers aspects that should be considered during IPv6 deployment for the design and planning of an addressing scheme for an IPv6 network. The network's IPv6 addressing plan may be for an IPv6- only network, or for a dual-stack infrastructure where some or all devices have addresses in both protocols. These considerations will help an IPv6 network designer to efficiently and prudently assign the IPv6 address space that has been allocated to their organization.
文書は、IPv6ネットワークのアドレス指定方式の設計と計画のためのIPv6展開時に考慮すべき側面をカバーしています。ネットワークのIPv6アドレス計画はIPv6-唯一のネットワークのため、一部またはすべてのデバイスは、両方のプロトコルのアドレスを持っているデュアルスタックインフラためのものであってもよいです。これらの考慮事項は、IPv6ネットワークの設計者は、効率的かつ慎重に自分の組織に割り当てられたIPv6アドレス空間を割り当てるのに役立ちます。
The address assignment considerations are analyzed separately for the two major components of the IPv6 unicast addresses -- namely, 'Network-Level Addressing' (the allocation of subnets) and the 'interface-id' (the identification of the interface within a subnet). Thus, the document includes a discussion of aspects of address assignment to nodes and interfaces in an IPv6 network. Finally, the document provides two examples of deployed addressing plans in a service provider (ISP) and an enterprise network.
すなわち、（サブネットの割り当て）「ネットワークレベルのアドレッシング」および「インタフェースID」（サブネット内のインターフェースの識別） - アドレス割り当ての考慮事項は、IPv6ユニキャストアドレスの2つの主要コンポーネントのために別々に分析されます。したがって、文書は、IPv6ネットワークのノードとインターフェースへのアドレス割り当ての態様の説明を含みます。最後に、文書は、サービス・プロバイダ（ISP）と企業ネットワーク内に展開アドレッシング計画の2つの例を提供します。
Parts of this document highlight the differences that an experienced IPv4 network designer should consider when planning an IPv6 deployment, for example:
このドキュメントの一部は、たとえば、IPv6の展開を計画する際に、経験豊富なIPv4ネットワークの設計者が考慮すべきことの違いを強調します：
o IPv6 devices will more likely be multi-addressed in comparison with their IPv4 counterparts.
O IPv6デバイスは、より多くの可能性が高い彼らのIPv4対応と比較して、マルチ対処されることになります。
o The practically unlimited size of an IPv6 subnet (2^64 bits) reduces the requirement to size subnets to device counts for the purposes of (IPv4) address conservation.
O IPv6サブネット（2 ^ 64ビット）の実質的に無制限のサイズは（IPv4）のアドレス保全の目的のためのデバイス数にサイズサブネットへの要求を低減します。
o The vastly increased subnet size has implications on the threat of address-based host scanning and other scanning techniques, as discussed in [RFC5157].
大幅に増加したサブネットサイズO [RFC5157]で説明したように、アドレスベースのホスト走査と他の走査技術の脅威に影響を有します。
We do not discuss here how a site or ISP should proceed with acquiring its globally routable IPv6 address prefix. In each case, the prefix received is either provider assigned (PA) or provider independent (PI).
私たちは、サイトやISPは、そのグローバルにルーティング可能なIPv6アドレスプレフィックスを取得を進めるべきか、ここで議論していません。それぞれの場合に、受信された接頭辞は、プロバイダ割り当て（PA）またはプロバイダ独立（PI）のいずれかです。
We do not discuss PI policy here. The observations and recommendations of this text are largely independent of the PA or PI nature of the address block being used. At this time, we assume that when an IPv6 network changes provider, typically it will need to undergo a renumbering process, as described in [RFC4192]. A separate document [THINKABOUT] makes recommendations to ease the IPv6 renumbering process.
ここではPIの方針を議論していません。このテキストの所見および勧告は、PAまたは使用されているアドレスブロックのPIの性質に大部分が独立しています。現時点では、IPv6ネットワークプロバイダを変更したときに、[RFC4192]で説明したように、一般的には、リナンバリングプロセスを経る必要があることを前提としています。別の文書は[THINKABOUT]のIPv6リナンバリング処理を容易にする勧告を行います。
This document does not discuss implementation aspects related to the transition from the now obsoleted site-local addresses to ULAs. Some implementations know about site-local addresses even though they are deprecated, and do not know about ULAs even though they represent current specification. As a result, transitioning between these types of addresses may cause difficulties.
この文書は現在廃止サイトローカルアドレスからULAsへの移行に関連する実装の側面を議論していません。一部の実装では、彼らが廃止され、そして、彼らは現在の仕様を表していてもULAs知らないにもかかわらず、サイトローカルアドレスを知っています。その結果、アドレスのこれらのタイプの間の移行は困難を引き起こす可能性があります。
This section discusses the kind of IPv6 addresses used at the network level for the IPv6 infrastructure. The kind of addresses that can be considered are Globally Unique Addresses and ULAs. We also comment here on the deprecated 6bone address space.
このセクションでは、IPv6インフラストラクチャのネットワークレベルで使用されるIPv6アドレスの種類を論じています。考えることができるアドレスの種類は、グローバルに一意なアドレスとULAsです。我々はまた、非推奨の6boneアドレス空間上でここにコメントします。
The most commonly used unicast addresses will be Globally Unique Addresses ('globals'). No significant considerations are necessary if the organization has an address space assignment and a single prefix is deployed through a single upstream provider.
最も一般的に使用されるユニキャストアドレスは、グローバルに一意なアドレス（「グローバル」）となります。組織は、アドレス空間の割り当てを持っており、単一のプレフィックスを単一の上流のプロバイダを介して展開された場合に有意な配慮は必要ありません。
However, a multihomed site may deploy addresses from two or more service-provider-assigned IPv6 address ranges. Here, the network administrator must have awareness on where and how these ranges are used on the multihomed infrastructure environment. The nature of the usage of multiple prefixes may depend on the reason for multihoming (e.g., resilience failover, load balancing, policy-based routing, or multihoming during an IPv6 renumbering event). IPv6 introduces improved support for multi-addressed hosts through the IPv6 default address selection methods described in RFC 3484 [RFC3484]. A multihomed host may thus have two or more addresses, one per prefix (provider), and select source and destination addresses to use as described in that RFC. However, multihoming also has some operational and administrative burdens besides choosing multiple addresses per interface [RFC4218] [RFC4219].
しかし、マルチホームのサイトは、二つ以上のサービスプロバイダーによって割り当てられたIPv6アドレス範囲からアドレスを配備することがあります。ここでは、ネットワーク管理者は、どこでどのようにこれらの範囲は、マルチホームのインフラ環境で使用されているの意識を持っている必要があります。複数のプレフィックスの使用の性質（例えば、弾性フェイルオーバー、ロードバランシング、IPv6のリナンバリングイベント中に、ポリシーベースのルーティング、またはマルチホーミング）をマルチホーミングのための理由に依存してもよいです。 IPv6は、RFC 3484 [RFC3484]に記載のIPv6デフォルトアドレス選択方法を介してマルチ対処ホストするための改良されたサポートを導入します。マルチホームホストは、したがって、2つの以上のアドレス、プレフィックス（プロバイダ）に1つずつあり、そのRFCに記載されているように使用する送信元アドレスと宛先アドレスを選択してもよいです。しかし、マルチホーミングは、インタフェースごとに複数のアドレスを選択する以外にも、いくつかの運用や管理の負担を持っている[RFC4218] [RFC4219]。
ULAs have replaced the originally conceived site-local addresses in the IPv6 addressing architecture, for reasons described in [RFC3879]. ULAs improve on site-locals by offering a high probability of the global uniqueness of the prefix used, which can be beneficial when there is (deliberate or accidental) leakage or when networks are merged. ULAs are akin to the private address space [RFC1918] assigned for IPv4 networks, except that in IPv6 networks we may expect to see ULAs used alongside global addresses, with ULAs used internally and globals used externally. Thus, use of ULAs does not imply use of NAT for IPv6.
ULAsは、[RFC3879]で説明した理由のために、IPv6のアドレス体系で、もともと構想サイトローカルアドレスを交換しました。 ULAsは（意図的または偶発）漏洩時やネットワークがマージされがある場合に有益であることができ、使用するプレフィックスのグローバルな一意の高い確率を提供することにより、サイト地元の人々に向上させます。 ULAsは、IPv6ネットワークでのことを除いて、我々はULAsが内部的に使用してグローバルが外部で使用してULAsは、グローバルアドレスと一緒に使用見ることを期待して、IPv4ネットワーク用に割り当てられたプライベートアドレス空間[RFC1918]に似ています。このように、ULAsの使用は、IPv6のためのNATの使用を意味するものではありません。
The ULA address range allows network administrators to deploy IPv6 addresses on their network without asking for a globally unique registered IPv6 address range. A ULA prefix is 48 bits, i.e., a /48, the same as the currently recommended allocation for a site from the globally routable IPv6 address space [RFC3177].
ULAアドレス範囲は、ネットワーク管理者は、グローバルに一意の登録IPv6アドレス範囲を求めずに、ネットワーク上のIPv6アドレスを展開することができます。 ULAプリフィックスは48ビット、すなわち、/ 48、グローバルにルーティング可能なIPv6のアドレス空間からサイトの現在推奨割当[RFC3177]と同じです。
A site that wishes to use ULAs can have (a) multiple /48 prefixes (e.g., a /44) (b) one /48, or (c) a less-than-/48 prefix (e.g., a /56 or /64). In all of the above cases, the ULAs can be randomly chosen according to the principles specified in [RFC4193]. However, in case (a) the use of randomly chosen ULAs will provide suboptimal aggregation capabilities.
ULAs（a）は、複数の/ 48プレフィックスを有することができ、使用したい部位（例えば、/ 44）（b）は、1/48、または（c）より少ない-than- / 48プレフィックス（例えば、/ 56 /又は64）。上記の場合の全てにおいて、ULAsがランダム[RFC4193]で指定された原理に従って選択することができます。しかし、ケース（a）においてランダムに選択されたULAsの使用は、次善の集約機能を提供します。
ULAs provide the means to deploy a fixed addressing scheme that is not affected by a change in service provider and the corresponding PA global addresses. Internal operation of the network is thus unaffected during renumbering events. Nevertheless, this type of address must be used with caution.
ULAsは、サービスプロバイダと対応するPAグローバルアドレスの変化に影響されない固定アドレス方式を導入するための手段を提供します。ネットワークの内部動作は、イベントをリナンバリング中のため、影響はありません。それにもかかわらず、このタイプのアドレスは慎重に使用する必要があります。
A site using ULAs may or may not also deploy global addresses. In an isolated network, ULAs may be deployed on their own. In a connected network that also deploys global addresses, both may be deployed, such that hosts become multi-addressed (one global and one ULA), and the IPv6 default address selection algorithm will pick the appropriate source and destination addresses to use, e.g., ULAs will be selected where both the source and destination hosts have ULAs. Because a ULA and a global site prefix are both /48 length, an administrator can choose to use the same subnetting (and host addressing) plan for both prefixes.
ULAsを使用してサイトには、あるいはまた、グローバルアドレスを展開しない場合があります。分離されたネットワークでは、ULAsは自分の上に配備することができます。また、グローバルアドレスを展開し、接続されたネットワークでは、両方のホストが（一つのグローバル一ULA）のマルチアドレス指定となり、IPv6デフォルトアドレス選択アルゴリズムは、例えば、使用する適切なソースおよび宛先アドレスを選択し、そのようなことは、展開されてもよいです両方のソースと宛先ホストがULAsを有する場合ULAsが選択されます。 ULAとグローバルサイトプレフィックスは両方/ 48の長さであるため、管理者は、同じサブネット（およびホストのアドレス指定）の両方のプレフィックスのための計画を使用するように選択することができます。
As an example of the problems ULAs may cause, when using IPv6 multicast within the network, the IPv6 default address selection algorithm prefers the ULA as the source address for the IPv6 multicast streams. This is NOT a valid option when sending an IPv6 multicast stream to the IPv6 Internet for two reasons. For one, these addresses are not globally routable, so Reverse Path Forwarding checks for such traffic will fail outside the internal network. The other reason is that the traffic will likely not cross the network boundary due to multicast domain control and perimeter security policies.
ネットワーク内のIPv6マルチキャストを使用する場合ULAsは、原因となる可能性のある問題の一例として、IPv6のデフォルトのアドレス選択アルゴリズムは、IPv6マルチキャストストリームの送信元アドレスとしてULAを好みます。二つの理由からIPv6インターネットへのIPv6マルチキャストストリームを送信するとき、これは有効なオプションではありません。一つは、これらのアドレスは、グローバルにルーティングできませんので、このようなトラフィックは、内部ネットワークの外に失敗するためにパス転送のチェックを逆にします。もう一つの理由は、トラフィックの可能性が高いため、マルチキャストドメイン制御と境界セキュリティポリシーにネットワークの境界を越えないであろうということです。
In principle, ULAs allow easier network mergers than RFC 1918 addresses do for IPv4 because ULA prefixes have a high probability of uniqueness, if the prefix is chosen as described in the RFC.
原則として、ULAsはRFCで説明したように接頭辞を選択した場合ULAプレフィックスは、一意の高い確率を持っているので、RFCよりも簡単にネットワークの合併1918のアドレスがIPv4のために行うことができます。
The 6bone address space was used before the Regional Internet Registries (RIRs) started to distribute 'production' IPv6 prefixes. The 6bone prefixes have a common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address range has been deprecated as of 6 June 2006 [RFC3701] and must not be used on any new IPv6 network deployments. Sites using 6bone address space should renumber to production address space using procedures as defined in [RFC4192].
地域インターネットレジストリ（RIRが）は「生産」のIPv6プレフィックスを配布するために開始する前の6boneアドレス空間を使用しました。 6boneのプレフィックスは3FFEのIPv6のプレフィックス:: / 16で共通の最初の16ビットを有します。このアドレス範囲は、2006年6月6日[RFC3701]のよう推奨されていませんし、新しいIPv6ネットワークの展開に使用することはできません。 [RFC4192]で定義されるように6boneのアドレス空間を使用してサイトでは手順を用いて製造アドレス空間に再番号付けなければなりません。
IPv6 provides network administrators with a significantly larger address space, enabling them to be very creative in how they can define logical and practical addressing plans. The subnetting of assigned prefixes can be done based on various logical schemes that involve factors such as:
IPv6は、彼らは論理的かつ実践的な対処する計画を定義することができますどのように非常に創造することを可能、かなり大きなアドレス空間をネットワーク管理者に提供します。割り当てられたプレフィックスのサブネットは、以下のような要因が関与する様々な論理体系に基づいて行うことができます。
o Using existing systems
既存のシステムを使用して、O
* translate the existing subnet numbers into IPv6 subnet IDs
*のIPv6サブネットIDに既存のサブネット番号を翻訳
* translate the VLAN IDs into IPv6 subnet IDs
*のIPv6サブネットIDにVLAN IDを変換します
o Redesign
O再設計
* allocate according to your need
*あなたの必要性に応じて割り当てます
o Aggregation
お あっｇれがちおん
* Geographical Boundaries - by assigning a common prefix to all subnets within a geographical area.
*地理的な境界 - 地理的領域内のすべてのサブネットに共通のプレフィックスを割り当てること。
* Organizational Boundaries - by assigning a common prefix to an entire organization or group within a corporate infrastructure.
*組織の境界 - 企業インフラストラクチャ内組織全体やグループに共通のプレフィックスを割り当てることもできます。
* Service Type - by reserving certain prefixes for predefined services such as: VoIP, content distribution, wireless services, Internet access, security areas, etc. This type of addressing may create dependencies on IP addresses that can make renumbering harder if the nodes or interfaces supporting those services on the network are sparse within the topology.
*サービスの種類 - など、事前に定義されたサービスのために特定のプレフィックスを予約することによって：などのVoIP、コンテンツ配信、無線サービス、インターネットアクセス、セキュリティエリア、困難リナンバリング作ることができるIPアドレスの依存関係を作成することが対処するこのタイプのノードまたはインタフェースの場合ネットワーク上のこれらのサービスをサポートするトポロジ内まばらで。
Such logical addressing plans have the potential to simplify network operations and service offerings, and to simplify network management and troubleshooting. A very large network would not need to consider using private address space for its infrastructure devices, thereby simplifying network management.
このような論理アドレス指定の計画は、ネットワークの運用とサービスの提供を簡素化するため、ネットワーク管理とトラブルシューティングを簡素化する可能性を秘めています。非常に大規模なネットワークでは、これによりネットワーク管理を簡素化し、そのインフラストラクチャデバイスのためのプライベートアドレス空間を使用することを検討する必要はありません。
The network designer must however keep in mind several factors when developing these new addressing schemes for networks with and without global connectivity:
ネットワークのためのこれらの新しいアドレス指定方式を開発する際にネットワーク設計者は、しかし、グローバルな接続をしてなくて心の中でいくつかの要因を維持する必要があります。
o Prefix aggregation - The larger IPv6 addresses can lead to larger routing tables unless network designers are actively pursuing aggregation. While prefix aggregation will be enforced by the service provider, it is beneficial for the individual organizations to observe the same principles in their network design process.
Oプレフィックス集約 - ネットワーク設計者が積極的に凝集を追求している場合を除き大きなIPv6のアドレスは、より大きなルーティングテーブルにつながることができます。プレフィックス集約は、サービスプロバイダによって実施されますが、それは彼らのネットワークの設計プロセスで同じ原則を遵守するために、個々の組織にとって有益です。
o Network growth - The allocation mechanism for flexible growth of a network prefix, documented in RFC 3531 [RFC3531] can be used to allow the network infrastructure to grow and be numbered in a way that is likely to preserve aggregation (the plan leaves 'holes' for growth).
Oネットワークの成長 - ネットワークプレフィックスの柔軟な成長のための割り当て機構、RFC 3531 [RFC3531]に記載さは、ネットワークインフラストラクチャが成長し、凝集（平面葉「孔を維持しやすいように番号付け可能にするために使用することができます'）成長のため。
o ULA usage in large networks - Networks that have a large number of 'sites' that each deploy a ULA prefix that will by default be a 'random' /48 under fc00::/7 will have no aggregation of those prefixes. Thus, the end result may be cumbersome because the network will have large amounts of non-aggregated ULA prefixes. However, there is no rule to disallow large networks from using a single ULA prefix for all 'sites', as a ULA still provides 16 bits for subnetting to be used internally.
O大規模ネットワークにおけるULAの使用 - それぞれがデフォルトでFC00の下で「ランダム」/ 48になりますULAプリフィックスを展開[サイト]の数が多いネットワーク:: / 7は、これらの接頭辞のない凝集を持ちません。ネットワークが非凝集ULAプリフィックスを大量に有することになるので、これにより、最終的な結果は、面倒であってもよいです。 ULAはまだ内部的に使用されるサブネットのための16ビットを提供しかし、すべてのサイト 'のシングルULAプリフィックスを使用してから大規模ネットワークを禁止するいかなるルールは、ありません。
o Compact numbering of small sites - It is possible that as registry policies evolve, a small site may experience an increase in prefix length when renumbering, e.g., from /48 to /56. For this reason, the best practice is to number subnets compactly rather than sparsely, and to use low-order bits as much as possible when numbering subnets. In other words, even if a /48 is allocated, act as though only a /56 is available. Clearly, this advice does not apply to large sites and enterprises that have an intrinsic need for a /48 prefix.
O小規模サイトのコンパクトナンバリングは、 - レジストリポリシーが進化すると、小さなサイトは/ 48から/ 56に、例えば、リナンバリングプレフィックス長の増加を経験することが可能です。このため、ベストプラクティスは、コンパクトではなく、まばら数のサブネットにある、とサブネットをナンバリングするとき、できるだけ下位ビットを使用します。換言すれば、偶数/ 48場合のみ/ 56が利用可能であるかのように作用し、割り当てられています。明らかに、このアドバイスは/ 48のプレフィックスのための本質的な必要性を持っている大規模なサイトや企業には適用されません。
o Consider assigning more than one /64 to a site - A small site may want to enable routing amongst interfaces connected to a gateway device. For example, a residential gateway that receives a /48 and is situated in a home with multiple LANs of different media types (sensor network, wired, Wi-Fi, etc.), or has a need for traffic segmentation (home, work, kids, etc.), could benefit greatly from multiple subnets and routing in IPv6. Ideally, residential networks would be given an address range of a /48 or /56 [RIPE_Nov07] such that multiple /64 subnets could be used within the residence.
Oサイトに複数の/ 64を割り当てることを検討 - 小サイトは、ゲートウェイ装置に接続されたインターフェース間のルーティング有効にすることができます。 / 48を受信して、異なるメディアタイプ（センサーネットワークなどの有線、のWi-Fi、）の複数のLANと一緒に家に位置し、またはトラフィックセグメンテーション（自宅、仕事の必要性を有する。例えば、住宅用ゲートウェイ、子供たちは、など）、IPv6における複数のサブネットとルーティングから大きな利益を得ることができます。理想的には、住宅のネットワークは、複数の/ 64サブネットが住居内で使用することができるように、[RIPE_Nov07] / 48または/ 56のアドレス範囲を与えられるであろう。
We do not discuss here how a network designer sizes their application for address space. By default, a site will receive a /48 prefix [RFC3177]; however, different RIR service regions policies may suggest alternative default assignments or let the ISPs decide on what they believe is more appropriate for their specific case (see Section 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]). The default provider allocation via the RIRs is currently a /32 [RIPE_Nov07]. These allocations are indicators for a first allocation for a network. Different sizes may be obtained based on the anticipated address usage [RIPE_Nov07]. At the time of writing, there are examples of allocations as large as /19 having been made from RIRs to providers.
ネットワーク設計者がアドレス空間への応用のサイズどのように我々はここでは説明しません。デフォルトでは、サイトには、/ 48プレフィックス[RFC3177]を受信します。しかし、別のRIRのサービス領域のポリシーは、代替デフォルトの割り当てを提案したり、彼らが特定のケースのためのより適切であると考えているものにISPが決めさせて（の[ARIN]、「のLIR / ISPのからの割り当て」、6.5.4項を参照してください）。 RIRを介しデフォルトプロバイダの割り当ては、[RIPE_Nov07]現在/ 32です。これらの割り当ては、ネットワークのための第1の割り当てのための指標です。異なるサイズは、予想されるアドレスの使用[RIPE_Nov07]に基づいて得られてもよいです。執筆時点では、プロバイダへのRIRから作られた19 /ほど大きな割り当ての例があります。
Despite the large IPv6 address space, which enables easier subnetting, it still is important to ensure an efficient use of this resource. Some addressing schemes, while facilitating aggregation and management, could lead to significant numbers of addresses being unused. Address conservation requirements are less stringent in IPv6, but they should still be observed.
簡単にサブネットを可能に大型のIPv6アドレス空間にもかかわらず、まだこのリソースの効率的な利用を確保することが重要です。集約と管理を容易にしつつ、いくつかのアドレス指定方式は、アドレスが未使用であることのかなりの数につながる可能性があります。住所保全の要件は、IPv6にそれほど厳しくない、彼らはまだ観測されなければなりません。
The proposed Host-Density (HD) value [RFC3194] for IPv6 is 0.94 compared to the current value of 0.96 for IPv4. Note that with IPv6, HD is calculated for sites (e.g., on a basis of /56), instead of for addresses as with IPv4.
IPv6のための提案されたホスト高密度（HD）値[RFC3194]はIPv4の0.96の現在の値と比較し0.94です。 IPv6で、HDは、サイトに対して計算されることに留意されたい（例えば、/ 56に基づいて）、代わりにIPv4の場合と同様にアドレスについて。
An important part of an IPv4 addressing plan is deciding the length of each subnet prefix. Unlike in IPv4, the IPv6 addressing architecture [RFC4291] specifies that all subnets using Globally Unique Addresses and ULAs always have the same prefix length of 64 bits. (This also applies to the deprecated 6bone and site-local addresses.)
IPv4アドレス指定計画の重要な部分は、各サブネットプレフィックスの長さを決めています。 IPv4の場合とは異なり、IPv6のアドレス体系[RFC4291]はグローバルに一意なアドレスとULAsを使用してすべてのサブネットは、常に64ビットの同じプレフィックス長を有することを指定します。 （また、これは非推奨の6boneとサイトローカルアドレスに適用されます。）
The only exception to this rule are special addresses starting with the binary value 000, such as IPv4-compatible IPv6 addresses. These exceptions are largely beyond the scope of this document.
このルールの唯一の例外は、IPv4互換IPv6アドレスのようなバイナリ値000で始まる特別なアドレスです。これらの例外は、主に、このドキュメントの範囲を超えています。
Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.
/ 64以外のサブネットプレフィックス長を使用すると、近隣探索（ND）、セキュア近隣探索（SEND）[RFC3971]、プライバシーの拡張[RFC4941]、モバイルIPv6の部品[RFC4866]、プロトコル独立含めたIPv6の多くの機能を、解除されますマルチキャスト - とりわけ希薄モード埋め込み-RP [RFC3956]と（PIM-SM）、およびIPv6仲介によるサイトマルチホーミング（SHIM6）SHIM6]。現在開発中の他の特徴の数は、あるいはまた、/ 64サブネット・プレフィックスに依存して、提案されています。
Nevertheless, many IPv6 implementations do not prevent the administrator from configuring a subnet prefix length shorter or longer than 64 bits. Using subnet prefixes shorter than /64 would rarely be useful; see Appendix B.1 for discussion.
それにもかかわらず、多くのIPv6実装は、64ビットより短いか長いサブネットプレフィックス長を設定から管理者を防ぐことはできません。より/ 64短いサブネットプレフィックスを使用すると、稀に役立つことないだろう。議論は、付録B.1を参照してください。
However, some network administrators have used prefixes longer than /64 for links connecting routers, usually just two routers on a point-to-point link. On links where all the addresses are assigned by manual configuration, and all nodes on the link are routers (not end hosts) that are known by the network, administrators do not need any of the IPv6 features that rely on /64 subnet prefixes, this can work. Using subnet prefixes longer than /64 is not recommended for general use, and using them for links containing end hosts would be an especially bad idea, as it is difficult to predict what IPv6 features the hosts will use in the future.
ただし、一部のネットワーク管理者は、ポイントツーポイントリンク上のルータ、通常はちょうど2台のルータを接続するリンクのためのより/ 64長い接頭辞を使用していました。すべてのアドレスを手動設定によって割り当てられ、リンク上のすべてのノードがネットワークによって知られているルータ（ホストを終了していない）、管理者が/ 64サブネットプレフィックスに依存しているのIPv6機能のいずれかを必要としないされているリンクでは、この働ける。より/ 64長いサブネットプレフィックスを使用すると、一般的な使用は推奨されていない、そしてIPv6がホストが、将来的に使用するどの機能を予測することは困難であるとして、エンドホストを含むリンクのためにそれらを使用すると、特に悪いアイデアだろう。
Appendix B.2 describes some practical considerations that need to be taken into account when using prefixes longer than /64 in limited cases. In particular, a number of IPv6 features use interface identifiers that have a special form (such as a certain fixed value in some bit positions). When using prefixes longer than /64, it is prudent to avoid certain subnet prefix values so that nodes who assume that the prefix is /64 will not incorrectly identify the addresses in that subnet as having a special form. Appendix B.2 describes the subnet prefix values that are currently believed to be potentially problematic; however, the list is not exhaustive and can be expected to grow in the future.
付録B.2は、限られた場合に比べ/ 64長い接頭辞を使用する際に考慮する必要があるいくつかの実用的な考慮事項について説明します。特に、IPv6の数は（例えば、いくつかのビット位置にある一定の値のような）特殊な形状を有していて、使用インタフェース識別子を特徴とします。より/ 64より長いプレフィックスを使用する場合は、接頭辞が/ 64であると仮定し、ノードが誤って特殊な形状を有するように、そのサブネット内のアドレスを識別しないように特定のサブネットプレフィックス値を避けるために賢明です。付録B.2は現在、潜在的に問題があると考えられているサブネットプレフィックス値を示します。しかし、リストは網羅的なものではなく、今後の成長が期待できます。
Using /64 subnets is strongly recommended, also for links connecting only routers. A deployment compliant with the current IPv6 specifications cannot use other prefix lengths. However, the V6OPS WG believes that despite the drawbacks (and a potentially expensive network redesign, if IPv6 features relying on /64 subnets are needed in the future), some networks administrators will use prefixes longer than /64.
/ 64サブネットを使用することを強くルータのみを接続するリンクのためにも、お勧めします。現在のIPv6仕様に準拠した展開は、他のプレフィックス長を使用することはできません。しかし、V6OPS WGは、（IPv6が将来的に必要とされている/ 64のサブネットに頼っています場合には、潜在的に高価なネットワークの再設計、）の欠点にもかかわらず、一部のネットワーク管理者が/ 64より長いプレフィックスを使用することを考えています。
Based on RFC 3177 [RFC3177], 64 bits is the prescribed subnet prefix length to allocate to interfaces and nodes.
RFC 3177 [RFC3177]に基づいて、64ビットインタフェースとノードに割り当てる所定のサブネットプレフィックス長です。
When using a /64 subnet length, the address assignment for these addresses can be made either by manual configuration, by a Dynamic Host Configuration Protocol [RFC3315], by stateless autoconfiguration [RFC4862], or by a combination thereof [RFC3736].
/ 64サブネット長を使用する場合、これらのアドレスのためのアドレス割り当ては、手動設定によって、動的ホスト構成プロトコル[RFC3315]で、ステートレス自動[RFC4862]によって、またはそれらの組み合わせ[RFC3736]のいずれかによって製造することができます。
Note that RFC 3177 strongly prescribes 64-bit subnets for general usage, and that stateless autoconfiguration on most link layers (including Ethernet) is only defined for 64-bit subnets. While in theory it might be possible that some future autoconfiguration mechanisms would allow longer than 64-bit prefix lengths to be used, the use of such prefixes is not recommended at this time.
そのRFC 3177強く一般的な使用のための64ビットのサブネットを規定し、（イーサネット（登録商標）を含む）が最もリンク層上のステートレス自動設定のみの64ビットのサブネットのために定義されます。理論的には、それはいくつかの将来の自動設定メカニズムが使用される64ビットのプレフィックス長よりも長いことが可能になることは可能かもしれないが、そのような接頭語の使用は、現時点では推奨されません。
In order to have a complete IPv6 address, an interface must be associated with a prefix and an Interface Identifier (IID). Section 3 of this document analyzed the prefix selection considerations. This section discusses the elements that should be considered when assigning the IID portion of the IPv6 address.
完全なIPv6アドレスを有するために、インターフェースは、接頭辞とインターフェース識別子（IID）と関連付けられなければなりません。このドキュメントのセクション3は、プレフィックス選択の考慮事項を分析しました。このセクションでは、IPv6アドレスのIID部分を割り当てる際に考慮すべき要素について説明します。
There are various ways to allocate an IPv6 address to a device or interface. The option with the least amount of caveats for the network administrator is that of EUI-64 [RFC4862] based addresses. For the manual or dynamic options, the overlap with well-known IPv6 addresses should be avoided.
デバイスまたはインターフェイスにIPv6アドレスを割り当てるためのさまざまな方法があります。ネットワーク管理者のための警告の最小量を持つオプションは、EUI-64 [RFC4862]ベースアドレスのことです。手動または動的オプションについては、よく知られているIPv6アドレスとの重複は避けるべきです。
When using this method, the network administrator has to allocate a valid 64-bit subnet prefix. Once that allocation has been made, the EUI-64 [RFC4862] allocation procedure can assign the remaining 64 IID bits in a stateless manner. All the considerations for selecting a valid IID have been incorporated into the EUI-64 methodology.
この方法を使用する場合は、ネットワーク管理者は、有効な64ビットのサブネットプレフィックスを割り当てなければなりません。その割り当てがなされた後、EUI-64 [RFC4862]割当て手順はステートレスな方法で、残りの64個のIIDビットを割り当てることができます。有効なIIDを選択するためのすべての考慮事項は、EUI-64の方法論に組み込まれています。
The main purpose of IIDs generated based on RFC 4941 [RFC4941] is to provide privacy to the entity using an IPv6 address. While there are no particular constraints in the usage of IPv6 addresses with IIDs as defined in [RFC4941], there are some implications to be aware of when using privacy addresses as documented in Section 4 of RFC 4941 [RFC4941]
IIDの主な目的は、RFC 4941 [RFC4941]に基づいて生成されたIPv6アドレスを使用してエンティティにプライバシーを提供することです。 IPv6の使用には特に制約されないが、[RFC4941]で定義されるようにRFC 4941 [RFC4941]のセクション4に記載のようにプライバシーアドレスを使用するときに注意すべきいくつかの含意がある、のIIDとアドレス
This section discusses those IID allocations that are not implemented through stateless address configuration (Section 4.1). They are applicable regardless of the prefix length used on the link. It is out of scope for this section to discuss the various assignment methods (e.g., manual configuration, DHCPv6, etc).
このセクションでは、ステートレスアドレス構成（4.1節）を介して実装されていないものIID割り当てを論じています。彼らは関係なく、リンク上で使用されるプレフィックス長の適用されます。これは、（例えば、手動設定、DHCPv6の、など）様々な割り当て方法を議論するために、このセクションの範囲外です。
In this situation, the actual allocation is done by human intervention, and consideration needs to be given to the complete IPv6 address so that it does not result in overlaps with any of the well-known IPv6 addresses:
このような状況では、実際の割り当ては、人間の介入によって行われ、そしてそれは、よく知られたIPv6アドレスのいずれかと重複が生じないように考慮すべき点は、完全なIPv6アドレスに与えられる必要があります。
o Subnet Router Anycast Address (Appendix B.2.5.1)
Oサブネットルータエニーキャストアドレス（付録B.2.5.1）
o Reserved Subnet Anycast Address (Appendix B.2.5.2)
O予約サブネットエニーキャストアドレス（付録B.2.5.2）
o Addresses used by Embedded-RP (Appendix B.2.6)
組み込み-RPで使用されるOアドレス（付録B.2.6）
o Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Addresses (Appendix B.2.7)
Oイントラサイト自動トンネルアドレス指定プロトコル（ISATAP）アドレス（付録B.2.7）
When using an address assigned by human intervention, it is recommended to choose IPv6 addresses that are not obvious to guess and/or to avoid any IPv6 addresses that embed IPv4 addresses used in the current infrastructure. Following these two recommendations will make it more difficult for malicious third parties to guess targets for attack, and thus reduce security threats to a certain extent.
人間の介入によって割り当てられたアドレスを使用する場合は、推測すること、および/または現在のインフラストラクチャで使用されるIPv4アドレスを埋め込む任意のIPv6アドレスを避けるために、明白ではないIPv6アドレスを選択することをお勧めします。悪意のある第三者が攻撃の目標を推測するため、ある程度のセキュリティ上の脅威を軽減するために、これら2つの忠告に従えば、それはより困難になります。
This document doesn't add any new security considerations that aren't already outlined in the security considerations of the references.
この文書は、すでに参照のセキュリティ上の考慮事項に概説されていない任意の新しいセキュリティの考慮事項を追加しません。
It must be noted that using subnet prefixes other than /64 breaks security mechanisms such as Cryptographically Generated Addresses (CGAs) and Hash-Based Addresses (HBAs), and thus makes it impossible to use protocols that depend on them.
サブネットを使用すると、このような暗号的に生成されたアドレス（CGAs）とハッシュベースアドレス（HBAの）など、他のより/ 64休憩セキュリティメカニズムを接頭辞、ひいてはそれが不可能それらに依存プロトコルを使用することが可能になることに留意しなければなりません。
Constructive feedback and contributions have been received during IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola, John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny Listman, Salman Assadullah, Krishnan Thirukonda, and the IESG.
建設的なフィードバックと貢献は、IESGのレビューサイクルの間、およびマーラAzinger、スティグVenaas、ペッカSavola、ジョン・スペンス、パトリックGrossetete、カルロス・ガルシアブラスキ、ブライアン・カーペンター、マーク・スミス、ヤーノシュMohacsi、ジム・バウンド、フレッド・テンプリン、ジニーListmanから受信されていますサルマンAssadullah、クリシュナンThirukonda、およびIESG。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]ジョンソン、D.とS.デアリング、 "予約済みのIPv6サブネットエニーキャストアドレス"、RFC 2526、1999年3月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021] Retana、A.、ホワイト、R.、フラー、V.、および、RFC 3021、2000年12月、 "IPv4のポイントツーポイントリンク上で31ビットのプレフィックスを使用する" D.マクファーソン、。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABとIESG、RFC 3177、2001年9月 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]マイヤー、D.およびP. Lothberg、 "8分の233にアドレッシングGLOP"、BCP 53、RFC 3180、2001年9月。
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, November 2001.
[RFC3194]デュラン、A.及びC.のHuitema、 "アドレス割り当て効率のためにH-密度比H比でアップデート"、RFC 3194、2001年11月。
[RFC3315] Droms, R., 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月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3531] Blanchet, M., "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block", RFC 3531, April 2003.
[RFC3531]ブランシェ、M.、「IPv6のビットの割り当てを管理するための柔軟な方法をブロックアドレス」、RFC 3531、2003年4月。
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[RFC3587] HindenとR.、デアリング、S.、およびE. Nordmarkと、 "IPv6のグローバルユニキャストアドレス形式"、RFC 3587、2003年8月。
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.
[RFC3627] Savola、P.、 "有害と考えられルータ間の使用の/ 127プレフィックス長"、RFC 3627、2003年9月。
[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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004.
[RFC3701]フィンク、R.とR. Hindenと "6boneの（IPv6のテストアドレス割り当て）段階的廃止"、RFC 3701、2004年3月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス"、RFC 3736、2004年4月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879]のHuitema、C.およびB.大工、 "卑下サイトローカルアドレス"、RFC 3879、2004年9月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956] Savola、P.とB.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F.、リア、E.、およびR. Droms、 "国旗の日なしでIPv6ネットワークを再番号付けのための手順"、RFC 4192、2005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[RFC4218] Nordmarkと、E.とT.李、RFC 4218、2005年10月の "IPv6マルチホーミングソリューションに関連脅威"。
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers Should Think About", RFC 4219, October 2005.
[RFC4219]リア、E.は、 "物事IPv6におけるマルチホーミング（MULTI6）開発者が考えなければならない"、RFC 4219、2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006.
[RFC4477]のchown、T.、Venaas、S.、およびC. Strauf、 "動的ホスト構成プロトコル（DHCP）：IPv4とIPv6のデュアルスタックの問題"、RFC 4477、2006年5月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続（6PE）"、RFC 4798、2007年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866] Arkko、J.、フォークト、C.、およびW.ハダッド、 "モバイルIPv6のためのルート最適化の強化"、RFC 4866、2007年5月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定"、RFC 5214、2008年3月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157]のchown、T.、 "ネットワークスキャンのためのIPv6の影響"、RFC 5157、2008年3月。
[SHIM6] IETF, "Site Multihoming by IPv6 Intermediation (shim6) Charter", <http://www.ietf.org/html.charters/ shim6-charter.html>.
【SHIM6] IETF、 "IPv6の仲介によってサイトマルチホーミング（SHIM6）憲章"、<http://www.ietf.org/html.charters/ SHIM6-charter.html>。
[ARIN] ARIN, "ARIN Number Resource Policy Manual", Version 2008.4, September 2008, <http://www.arin.net/policy/nrpm.html>.
[ARIN] ARIN、 "ARINナンバーリソースポリシーマニュアル"、バージョン2008.4、2008年9月、<http://www.arin.net/policy/nrpm.html>。
[RIPE_Nov07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment Policy", ripe-421, November 2007, <http://www.ripe.net/ripe/docs/ipv6policy.html>.
[RIPE_Nov07] APNIC、ARIN、RIPE NCC、 "IPv6アドレス割り振りおよび割り当てポリシー"、熟した-421、2007年11月、<http://www.ripe.net/ripe/docs/ipv6policy.html>。
[RIPE_Jul07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment Policy", ripe-412, July 2007, <http://www.ripe.net/ripe/docs/ripe-412.html>.
[RIPE_Jul07] APNIC、ARIN、RIPE NCC、 "IPv6アドレス割り振りおよび割り当てポリシー"、熟した-412、2007年7月、<http://www.ripe.net/ripe/docs/ripe-412.html>。
[APNIC_IPv6] APNIC, "IPv6 Address Allocation and Assignment Policy", APNIC-089, August 2008, <http:// www.apnic.net/policy/ipv6-address-policy.html>.
[APNIC_IPv6] APNIC、 "IPv6アドレス割り振りおよび割り当てポリシー"、APNIC-089、2008年8月、<のhttp：// www.apnic.net/policy/ipv6-address-policy.html>。
[LACNIC_IPv6] LACNIC, "Internet Resource Management Policies in Latin America and the Caribbean: IPv6 Address Allocation and Assignment Policy", <http://lacnic.net/en/politicas/ipv6.html>.
[LACNIC_IPv6] LACNIC、「ラテンアメリカ・カリブ海地域でのインターネットリソース管理ポリシー：IPv6アドレス割り振りおよび割り当てポリシー」、<http://lacnic.net/en/politicas/ipv6.html>。
[AFRINIC_IPv6] AfriNIC, "AfriNIC IPv6 Address Allocation and Assignment Policy", March 2004, <http://www.afrinic.net/docs/policies/ afpol-v6200407-000.htm>.
[AFRINIC_IPv6] AfriNIC、 "AfriNIC IPv6アドレス割り振りおよび割り当てポリシー"、2004年3月、<http://www.afrinic.net/docs/policies/ afpol-v6200407-000.htm>。
[THINKABOUT] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, March 2007.
[THINKABOUT]のchown、T.、トンプソン、M.、フォード、A.、およびS. Venaas、進歩、2007年3月にワーク "IPv6ネットワークのリナンバリング時に物事を考えます"。
Appendix A. Case Studies
付録A.ケーススタディ
This appendix contains two case studies for IPv6 addressing schemas that have been based on the statements and considerations of this document. These case studies illustrate how this document has been used in two specific network scenarios. The case studies may serve as basic considerations for an administrator who designs the IPv6 addressing schema for an enterprise or ISP network, but are not intended to serve as a general design proposal for every kind of IPv6 network. All subnet sizes used in this appendix are for practical visualization and do not dictate RIR policy.
この付録では、この文書の文との考慮に基づいているのIPv6アドレス指定のスキーマのための2つのケーススタディが含まれています。これらのケーススタディは、この文書は、2つの特定のネットワークシナリオで使用されている方法を示しています。ケーススタディは、企業やISPネットワークのIPv6アドレス指定のスキーマを設計し、管理者用としての基本的な考慮事項を果たすかもしれませんが、IPv6ネットワークのあらゆる種類のための一般的な設計案として機能するように意図されていません。この付録で使用されるすべてのサブネットサイズは、実用的な可視化のためのものであり、RIRのポリシーを規定していません。
A.1. Enterprise Considerations
A.1。エンタープライズの考慮事項
In this section, one considers a case study of a campus network that is deploying IPv6 in parallel with existing IPv4 protocols in a dual-stack environment. The specific example is the University of Southampton (UK), focusing on a large department within that network. The deployment currently spans around 1,000 hosts and over 1,500 users.
このセクションでは、1は、デュアルスタック環境では、既存のIPv4プロトコルと並列にIPv6を展開しているキャンパスネットワークのケーススタディを検討します。具体的な例としては、そのネットワーク内の大部門に焦点を当て、サウサンプトン大学（英国）です。展開は現在、約1,000のホストと1,500人以上のユーザーをまたがります。
A.1.1. Obtaining General IPv6 Network Prefixes
A.1.1。一般的なIPv6ネットワークプレフィックスを取得
In the case of a campus network, the site will typically take its connectivity from its National Research and Education Network (NREN). Southampton connects to JANET, the UK academic network, via its local regional network LeNSE (Learning Network South East). JANET currently has a /32 allocation from RIPE NCC. The current recommended practice is for sites to receive a /48 allocation; on this basis, Southampton has received such a prefix for its own use. The regional network also uses its own allocation from the NREN provider.
キャンパスネットワークの場合、サイトは通常、その国立研究教育ネットワーク（NREN）からの接続がかかります。サウサンプトンは、そのローカル地域ネットワークのLeNSE（学習ネットワーク東南アジア）を介して、JANET、英国の学術ネットワークに接続します。 JANET現在RIPE NCCから/ 32割り振りを有しています。現在のお勧めは/ 48の割り当てを受信するためのサイトです。これに基づいて、サウサンプトンは、自身の使用のために、このような接頭辞を受けています。地域ネットワークもNRENプロバイダーから独自の割り当てを使用しています。
No ULA addressing is used on site. The campus is not multihomed (JANET is the sole provider), nor does it expect to change service provider, and thus does not plan to use ULAs for the (perceived) benefit of easing network renumbering. Indeed, the campus has renumbered following the aforementioned renumbering procedure [RFC4192] on two occasions, and this has proven adequate (with provisos documented in [THINKABOUT]). The campus does not see any need to deploy ULAs for in-band or out-of-band network management; there are enough IPv6 prefixes available in the site allocation for the infrastructure. In some cases, use of private IP address space in IPv4 creates problems, so University of Southampton believes that the availability of ample global IPv6 address space for infrastructure may be a benefit for many sites.
ULAアドレッシングがサイト上で使用されません。キャンパスは（JANETが唯一のプロバイダーである）マルチホームされていない、またそれは、サービスプロバイダを変更するには期待しないため、ネットワークのリナンバリングを緩和する（認知）の利益のためにULAsを使用する予定はありません。実際、キャンパスは、二つの機会に、前述のリナンバリング手順[RFC4192]以下の番号を付け替えており、これは（[THINKABOUT]に記載但し書きで）十分であることが証明されました。キャンパスはULAsを展開する必要性を見ていないため、インバンドまたはアウトオブバンドネットワーク管理;インフラのためのサイトの割り当てで利用可能な十分なIPv6プレフィックスがあります。いくつかのケースでは、IPv4のプライベートIPアドレス空間の使用は、問題を作成するので、サウサンプトン大学は、インフラストラクチャのための十分なグローバルIPv6アドレス空間の利用可能性は、多くのサイトのための利益であり得ることを考えています。
No 6bone addressing is used on site any more. Since the 6bone phaseout of June 2006 [RFC3701], most transit ISPs have begun filtering attempted use of such prefixes.
何の6boneのアドレス指定は、任意のより多くのサイトで使用されていません。 2006年6月[RFC3701]の6boneの段階的廃止をするので、ほとんどのトランジットISPは、このような接頭辞を試みた使用をフィルタリングし始めています。
Southampton does participate in global and organizational scope IPv6 multicast networks. Multicast address allocations are not discussed here as they are not in scope for the document. It is noted that IPv6 has advantages for multicast group address allocation. In IPv4, a site needs to use techniques like GLOP [RFC3180] to pick a globally unique multicast group to use. This is problematic if the site does not use the Border Gateway Protocol (BGP) [RFC4271] and does not have an Autonomous System Number (ASN). In IPv6,0 unicast-prefix-based IPv6 multicast addresses empower a site to pick a globally unique group address based on its own unicast site or link prefix. Embedded-RP is also in use, is seen as a potential advantage for IPv6 and multicast, and has been tested successfully across providers between sites (including paths to/from the US and UK).
サウサンプトンは、グローバルおよび組織スコープのIPv6マルチキャストネットワークに参加しません。彼らは、ドキュメントのスコープに含まれていないとして、マルチキャストアドレスの割り当ては、ここで議論されていません。 IPv6マルチキャストグループアドレスの割り当てのための利点を持っていることに留意されたいです。 IPv4では、サイトが使用するために、グローバルに一意なマルチキャストグループを選択するGLOP [RFC3180]のような技術を使用する必要があります。サイトには、ボーダーゲートウェイプロトコル（BGP）[RFC4271]を使用していないと自律システム番号（ASN）を持っていない場合、これは問題があります。 IPv6,0では、ユニキャストプレフィックスベースのIPv6マルチキャストアドレスは、独自のユニキャストサイトまたはリンクプレフィックスに基づいてグローバルにユニークなグループアドレスを選択するようにサイトに力を与えます。組み込み-RPが使用されても、IPv6のマルチキャストのための潜在的な利点と見られている、と（米国と英国へ/からのパスを含む）サイト間のプロバイダ間で正常にテストされています。
A.1.2. Forming an Address (Subnet) Allocation Plan
A.1.2。アドレス（サブネット）割当計画を形成します
The campus has a /16 prefix for IPv4 use; in principle, 256 subnets of 256 addresses. In reality, the subnetting is muddier, because of concerns of IPv4 address conservation; subnets are sized to the hosts within them, e.g., a /26 IPv4 prefix is used if a subnet has 35 hosts in it. While this is efficient, it increases management burden when physical deployments change, and IPv4 subnets require resizing (up or down), even when DHCP is in use.
キャンパスは、IPv4用/ 16のプレフィックスを持っています。原則として、256個のアドレス256個のサブネット。現実には、サブネットがあるため、IPv4アドレスの保全の懸念のため、muddierです。サブネットは、サブネットが35台のホストを有する場合IPv4プレフィクスが使用されている/ 26、例えば、その中のホストに寸法決めされています。これは効率的ではあるが、物理的な展開が変化したときには、管理の負担を増加させ、IPv4のサブネットは、DHCPを使用している場合でも、（アップまたはダウン）リサイズが必要です。
The /48 IPv6 prefix is considerably larger than the IPv4 allocation already in place at the site. It is loosely equivalent to a 'Class A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an effectively unlimited subnet address size (2^64) compared to 256 in the IPv4 equivalent. The increased subnet size means that /64 IPv6 prefixes can be used on all subnets, without any requirement to resize them at a later date. The increased subnet volume allows subnets to be allocated more generously to schools and departments in the campus. While address conservation is still important, it is no longer an impediment to network management. Rather, address (subnet) allocation is more about embracing the available address space and planning for future expansion.
/ 48 IPv6プレフィックスサイトの場所ですでにIPv4の割り当てよりもかなり大きいです。それは2 ^ 16（65,000以上）サブネットを持つが、IPv4の換算で256に比べて効果的に無制限のサブネットアドレスサイズ（2 ^ 64）を有することを「クラスA」IPv4プレフィクスに緩く等価です。増加したサブネットサイズは/ 64のIPv6プレフィックスは、後日それらのサイズを変更するために、任意の必要とせずに、すべてのサブネット上で使用することができることを意味します。増加したサブネットボリュームはサブネットは、キャンパス内の学校や部門に、より寛大に割り当てることができます。アドレスの保全は依然として重要であるが、それはもはや、ネットワーク管理に支障はありません。むしろ、アドレス（サブネット）の割り当ては、利用可能なアドレス空間を採用し、将来の拡張のための計画の詳細です。
In a dual-stack network, it was chosen to deploy the IP subnets congruently for IPv4 and IPv6. This is because the systems are still in the same administrative domains and the same geography. It is not expected to have IPv6-only subnets in production use for a while yet, outside the test beds and some early Mobile IPv6 trials. With congruent addressing, the firewall policies are also aligned for IPv4 and IPv6 traffic at the site border.
デュアルスタックネットワークでは、IPv4とIPv6のための合同IPサブネットを展開することを選択しました。システムが同じ管理ドメインと同じ地理に残っているためです。テストベッドといくつかの初期のモバイルIPv6トライアルの外に、まだしばらくの間、生産使用でIPv6のみのサブネットを持つことが期待されていません。合同アドレッシングを使用すると、ファイアウォールポリシーは、サイトの境界でIPv4とIPv6トラフィックのために整列されています。
The subnet allocation plan required a division of the address space per school or department. Here, a /56 was allocated to the school level of the university; there are around 30 schools currently. A /56 of IPv6 address space equates to 256 /64 subnet allocations. Further /56 allocations were made for central IT infrastructure, the network infrastructure, and the server side systems.
サブネット割り当て計画は、学校や部門ごとのアドレス空間の分割を必要としました。ここでは、/ 56は、大学の学校のレベルに配分されました。現在約30校があります。 IPv6アドレス空間の/ 56 64分の256サブネット割り当てに等しいです。さらに/ 56の割り当ては、中央ITインフラストラクチャ、ネットワークインフラストラクチャ、およびサーバ側システムのために作られました。
A.1.3. Other Considerations
A.1.3。その他の考慮事項
The network uses a Demilitarized Zone (DMZ) topology for some level of protection of 'public' systems. Again, this topology is congruent with the IPv4 network.
ネットワークは、「公共のシステムのあるレベルの保護のための非武装地帯（DMZ）トポロジを使用しています。ここでも、このトポロジでは、IPv4ネットワークと合同です。
There are no specific transition methods deployed internally to the campus; everything is using the conventional dual-stack approach. There is no use of ISATAP [RFC5214] for example.
キャンパスに内部的に展開具体的な移行方法がありません。すべては、従来のデュアルスタックアプローチを使用しています。例えばISATAP [RFC5214]の使用はありません。
For the Mobile IPv6 early trials, there is one allocated prefix for Home Agent (HA) use. However, there has been no detailed consideration yet regarding how Mobile IPv6 usage may grow, and whether more subnets (or even every subnet) will require HA support.
モバイルIPv6の早期臨床試験のために、ホームエージェント（HA）の使用のための1つの割り当てられた接頭辞があります。しかし、モバイルIPv6の利用が成長できるかについてはまだ詳細な検討はなされていない、と複数のサブネットかどうか（あるいはすべてのサブネット）は、HAのサポートが必要になります。
The university operates a tunnel broker [RFC3053] service on behalf of the United Kingdom Education and Research Network Association (UKERNA) for JANET sites. This uses separate address space from JANET, not the university site allocation.
大学は、JANETサイトのイギリスの教育と研究ネットワーク協会（UKERNA）に代わってトンネルブローカー[RFC3053]のサービスを運営しています。これは、JANETとは別のアドレス空間ではなく、大学のサイト割り当てを使用しています。
A.1.4. Node Configuration Considerations
A.1.4。ノード構成の考慮事項
Currently, stateless autoconfiguration is used on most subnets for IPv6 hosts. There is no DHCPv6 service deployed yet, beyond tests of early code releases. It is planned to deploy DHCPv6 for address assignment when robust client and server code is available (at the time of writing, the potential for this looks good, e.g., via the Internet Systems Consortium (ISC) implementation). University of Southampton is also investigating a common integrated DHCP/DNS management platform, even if the servers themselves are not co-located, including integrated DHCPv4 and DHCPv6 server configuration, as discussed in [RFC4477]. Currently, clients with statelessly autoconfigured addresses are added to the DNS manually, though dynamic DNS is an option. The network administrators would prefer the use of DHCP because they believe it gives them more management control.
現在、ステートレス自動設定は、IPv6ホストのための最もサブネット上で使用されています。初期のコードのリリースのテストを超えて、まだ展開全くDHCPv6サービスはありません。これは、堅牢なクライアントとサーバーのコードが利用可能なときにアドレス割り当てのためのDHCPv6を展開するために計画されている（執筆時点で、このための可能性は、Internet Systems Consortium（ISC）の実装を経由して、例えば、よさそうです）。サウサンプトン大学はまた、[RFC4477]で説明したように、サーバ自体は、統合されたDHCPv4とDHCPv6サーバの設定を含め、同じ場所に配置されていない場合でも、一般的な統合されたDHCP / DNS管理プラットフォームを調査しています。ダイナミックDNSはオプションですが、現在、ステートレス自動設定アドレスを持つクライアントは、手動でDNSに追加されます。彼らはそれが彼らに多くの管理制御を与えると考えているので、ネットワーク管理者は、DHCPの使用を好むだろう。
Regarding the implications of the larger IPv6 subnet address space on scanning attacks [RFC5157], it is noted that all the hosts are dual-stack, and thus are potentially exposed over both protocols anyway. All addresses are published in DNS, and the site does not operate a two-faced DNS.
走査攻撃[RFC5157]に大きいIPv6サブネットアドレス空間の影響について、すべてのホストはデュアルスタックであるので、潜在的にとにかく両方のプロトコルの上に露出されることに留意されたいです。すべてのアドレスがDNSで公開され、サイトは2-直面しているDNSを操作しません。
Currently, there is internal usage of RFC 4941 privacy addresses [RFC4941] (certain platforms ship with it on by default), but network administrators may desire to disable this (perhaps via DHCP) to ease management complexity. However, it is desired to determine the feasibility of this on all systems, e.g., for guests on wireless LAN or other user-maintained systems. Network management and monitoring should be simpler without RFC 4941 in operation, in terms of identifying which physical hosts are using which addresses. Note that RFC 4941 is only an issue for outbound connections, and that there is potential to assign privacy addresses via DHCPv6.
現在、RFC 4941のプライバシーアドレス[RFC4941]（デフォルトではそれに特定のプラットフォームの船）の内部使い方がありますが、ネットワーク管理者は、管理の複雑さを緩和するために（おそらくDHCP経由で）これを無効にすることを望むかもしれません。しかし、無線LANまたは他のユーザ維持システムでゲストのため、例えば、すべてのシステムでこれを実現可能性を決定することが望まれます。ネットワーク管理および監視は、物理ホストのアドレスその使用している特定の点で、動作時にRFC 4941せずに単純であるべきです。 RFC 4941は、アウトバウンド接続のための唯一の問題であり、とDHCPv6を経由して、プライバシーアドレスを割り当てる可能性があることに注意してください。
Manually configured server addresses are used to avoid address changes based upon change of network adaptor. With IPv6 you can pick ::53 for a DNS server, or you can pick 'random' addresses for obfuscation, though that's not an issue for publicly advertised addresses (dns, mx, web, etc.).
手動で設定されたサーバのアドレスは、ネットワークアダプタの変化に基づいて、アドレスの変更を回避するために使用されています。 IPv6では、あなたはDNSサーバのための:: 53を選ぶことができ、またはそれは公に公示アドレス（DNS、MX、ウェブ、など）のための問題ではないのですけれども、あなたは、難読化のために「ランダム」のアドレスを選ぶことができます。
A.2. Service Provider Considerations
A.2。サービスプロバイダーの考慮事項
In this section an IPv6 addressing schema is sketched that could serve as an example for an Internet Service Provider.
このセクションではIPv6のアドレス指定のスキーマは、インターネットサービスプロバイダのための一例としての役割を果たすことができることをスケッチしています。
Appendix A.2.1 starts with some thoughts regarding objective requirements of such an addressing schema and derives a few general rules of thumb that have to be kept in mind when designing an ISP IPv6 addressing plan.
付録A.2.1は、このようなアドレッシングスキーマの客観的要件に関して、いくつかの考えから始まり、ISPのIPv6アドレス指定の計画を設計する際に念頭に置いておく必要はあり親指のいくつかの一般的なルールを導出します。
Appendix A.2.2 illustrates the findings of Appendix A.2.1 with an exemplary IPv6 addressing schema for an MPLS-based ISP offering Internet services as well as network access services to several millions of customers.
付録A.2.2は、顧客の数百万にインターネットサービスだけでなく、ネットワーク・アクセス・サービスを提供するMPLSベースのISPのための例示的なIPv6のアドレス指定のスキーマと付録A.2.1の調査結果を示しています。
A.2.1. Investigation of Objective Requirements for an IPv6 Addressing Schema of a Service Provider
A.2.1。サービスプロバイダのIPv6のアドレス指定スキーマのための客観的要件の調査
The first step of the IPv6 addressing plan design for a service provider should identify all technical, operational, political, and business requirements that have to be satisfied by the services supported by this addressing schema.
サービスプロバイダのIPv6アドレス計画設計の最初のステップは、このアドレッシング・スキーマによってサポートされるサービスによって満たされなければならすべての技術、運用、政治的、およびビジネス要件を特定する必要があります。
According to the different technical constraints and business models as well as the different weights of these requirements (from the point of view of the corresponding service provider), it is very likely that different addressing schemas will be developed and deployed by different ISPs. Nevertheless, the addressing schema of Appendix A.2.2 is one possible example.
さまざまな技術的な制約やビジネスモデルだけでなく、これらの要件（対応するサービスプロバイダの観点から）の異なる重みによると、別のアドレス指定スキーマが異なるISPによって開発され、配備される可能性が非常に高いです。それにも関わらず、付録A.2.2のアドレッシング・スキーマは、1つの可能な例です。
For this document, it is assumed that our exemplary ISP has to fulfill several roles for its customers such as:
この文書では、私たちの典型的なISPのような顧客のためのいくつかの役割を果たすために持っていることが想定されています。
o Local Internet Registry
Oローカルインターネットレジストリ
o Network Access Provider
Oネットワークアクセスプロバイダー
o Internet Service Provider
Oインターネットサービスプロバイダ
A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR Perspective of the Service Provider
A.2.1.1。サービスプロバイダーのLIR視点からのIPv6アドレス指定スキーマへの提言
In its role as Local Internet Registry (LIR), the service provider has to care about the policy constraints of the RIRs and the standards of the IETF regarding IPv6 addressing. In this context, the following basic recommendations have to be considered and should be satisfied by the IPv6 address allocation plan of a service provider:
ローカルインターネットレジストリ（LIR）としての役割では、サービスプロバイダは、各RIRのポリシー制約とIPv6アドレスに関するIETFの標準規格を気にする必要があります。この文脈では、以下の基本的な推奨事項は考慮しなければならないと、サービスプロバイダのIPv6のアドレス割り当て計画によって満たされる必要があります。
o As recommended in RFC 3177 [RFC3177] and in several RIR policies, "Common" customers sites (normally private customers) should receive a /48 prefix from the aggregate of the service provider. (Note: The addressing plan must be flexible enough and take into account the possible change of the minimum allocation size for end users currently under definition by the RIRs.)
RFC 3177 [RFC3177]に、いくつかのRIR政策で推奨されているようにO、「一般的な」顧客サイト（通常は個人顧客）は、サービスプロバイダの集計から/ 48のプレフィックスを受けるべきです。 （注：アドレッシング計画は十分に柔軟であり、現在のRIRによって定義で考慮エンドユーザーの最小割り当てサイズの可能性のある変更を行う必要があります。）
o "Big customers" (like big enterprises, governmental agencies, etc.) may receive shorter prefixes according to their needs, when their needs can be documented and justified to the RIR.
O（大企業、政府機関などのような）「ビッグ顧客は、」彼らのニーズがRIRに文書化し、正当化することができたときに、自分のニーズに応じて短いプレフィックスを受け取ることができます。
o The IPv6 address allocation schema has to be able to meet the HD-ratio that is proposed for IPv6. This requirement corresponds to the demand for an efficient usage of the IPv6 address aggregate by the service provider. (Note: The currently valid IPv6 HD-ratio of 0.94 means an effective usage rate of about 22% of a /20 prefix of the service provider, on the basis of /56 assignments.)
OのIPv6アドレス割当スキーマは、IPv6のために提案されているHD-比を満たすことができなければなりません。この要件は、サービス・プロバイダによってIPv6アドレス集合体の効率的な使用のための需要に対応します。 （注：0.94の現在有効なIPv6 HD-比が/ 56の割り当てに基づいて、サービスプロバイダの/ 20プレフィックスの約22％の有効利用率を意味します。）
o All assignments to customers have to be documented and stored into a database that can also be queried by the RIR.
O顧客へのすべての割り当てを文書化し、また、RIRで照会できるデータベースに格納する必要があります。
o The LIR has to make available the means for supporting the reverse DNS mapping of the customer prefixes.
oをLIRは、顧客のプレフィックスの逆DNSマッピングを支持するための手段を利用できるようにすることがあります。
o IPv6 Address Allocation and Assignment Policies can be found at RIRs and are similar in many aspects. See [RIPE_Nov07], [RIPE_Jul07], [APNIC_IPv6], [LACNIC_IPv6], [AFRINIC_IPv6], and Section 6 of [ARIN].
OのIPv6アドレス割り振りおよび割り当てポリシーのRIRで発見され、多くの点で類似していることができます。 [AFRINIC_IPv6]、[RIPE_Jul07]、[APNIC_IPv6]、[LACNIC_IPv6]、[RIPE_Nov07]を参照し、[ARIN]のセクション6。
A.2.1.2. IPv6 Addressing Schema Recommendations from the ISP Perspective of the Service Provider
A.2.1.2。サービスプロバイダのISP視点からスキーマ勧告をIPv6アドレス
From the ISP perspective, the following basic requirements can be identified:
ISPの観点から、以下の基本的な要件を識別することができます。
o The IPv6 address allocation schema must be able to realize a maximal aggregation of all IPv6 address delegations to customers into the address aggregate of the service provider. Only this provider aggregate will be routed and injected into the global routing table (DFZ, "Default-Free Zone"). This strong aggregation keeps the routing tables of the DFZ small and eases filtering and access control very much.
OのIPv6アドレス割り当てスキーマは、サービスプロバイダのアドレス集約に顧客にすべてのIPv6アドレスの代表団の最大凝集を実現することができなければなりません。これだけプロバイダ集約はルーティングされ、グローバルルーティングテーブル（DFZ、「デフォルト・フリーゾーン」）に注入されます。この強い集約は小さなDFZのルーティングテーブルを保持し、非常に多くのフィルタリングとアクセス制御を容易にします。
o The IPv6 addressing schema of the SP should contain optimal flexibility since the infrastructure of the SP will change over time with new customers, transport technologies, and business cases. The requirement of optimal flexibility is contrary to the recommendation of strong IPv6 address aggregation and efficient address usage, but each SP has to decide which of these requirements to prioritize.
O SPのIPv6のアドレス指定のスキーマは、SPのインフラは、新規顧客、輸送技術、およびビジネスケースと時間をかけて変化しますので、最適な柔軟性を含める必要があります。最適な柔軟性の要件は、強力なIPv6アドレスの集約と効率的なアドレスの使用状況の勧告に反しているが、各SPは、優先順位を付けるために、これらの要件のかを決定する必要があります。
o While keeping the multilevel network hierarchy of an ISP in mind, note that due to addressing efficiency reasons, not all hierarchy levels can and should be mapped into the IPv6 addressing schema of an ISP. Sometimes it is much better to implement a more "flat" addressing for the ISP network than to lose big chunks of the IPv6 address aggregate in addressing each level of network hierarchy. (Note: In special cases, it is even recommended for really "small" ISPs to design and implement a totally flat IPv6 addressing schema without any level of hierarchy.)
心内ISPのマルチレベルのネットワーク階層を維持しながら、O、により効率の理由に対処することなく、すべての階層レベルとISPのIPv6アドレス指定スキーマにマップされなければならないことに注意。ネットワーク階層の各レベルに対処する上でIPv6アドレス集合体の大きな塊を失うことよりも、時にはより多くの「フラット」は、ISPネットワークのアドレス指定を実装することもはるかに優れています。 （注：特別な場合には、さえ設計し、階層の任意のレベルのない、完全にフラットなIPv6のアドレス指定のスキーマを実装するために、本当に「小さな」のISPのために推奨されます。）
o A decoupling of provider network addressing and customer addressing is recommended. (Note: A strong aggregation (e.g., on POP, Aggregation Router (AG), or Label Edge Router (LER) level) limits the numbers of customer routes that are visible within the ISP network, but also brings down the efficiency of the IPv6 addressing schema. That's why each ISP has to decide how many internal aggregation levels it wants to deploy.)
Oプロバイダ・ネットワークアドレッシングと顧客アドレッシングのデカップリングが推奨されます。 （注：強い凝集（例えば、POPに、集約ルータ（AG）、またはラベルエッジルータ（LER）レベル）ISPネットワーク内で表示され、顧客の経路の数を制限するだけでなく、IPv6の効率をダウンさせスキーマに取り組む。各ISPは、それが展開したいどのように多くの内部の集約レベルを決定するために持っている理由です。）
A.2.1.3. IPv6 Addressing Schema Recommendations from the Network Access Provider Perspective of the Service Provider
A.2.1.3。 IPv6は、サービスプロバイダーのネットワークアクセスプロバイダーの観点からスキーマ勧告への対応します
As already done for the LIR and the ISP roles of the SP it is also necessary to identify requirements that come from its Network Access Provider role. Some of the basic requirements are:
すでにLIRとSPのISPの役割のために行ったように、そのネットワークアクセスプロバイダの役割から来るの要件を識別することも必要です。基本的な要件のいくつかは以下のとおりです。
o The IPv6 addressing schema of the SP, it must be chosen in a way that it can handle new requirements that are triggered from customer side. For instance, this can be the customer's growing needs for IPv6 addresses as well as customer-driven modifications within the access network topology (e.g., when the customer moves from one point of network attachment (POP) to another). (See Appendix A.2.3.4, "Changing the Point of Network Attachment".)
IPv6はSPのスキーマに対処O、それは顧客側からトリガされ、新たな要件に対応できるように選択する必要があります。例えば、これは、IPv6のための顧客の増大するニーズに対処するだけでなく、アクセス・ネットワーク・トポロジ内の顧客主導の修飾（例えば、ときに、別のネットワーク接続（POP）の一点から顧客に移動）することができます。 （「ネットワーク接続のポイントを変更する」、付録A.2.3.4を参照してください。）
o For each IPv6 address assignment to customers, a "buffer zone" should be reserved that allows the customer to grow in its addressing range without renumbering or assignment of additional prefixes.
O顧客にそれぞれのIPv6アドレスの割り当てについては、「バッファゾーンは、」顧客がリナンバリングや追加のプレフィックスの割り当てなしにそのアドレス指定の範囲で成長することを可能にするように確保されなければなりません。
o The IPv6 addressing schema of the SP must deal with multiple attachments of a single customer to the SP network infrastructure (i.e., multihomed network access with the same SP).
O SPのIPv6アドレス指定スキーマは、SPネットワークインフラストラクチャ（同じSPを有する、すなわち、マルチホーム・ネットワーク・アクセス）に単一の顧客の複数の添付ファイルに対処しなければなりません。
These few requirements are only part of the requirements a service provider has to investigate and keep in mind during the definition phase of its addressing architecture. Each SP will most likely add more constraints to this list.
これらのいくつかの要件は、サービスプロバイダが調査し、そのアドレス体系の定義フェーズの間に心に留めておく必要があり要件の一部のみです。各SPは、最も可能性の高いこのリストに多くの制約を追加します。
A.2.1.4. A Few Rules of Thumb for Designing an ISP IPv6 Addressing Architecture
A.2.1.4。 ISPのIPv6アドレス指定アーキテクチャの設計のための親指のいくつかのルール
As a result of the above enumeration of requirements regarding an ISP IPv6 addressing plan, the following design "rules of thumb" have been derived:
ISPのIPv6アドレス計画に関する要件の上記列挙した結果、次のような設計「親指のルールは、」派生されています：
o No "One size fits all". Each ISP must develop its own IPv6 address allocation schema depending on its concrete business needs. It is not practical to design one addressing plan that fits for all kinds of ISPs (small / big, routed / MPLS-based, access / transit, LIR / No LIR, etc.).
ノーO「フリーサイズ」。各ISPは、その具体的なビジネス・ニーズに応じて、独自のIPv6アドレス割り当てスキーマを開発する必要があります。 （LIR /いいえLIRなど、小型/大MPLSベース/ルーテッド、アクセス/トランジット）のISPのすべての種類のために合う1つのアドレッシング計画を設計することは現実的ではありません。
o The levels of IPv6 address aggregation within the ISP addressing schema should strongly correspond to the implemented network structure, and their number should be minimized because of efficiency reasons. It is assumed that the SP's own infrastructure will be addressed in a fairly flat way, whereas part of the customer addressing architecture should contain several levels of aggregation.
ISPアドレッシングスキーマ内のIPv6アドレス集合のレベルoを強く実現ネットワーク構造に対応している必要があり、その数があるため、効率上の理由から最小限にすべきです。顧客アドレス体系の一部が凝集のいくつかのレベルが含まれている必要があり、一方、SP自身のインフラは、かなりフラットな方法で対処することを想定しています。
o Keep the number of IPv6 customer routes inside your network as small as possible. A totally flat customer IPv6 addressing architecture without any intermediate aggregation level will lead to lots of customer routes inside the SP network. A fair trade-off between address aggregation levels (and hence the size of the internal routing table of the SP) and address conservation of the addressing architecture has to be found.
Oできるだけ小さく、ネットワーク内のIPv6顧客ルートの数にしてください。任意の中間集約レベルなしで完全に平坦な顧客のIPv6アドレス体系は、SPネットワーク内の顧客ルートのロットにつながります。アドレスアグリゲーションレベル（したがって、SPの内部ルーティングテーブルのサイズ）とアドレス体系のアドレス保存の間にフェアトレードオフが見出されなければなりません。
o The ISP IPv6 addressing schema should provide maximal flexibility. This has to be realized for supporting different sizes of customer IPv6 address aggregates ("big" customers vs. "small" customers) as well as to allow future growth rates (e.g., of customer aggregates) and possible topological or infrastructural changes.
O ISPのIPv6アドレス指定のスキーマは、最大限の柔軟性を提供する必要があります。これは、顧客のIPv6アドレスの集合体（「ビッグ」の顧客対「小さな」の顧客）の異なるサイズをサポートするために実現されるだけでなく、将来の成長率（例えば、顧客の凝集体の）と可能な位相的またはインフラの変更を可能にしています。
o A limited number of aggregation levels and sizes of customer aggregates will ease the management of the addressing schema. This has to be weighed against the previous "rule of thumb" -- flexibility.
Oアグリゲーションレベルと顧客の凝集体の大きさの限られた数のアドレス指定スキーマの管理を容易にします。柔軟性 - これは、以前の「経験則」と比較して検討する必要があります。
A.2.2. Exemplary IPv6 Address Allocation Plan for a Service Provider
A.2.2。サービスプロバイダのための典型的なIPv6アドレス割当計画
In this example, the service provider is assumed to operate an MPLS-based backbone and to implement IPv6 Provider Edge Routers (6PE) [RFC4798] to provide IPv6 backbone transport between the different locations (POPs) of a fully dual-stacked network access and aggregation area.
この例では、サービスプロバイダがMPLSベースのバックボーンを操作するとIPv6プロバイダーエッジルータ（6PE）を実装すると想定されている[RFC4798]異なる場所（のPOP）との間のIPv6バックボーントランスポートを提供する完全デュアル積層ネットワークアクセスと集約エリア。
In addition, it is assumed that the service provider:
また、それは、サービスプロバイダと想定されます。
o has received a /20 from its RIR
Oは、RIRから/ 20を受信しました
o operates its own LIR
oは、独自のLIRを運営します
o has to address its own IPv6 infrastructure
oは、独自のIPv6インフラストラクチャに対処しなければなりません
o delegates prefixes from this aggregate to its customers
O代表者は、顧客にこの集計から接頭辞
This addressing schema should illustrate how the /20 IPv6 prefix of the SP can be used to address the SP's own infrastructure and to delegate IPv6 prefixes to its customers, following the above-mentioned requirements and rules of thumb as far as possible.
このアドレッシングスキーマは、SPの/ 20のIPv6プレフィックスはSP自身のインフラに対処するために使用することができ、可能な限り親指の上記の要件とルールを以下、その顧客にIPv6プレフィックスを委任する方法を説明しなければなりません。
The figure below summarizes the device types in an SP network and the typical network design of a MPLS-based service provider. The network hierarchy of the SP has to be taken into account for the design of an IPv6 addressing schema; it defines the basic shape of the addressing schema and the various levels of aggregation.
以下の図は、SPネットワーク内のデバイスタイプとMPLSベースのサービスプロバイダの一般的なネットワーク設計を要約します。 SPのネットワーク階層は、IPv6のアドレス指定スキーマの設計のために考慮しなければなりません。それはアドレッシングスキーマおよび凝集の様々なレベルの基本的な形状を定義します。
+------------------------------------------------------------------+
| LSRs of the MPLS Backbone of the SP |
+------------------------------------------------------------------+
| | | | |
| | | | |
+-----+ +-----+ +--------+ +--------+ +--------+
| LER | | LER | | LER-BB | | LER-BB | | LER-BB |
+-----+ +-----+ +--------+ +--------+ +--------+
| | | | | | / | | |
| | | | | | / | | |
| | | | +------+ +------+ +------+ | |
| | | | |BB-RAR| |BB-RAR| | AG | | |
| | | | +------+ +------+ +------+ | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | RAR | | RAR | | RAR | | RAR |
| | | | | | | | +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
+-------------------------------------------------------------------+
| Customer networks |
+-------------------------------------------------------------------+
LSR Label Switch Router LER Label Edge Router LER-BB Broadband Label Edge Router RAR Remote Access Router BB-RAR Broadband Remote Access Router AG Aggregation Router
LSRのラベルスイッチルータLERラベルエッジルータLER-BBブロードバンドラベルエッジルータRARリモートアクセスルータBB-RARブロードバンドリモートアクセスルータAG集約ルータ
Exemplary Service Provider Network
代表的なサービス・プロバイダ・ネットワーク
The following should be taken into consideration when making the basic design decisions for the exemplary service provider IPv6 addressing plan regarding customer prefixes.
IPv6のアドレス指定を計画顧客プレフィックスに関する模範的なサービスプロバイダのための基本的な設計上の決定を行う際には、以下を考慮すべきです。
o The prefixes assigned to all customers behind the same LER (or LER-BB) are aggregated under one LER prefix. This ensures that the number of labels that have to be used for 6PE is limited and hence provides strong MPLS label conservation.
O同じLER（またはLER-BB）の背後にあるすべての顧客に割り当てられたプレフィックスは、一のLERプレフィックスの下に集約されます。これは6PEのために使用する必要があるラベルの数が限られているので、強力なMPLSラベルの保全を提供することを保証します。
o The /20 prefix of the SP is separated into 3 different pools that are used to allocate IPv6 prefixes to the customers of the SP:
O SPの/ 20プレフィックスは、SPの顧客にIPv6プレフィックスを割り当てるために使用される3つの異なるプールに分離されます。
1. A pool (e.g., /24) for satisfying the addressing needs of really "big" customers (as defined in Appendix A.2.2.1.1) that need IPv6 prefixes larger than /48 (e.g., /32). These customers are assumed to be connected to several POPs of the access network, so that this customer prefix will be visible in each of these POPs.
IPv6が必要プレフィックス（付録A.2.2.1.1で定義されるように）実際には「大きな」顧客のアドレッシングニーズを満たすため1.プール（例えば、/ 24）より大きい/ 48（例えば、/ 32）。これらの顧客は、この顧客のプレフィックスはこれらのPOPsのそれぞれに表示されるように、アクセスネットワークのいくつかのPOPに接続されているものとします。
2. A pool (e.g., /24) for the LERs with direct customer connections (e.g., dedicated line access) and without an additional aggregation area between the customer and the LER. (These LERs are mostly connected to a limited number of customers because of the limited number of interfaces/ports.)
2.プール（例えば、/ 24）の直接顧客の接続（例えば、専用線アクセス）とのLERおよび顧客とLERの間に追加の凝集領域はありません。 （これらのLERが主な原因インターフェイス/ポートの限られた数の顧客の限られた数に接続されています。）
3. A larger pool (e.g., 14*/24) for LERs (or LER-BBs) that serve a high number of customers that are normally connected via some kind of aggregation network (e.g., DSL customers behind a BB-RAR or dial-in customers behind a RAR).
3.大きなプール（例えば、* / 24 14）は、通常、アグリゲーションネットワーク（例えば、DSL顧客の背後BB-RARまたはダイヤルのいくつかの種類を介して接続されている顧客の高い数を提供するためのLER（またはLER-BBS） RARの後ろ-in顧客）。
o The IPv6 address delegation within each pool (the end customer delegation or the aggregates that are dedicated to the LER itself) should be chosen with an additional buffer zone of 100-300% for future growth. That is, 1 or 2 additional prefix bits should be reserved according to the expected future growth rate of the corresponding customer or the corresponding network device aggregate.
Oの各プール（最終顧客委任やLER自体専用の凝集体）内のIPv6アドレス委譲は、将来の成長のための100から300パーセントの追加のバッファゾーンに選択されるべきです。すなわち、1つの又は2の追加の接頭辞ビットが、対応する顧客の予想される将来の成長率または対応するネットワーク装置の集合体に応じて予約されるべきです。
A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the Service Provider
A.2.2.1。サービスプロバイダーのお客様のためのIPv6アドレスの割当計画の定義
A.2.2.1.1. "Big" Customers
A.2.2.1.1。 「ビッグ」お客様
The SP's "big" customers receive their prefix from the /24 IPv6 address aggregate that has been reserved for their "big" customers. A customer is considered a "big" customer if it has a very complex network infrastructure and/or huge IPv6 address needs (e.g., because of very large customer numbers) and/or several uplinks to different POPs of the SP network.
SPの「ビッグ」の顧客は彼らの「大」顧客のために予約されてきた/ 24のIPv6アドレス集約から自分のプレフィックスを受けます。それはSPネットワークのさまざまなPOPのに非常に複雑なネットワークインフラストラクチャ、および/または（理由は非常に大規模な顧客番号の例えば）巨大なIPv6のアドレスニーズおよび/または複数のアップリンクを持っている場合、お客様は「ビッグ」の顧客とみなされます。
The assigned IPv6 address prefixes can have a prefix length in the range 32-48 and for each assignment a 100 or 300% future growing zone is marked as "reserved" for this customer. For instance, this means that with a delegation of a /34 to a customer the corresponding /32 prefix (which contains this /34) is reserved for the customer's future usage.
割り当てられたIPv6アドレスプレフィックスは範囲32から48にし、この顧客のために「予約」として、100または300％の将来の成長ゾーンがマークされている各割り当てのためのプレフィックス長を持つことができます。例えば、これは、顧客（本/ 34が含まれている）に対応する/ 32プレフィックスに/ 34の代表団と、顧客の将来の使用のために予約されていることを意味します。
The prefixes for the "big" customers can be chosen from the corresponding "big customer" pool by either using an equidistant algorithm or using mechanisms similar to the Sparse Allocation Algorithm (SAA) [RIPE_Nov07].
「大」顧客のためのプレフィックスは等距離アルゴリズムを使用して、または[RIPE_Nov07]スパースアロケーションアルゴリズム（SAA）と同様のメカニズムを使用してのいずれかにより、対応する「ビッグ顧客」プールから選択することができます。
A.2.2.1.2. "Common" Customers
A.2.2.1.2。 「共通」お客様
All customers that are not "big" customers are considered as "common" customers. They represent the majority of customers, hence they receive a /48 out of the IPv6 customer address pool of the LER where they are directly connected or aggregated.
「ビッグ」の顧客ではありませんすべてのお客様は、「一般的な」顧客として考えられています。彼らは、それゆえ、彼らは直接接続または集約されているLERのIPv6の顧客アドレスプールの外に/ 48を受け取り、顧客の大半を表します。
Again a 100-300% future growing IPv6 address range is reserved for each customer, so that a "common" customer receives a /48 allocation but has a /47 or /46 reserved.
「共通」顧客が/ 48の割り当てを受信するが、予約/ 47または/ 46を有するように、再び100から300パーセントの将来の成長のIPv6アドレス範囲は、各顧客のために予約されています。
(Note: If it is obvious that the likelihood of needing a /47 or /46 in the future is very small for a "common" customer, then no growing buffer should be reserved for it, and only a /48 will be assigned without any growing buffer.)
（注：将来的に/ 47または/ 46を必要とする可能性が「普通」の顧客のために非常に小さく、その後、何の成長バッファはそれのために確保すべきではない、とだけ/ 48はせずに割り当てられるであろうことは明らかである場合任意の成長バッファー。）
In the network access scenarios where the customer is directly connected to the LER, the customer prefix is directly taken out of the customer IPv6 address aggregate (e.g., /38) of the corresponding LER.
顧客が直接LERに接続されたネットワークアクセスシナリオでは、顧客のプレフィックスは直接対応するLERの顧客IPv6アドレスの集合体（例えば、/ 38）から取り出されます。
For other cases (e.g., the customer is attached to a RAR that is itself aggregated to an AG or to a LER-BB), at least 2 different approaches are possible.
他のケースでは、少なくとも2つの異なるアプローチが可能である（例えば、顧客は、それ自体がAGまたはLER-BBに集約されているRARに取り付けられています）。
1) Mapping of Aggregation Network Hierarchy into Customer IPv6 Addressing Schema. The aggregation network hierarchy could be mapped into the design of the customer prefix pools of each network level in order to achieve a maximal aggregation at the LER level as well as at the intermediate levels. (Example: Customer - /48, RAR - /38, AG - /32, LER-BB - /30). At each network level, an adequate growing zone should be reserved. (Note: Of course, this approach requires some "fine tuning" of the addressing schema based on a very good knowledge of the Service Provider network topology including actual growing ranges and rates.)
スキーマへの対応顧客のIPv6への集約ネットワーク階層の1）のマッピング。アグリゲーションネットワーク階層は、LERレベルならびに中間レベルで最大の凝集を達成するために、各ネットワークレベルの顧客プレフィックスプールの設計にマッピングすることができます。 （例：顧客 - / 48、RAR - / 38、AG - / 32、LER-BB - / 30）。各ネットワークレベルでは、十分な成長ゾーンが確保されなければなりません。 （注：もちろん、このアプローチは、実際の成長範囲や料金など、サービスプロバイダーのネットワークトポロジの非常に良い知識に基づいて対処するスキーマの一部の「微調整」が必要。）
When the IPv6 customer address pool of a LER (or another device
of the aggregation network -- AG or RAR) is exhausted, the
related LER (or AG or RAR) prefix is shortened by 1 or 2 bits
(e.g., from /38 to /37 or /36) so that the originally reserved
growing zone can be used for further IPv6 address allocations to customers. In the case where this growing zone is exhausted as
well, a new prefix range from the corresponding pool of the next-
higher hierarchy level can be requested.
2) "Flat" Customer IPv6 Addressing Schema. The other option is to allocate all the customer prefixes directly out of the customer IPv6 address pool of the LER where the customers are attached and aggregated and to ignore the intermediate aggregation network infrastructure. Of course, this approach leads to a higher amount of customer routes at the LER and aggregation network level, but it takes a great amount of complexity out of the addressing schema. Nevertheless, the aggregation of the customer prefixes to one prefix at the LER level is realized as required above.
2）「フラット」顧客のIPv6は、スキーマへの対応します。他のオプションは、直接顧客が取り付けられ、集約されるLERの顧客IPv6アドレスプールからすべての顧客プレフィックスを割り当てるように中間集約ネットワークインフラストラクチャを無視することです。もちろん、このアプローチは、LERとアグリゲーションネットワークレベルで顧客ルートの高い量につながり、それがアドレッシングスキーマのうちの複雑さの偉大な量を要します。それにもかかわらず、LERレベルで1つのプレフィックスへの顧客プレフィックスの集合は、上記の必要に応じて実現されます。
Note: The handling of changes (e.g., technically triggered changes) within the ISP access network is discussed briefly in Appendix A.2.3.5.
注：ISPアクセスネットワーク内の変更（例えば、技術的にトリガー変更）の処理は、付録A.2.3.5に簡単に説明されています。
If the actual observed growing rates show that the reserved growing zones are not needed, then they can be freed and used for assignments for prefix pools to other devices at the same level of the network hierarchy.
実際の観測成長率を禁じ成長ゾーンが必要とされていないことが示された場合は、その後、彼らは解放され、ネットワーク階層の同じレベルで他のデバイスへのプレフィックスプールの割り当てのために使用することができます。
A.2.2.2. Defining an IPv6 Address Allocation Plan for the Service Provider Network Infrastructure
A.2.2.2。サービスプロバイダーのネットワークインフラストラクチャのIPv6アドレス割当計画の定義
For the IPv6 addressing of the SP's own network infrastructure, a /32 (or /40) from the "big" customers address pool can be chosen.
「大」顧客からSP独自のネットワークインフラストラクチャのIPv6アドレス、/ 32（または/ 40）のためにプールを選択することができ取り組みます。
This SP infrastructure prefix is used to code the network infrastructure of the SP by assigning a /48 to every POP/location and using (for instance) a /56 for coding the corresponding router within this POP. Each SP internal link behind a router interface could be coded using a /64 prefix. (Note: While it is suggested to choose a /48 for addressing the POP/location of the SP network, it is left to each SP to decide what prefix length to assign to the routers and links within the POP.)
このSPインフラプレフィックスは、すべてのPOP /場所に/ 48を割り当て、このPOP内の対応するルータを符号化するためにA / 56（例えば）を使用して、SPのネットワークインフラストラクチャを符号化するために使用されます。ルータインターフェイスの背後にある各SP内部リンクは/ 64のプレフィックスを使用して符号化することができます。 （注：SPネットワークのPOP /場所に対処するための/ 48を選択することが示唆されたが、POP内のルータとリンクに割り当てるためにどのような接頭辞の長さを決めるために、各SPに任されています。）
The IIDs of the router interfaces may be generated by using EUI-64 or through plain manual configuration, e.g., for coding additional network or operational information into the IID.
ルータインターフェイスのIIDは、IIDに追加のネットワークや運用情報を符号化するために、例えば、EUI-64またはプレーン手動設定介しを用いて生成することができます。
Again, it is assumed that 100-300% growing zones are needed for each level of network hierarchy, and additional prefix bits may be assigned to POPs and/or routers if needed.
再び、100から300パーセント成長ゾーンがネットワーク階層の各レベルのために必要とされる、必要に応じて追加のプレフィックスビットのPOPおよび/またはルータに割り当てられてもよいことが想定されます。
Loopback interfaces of routers may be chosen from the first /64 of the /56 router prefix (in the example above).
ルータのループバックインターフェイスは、（上記の例では）/ 56ルータプレフィックスの最初の/ 64から選択することができます。
(Note: The /32 (or /40) prefix that has been chosen for addressing the SP's own IPv6 network infrastructure leaves enough space to code additional functionalities like security levels or private and test infrastructure, although such approaches haven't been considered in more detail for the above-described SP until now.)
（注：このようなアプローチは、より多くのでは考慮されていないが、SPの独自のIPv6ネットワークインフラストラクチャに対処するために選択されている/ 32（または/ 40）プレフィックスは、セキュリティレベルや民間とテストインフラなどの追加機能をコーディングするのに十分なスペースを残し今まで、上述したSPの詳細）。
Point-to-point links to customers (e.g., PPP links, dedicated lines, etc.) may be addressed using /126 prefixes out of the first /64 of the access routers that could be reserved for this reason.
顧客へのポイントツーポイントリンク（例えば、PPPリンク、専用線など）は、この理由のために予約することができたアクセスルータの第一/ 64から/ 126接頭辞を使用して対処することができます。
A.2.3. Additional Remarks
A.2.3。付言
A.2.3.1. ULA
A.2.3.1。 ULA
There are no compelling reasons for service providers to use ULAs. See Section 2.2.
サービスプロバイダーはULAsを使用するための説得力のある理由がありません。 2.2節を参照してください。
ULAs could be used inside the SP network in order to have an additional "site-local scoped" IPv6 address for the SP's own infrastructure, for instance, for network management reasons and in order to have an addressing schema that can't be reached from outside the SP network.
ULAsは、ネットワーク管理上の理由から到達できないのアドレッシングスキーマを持たせるために、例えば、SP自身の基盤のための追加の「サイトローカルスコープ」のIPv6アドレスを持つために、SPネットワーク内で使用することができSPネットワークの外。
When ULAs are used, it is possible to map the proposed internal IPv6 addressing of the SP's own network infrastructure (as described in Appendix A.2.2.2) directly to the ULA addressing schema by substituting the /48 POP prefix with a /48 ULA site prefix.
ULAsが使用される場合、ULA / 48と/ 48 POP接頭辞を置換することによって直接ULAアドレッシングスキーマに（付録A.2.2.2に記載されているように）SP自身のネットワークインフラストラクチャのアドレッシング提案内部IPv6をマッピングすることが可能ですサイト接頭辞。
A.2.3.2. Multicast
A.2.3.2。マルチキャスト
IPv6 multicast-related addressing issues are out of the scope of this document.
IPv6のマルチキャスト関連の問題に対処するには、この文書の範囲外です。
A.2.3.3. POP Multihoming
A.2.3.3。 POPのマルチホーミング
POP multihoming (or better, LER multihoming) of customers with the same SP can be realized within the proposed IPv6 addressing schema of the SP by assigning multiple LER-dependent prefixes to this customer (i.e., considering each customer location as a single customer) or by choosing a customer prefix out of the pool of "big" customers. The second solution has the disadvantage that in every LER where the customer is attached, this prefix will appear inside the IGP routing table, thus requiring an explicit MPLS label.
同じSPと顧客のPOPマルチホーミング（以上、LERマルチホーミング）は（すなわち、単一の顧客、各顧客の位置を考慮して）、またはこの顧客に複数LER依存プレフィックスを割り当てることによって、SPの提案されたIPv6アドレス指定スキーマ内で実現することができます「ビッグ」のお客様のプールのうち、顧客のプレフィックスを選択することもできます。第2の解決策は、顧客が取り付けられているすべてのLERに、このプレフィックスは、このように明示的にMPLSラベルを必要とする、IGPルーティングテーブルの内部に表示されるという欠点を有します。
Note: The negative effects (described above) of POP/LER multihoming on the addressing architecture in the SP access network are not resolved by implementing the Site Multihoming by IPv6 Intermediation (SHIM6) approach. SHIM6 only targets a mechanism for dealing with multiple prefixes in end systems. The SP is expected to have unaggregated customer prefixes in its internal routing tables.
注：SPアクセスネットワーク内のアドレス体系にPOP / LERマルチホーミングの（上述の）負の影響は、IPv6仲介（SHIM6）アプローチによってサイトマルチホーミングを実装することによって解決されていません。 SHIM6はエンドシステムに複数のプレフィックスに対処するためのメカニズムを対象としています。 SPは、その内部ルーティングテーブルに凝集していない顧客のプレフィックスを持つことが期待されています。
A.2.3.4. Changing the Point of Network Attachment
A.2.3.4。ネットワーク接続のポイントを変更します
In the possible case that a customer has to change its point of network attachment to another POP/LER within the ISP access network, two different approaches can be applied, assuming that the customer uses PA addresses out of the SP aggregate:
顧客がISPアクセスネットワーク内の別のPOP / LERへのネットワーク接続点を変更する必要がある可能ケースでは、2つの異なるアプローチが、顧客がPAはSPの集合体のうちのアドレスを使用することを仮定して、適用することができます。
1) The customer has to renumber its network with an adequate customer prefix out of the aggregate of the corresponding LER/RAR of its new network attachment. To minimize the administrative burden for the customer, the prefix should be of the same size as the former. This conserves the IPv6 address aggregation within the SP network (and the MPLS label space) but adds additional burden to the customer. Hence, this approach will most likely only be chosen in the case of "small customers" with temporary addressing needs and/or prefix delegation with address autoconfiguration.
1）顧客は、新しいネットワーク接続の対応LER / RARの集合体のうちの適切な顧客プレフィックスとのネットワークの番号を変更しなければなりません。顧客の管理上の負担を最小限に抑えるために、接頭辞は元と同じサイズでなければなりません。これは、SPネットワーク内のIPv6アドレス集約（およびMPLSラベルスペース）を節約できますが、顧客に追加負担を追加します。したがって、このアプローチは、最も可能性が高いだけでアドレス自動設定と一時的に対処する必要性および/またはプレフィックス委任と「小さな顧客」の場合に選択されます。
2) The customer does not need to renumber its network and keeps its address aggregate.
2）お客様がそのネットワーク番号を付け直す必要があり、そのアドレス集約を保持しません。
This approach leads to additional more-specific routing entries
within the IGP routing table of the LER and will hence consume
additional MPLS labels, but it is totally transparent to the
customer. Because this results in additional administrative
effort and will stress the router resources (label space, memory)
of the ISP, this solution will only be offered to the most
valuable customers of an ISP (e.g., "big customers" or
"enterprise customers").
Nevertheless, the ISP again has to find a fair trade-off between customer renumbering and sub-optimal address aggregation (i.e., the generation of additional more-specific routing entries within the IGP and the waste of MPLS label space).
それにもかかわらず、ISPが再度フェアトレードオフの顧客番号を付け替えると次善アドレス集合との間を見つけなければならない（すなわち、IGP内の追加のより具体的なルーティングエントリの生成及びMPLSラベル空間の浪費）。
A.2.3.5. Restructuring of SP (Access) Network and Renumbering
A.2.3.5。 SPの再構築（アクセス）ネットワークとリナンバリング
A technically triggered restructuring of the SP (access) network (for instance, because of split of equipment or installation of new equipment) should not lead to a customer network renumbering. This challenge should be handled in advance by an intelligent network design and IPv6 address planning.
（なぜなら機器や新しい機器の設置のスプリットのインスタンスのために、）技術的にトリガされたSPの再編（アクセス）ネットワークは、顧客のネットワークのリナンバリングにつながるべきではありません。この課題は、インテリジェントネットワークの設計およびIPv6アドレス計画によって事前に処理する必要があります。
In the worst case, the customer network renumbering could be avoided through the implementation of more-specific customer routes. (Note: Since this kind of network restructuring will mostly happen within the access network (at the level) below the LER, the LER aggregation level will not be harmed and the more-specific routes will not consume additional MPLS label space.)
最悪の場合には、顧客ネットワークのリナンバリングは、より多くの固有の顧客ルートの実装により回避することができます。 （注：ネットワークの再構築のこの種はほとんどLER未満）レベル（アクセス・ネットワーク内で起こるので、LER凝集レベルが損なわれず、より特異的なルートは、追加のMPLSラベルスペースを消費しません。）
A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases
A.2.3.6。その後のIPv6移行フェーズに必要な拡張機能
The proposed IPv6 addressing schema for an SP needs some slight enhancements / modifications for the later phases of IPv6 integration, for instance, when the whole MPLS backbone infrastructure (LDP, IGP, etc.) is realized over IPv6 transport, and an IPv6 addressing of the LSRs is needed. Other changes may be necessary as well but should not be explained at this point.
SPのための提案されたIPv6アドレス指定スキーマ全体MPLSバックボーンインフラストラクチャ（LDP、IGPなど）のIPv6トランスポートを介して実現されているインスタンスのために、IPv6の統合の後の段階のためにいくつかのわずかな拡張/変更を必要とIPv6は、アドレッシングLSRが必要とされています。その他の変更も同様に必要になることがありますが、この時点で説明すべきではありません。
Appendix B. Considerations for Subnet Prefixes Different than /64
/ 64と異なるサブネットプレフィックス付録B.の考慮事項
B.1. Considerations for Subnet Prefixes Shorter than /64
B.1。サブネットプレフィックスのための考慮事項より短い/ 64
An allocation of a prefix shorter then 64 bits to a node or interface is considered bad practice. One exception to this statement is when using 6to4 technology where a /16 prefix is utilized for the pseudo-interface [RFC3056]. The shortest subnet prefix that could theoretically be assigned to an interface or node is limited by the size of the network prefix allocated to the organization.
ノードまたはインタフェース64ビットより短いプレフィックスの割り当てが悪い習慣であると考えられます。 / 16プレフィックスが擬似インタフェース[RFC3056]のために利用されるの6to4技術を使用する場合、この文には1つの例外があります。理論的インタフェースまたはノードに割り当てることができる最短のサブネットプレフィックスは、組織に割り当てられたネットワークプレフィックスのサイズによって制限されます。
A possible reason for choosing the subnet prefix for an interface shorter than /64 is that it would allow more nodes to be attached to that interface compared to a prescribed length of 64 bits. The prescribed /64 does include 2 functional bits, the 'g' bit and the inverted 'u' (universal/local) bit and these can not be chosen at will. However, a larger address space then a /64 is unnecessary for most networks, considering that 2^62 provides plenty of node addresses.
界面より短い/ 64のサブネットプレフィックスを選択するための可能な理由は、より多くのノードが64ビットの所定の長さに比べて、そのインターフェイスに接続することを可能にすることです。規定/ 64は、2官能ビット、これらの自由に選択することができない「G」ビット及び反転「U」は（ユニバーサル/ローカル）ビットとが含まれています。しかし、その後、より大きなアドレス空間/ 64は、2 ^ 62は、ノードアドレスの多くを提供することを考慮すると、ほとんどのネットワークには不要です。
The subnet prefix assignments can be made by manual configuration, by a stateful Host Configuration Protocol [RFC3315], by a stateful prefix delegation mechanism [RFC3633], or implied by stateless autoconfiguration from prefix Router Advertisements (RAs).
サブネットプレフィックスの割り当ては、ステートフルプレフィックス委譲機構[RFC3633]で、ステートフルなホスト構成プロトコル[RFC3315]で、手動設定製、又は接頭ルータ広告（RAS）からステートレス自動設定によって暗示することができます。
B.2. Considerations for Subnet Prefixes Longer than /64
B.2。サブネットプレフィックスのための考慮事項よりも長い/ 64
The following subsections describe subnet prefix values that should be avoided in deployments because nodes who assume that the subnet prefix is /64 could treat them incorrectly.
以下のサブセクションでは、サブネットプレフィックスが/ 64であることを前提としていたノードが誤ってそれらを扱う可能性があるため、展開に避けるべきサブネットプレフィックス値を記述する。
B.2.1. /126 Addresses
B.2.1。 / 126アドレス
126-bit subnet prefixes are typically used for point-to-point links similar to a the IPv4 address-conservative /30 allocation for point-to-point links. The usage of this subnet address length does not lead to any considerations beyond those discussed earlier in this section, particularly those related to the 'u' and 'g' bits (see B.2.4.
126ビットのサブネットプレフィックスは、典型的には、ポイントツーポイントリンクのIPv4アドレス保存的/ 30割当と同様のポイントツーポイントリンクのために使用されます。このサブネットアドレス長の使用は、この節で前に説明したもの以外の任意の考察、「U」と「G」ビット（B.2.4を参照に関連し、特にそれらにはつながりません。
B.2.2. /127 Addresses
B.2.2。 / 127アドレス
The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 [RFC3021], is not valid and should be strongly discouraged as documented in RFC 3627 [RFC3627].
/ 127アドレスはIPv4のRFC 3021 [RFC3021]の当量の使用は、有効ではなく、RFC 3627 [RFC3627]に記載されているように強く推奨されるべきです。
B.2.3. /128 Addresses
B.2.3。 / 128アドレス
The 128-bit address prefix may be used in those situations where we know that one, and only one, address is sufficient. Example usage would be the off-link loopback address of a network device.
128ビットのアドレスプレフィックスは、私たちが1、一つだけ、アドレスが十分であることを知っているような状況で使用することができます。使用例は、ネットワーク機器のオフリンクのループバックアドレスになります。
When choosing a 128 bit prefix, it is recommended to take the 'u' and 'g' bits into consideration and to make sure that there is no overlap with any of the following well-known addresses:
128ビットのプレフィックスを選択するとき、それを考慮に「U」と「G」ビットを取るために、以下のよく知られたアドレスのいずれかとの重複がないことを確認することをお勧めします：
o Subnet Router Anycast Address
Oサブネットルータエニーキャストアドレス
o Reserved Subnet Anycast Address
O予約サブネットエニーキャストアドレス
o Addresses used by Embedded-RP
組み込み-RPで使用されるOアドレス
o ISATAP Addresses
OのISATAPアドレス
B.2.4. EUI-64 'u' and 'g' Bits
B.2.4。 EUI-64 'U' と 'G' ビット
When using subnet prefix lengths other than /64, the interface identifier cannot be in Modified EUI-64 format as required by [RFC4291]. However, nodes not aware that a prefix length other than /64 is used might still think it's an EUI-64; therefore, it's prudent to take into account the following points when setting the bits.
より/ 64他のサブネットプレフィックス長を使用する場合は、[RFC4291]によって必要とされるように、インタフェース識別子が変形EUI-64フォーマットであることはできません。しかし、/ 64以外のプレフィックス長は、まだそれがEUI-64だと思うかもしれません使用されていることを認識していないノード。したがって、それはビットを設定する際に考慮に入れ、以下の点を取ることが賢明です。
Address space conservation is the main motivation for using a subnet prefix length longer than 64 bits; however, this kind of address conservation is of little benefit compared with the additional considerations one must make when creating and maintaining an IPv6 addressing plan.
アドレス空間の節約は、長さが64ビットよりサブネットプレフィックス長を使用する主な動機です。しかし、アドレス保全のこの種は、1がIPv6アドレス計画を作成し、維持するときにする必要があり、追加の考慮事項と比べて少し有益です。
The address assignment can be made either by manual configuration or by a stateful Host Configuration Protocol [RFC3315].
アドレスの割り当ては、手動設定するか、ステートフルなホスト構成プロトコル[RFC3315]のいずれかによって行うことができます。
When assigning a subnet prefix of more then 70 bits, according to RFC 4291 [RFC4291], 'u' and 'g' bits (the 71st and 72nd bit, respectively) need to be taken into consideration and should be set correctly.
RFC 4291 [RFC4291]によれば、より後、70ビットのサブネットプレフィックスを割り当てるとき、「U」と「G」ビット（第71および第72ビット、それぞれ）が考慮される必要があり、正しく設定されなければなりません。
The 71st bit of a IPv6 address is the inverted 'u' (universal/local) bit and is used to determine whether the address is universally or locally administered. If 1, the IEEE, through the designation of a unique company ID, has administered the address. If 0, the address is locally administered. The network administrator has overridden the manufactured address and specified a different address.
IPv6アドレスの第71ビットは「U」（ユニバーサル/ローカル）ビット反転したアドレスが普遍的または局所的に投与されるか否かを決定するために使用されます。 1場合は、IEEEは、ユニークな企業IDの指定によって、アドレスを投与しました。 0の場合、アドレスが局所投与されます。ネットワーク管理者は、製造されたアドレスを上書きして別のアドレスを指定しています。
The 'g' (the individual/group) bit is the 72nd bit and is used to determine whether the address is an individual address (unicast) or a group address (multicast). If '0', the address is a unicast address. If '1', the address is a multicast address.
「G」（個人/グループ）ビットは第72ビットで、アドレスが個別アドレス（ユニキャスト）またはグループアドレス（マルチキャスト）であるか否かを決定するために使用されます。 「0」場合は、アドレスがユニキャストアドレスです。 「1」の場合は、アドレスがマルチキャストアドレスです。
In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bits is marginal and typically will not give an error when configured wrongly; however, future implementations may turn out differently if they process the 'u' and 'g' bits in IEEE-like behavior.
現在のIPv6プロトコルスタックでは、「U」と「G」ビットの妥当性は限界であり、典型的に誤って設定したときにエラーを与えないであろう。彼らはIEEEのような振る舞いに「U」と「G」ビットを処理する場合は、将来の実装が異なっなるかもしれません。
When using subnet lengths longer then 64 bits, it is important to avoid selecting addresses that may have a predefined use and could confuse IPv6 protocol stacks. The alternate usage may not be a simple unicast address in all cases. The following points should be considered when selecting a subnet length longer then 64 bits.
サブネットがより長い64ビット長使用する場合は、事前に定義された用途を有することができ、IPv6プロトコルスタックを混乱させる可能性がアドレスを選択しないようにすることが重要です。代替的な使用は、全ての場合において、単純なユニキャストアドレスではないかもしれません。 64ビットより長いサブネット長さを選択する際、以下の点が考慮されるべきです。
B.2.5. Anycast Addresses
B.2.5。エニーキャストアドレス
B.2.5.1. Subnet Router Anycast Address
B.2.5.1。サブネットルータエニーキャストアドレス
RFC 4291 [RFC4291] provides a definition for the required Subnet Router Anycast Address as follows:
次のようにRFC 4291 [RFC4291]は、必要なサブネットのルータエニーキャストアドレスの定義を提供します。
| n bits | 128-n bits |
+--------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+
It is recommended to avoid allocating this IPv6 address to a device that expects to have a normal unicast address.
通常のユニキャストアドレスを持っていることを期待デバイスに、このIPv6アドレスを割り当てないことをお勧めします。
B.2.5.2. Reserved IPv6 Subnet Anycast Addresses
B.2.5.2。予約済みのIPv6サブネットエニーキャストアドレス
RFC 2526 [RFC2526] stated that within each subnet, the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses.
RFC 2526 [RFC2526]は各サブネット内で、最高128インタフェース識別子値がサブネットエニーキャストアドレスとして割り当てのために予約されていると述べました。
The construction of a reserved subnet anycast address depends on the type of IPv6 addresses used within the subnet, as indicated by the format prefix in the addresses.
アドレスにフォーマット接頭辞によって示されるように予約されたサブネットエニーキャストアドレスの構成は、サブネット内で使用されるIPv6アドレスのタイプに依存します。
The first type of Subnet Anycast addresses have been defined as follows for the Modified EUI-64 format:
変形EUI-64フォーマットのために次のようにサブネットエニーキャストアドレスの最初のタイプは定義されています。
| 64 bits | 57 bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111110111...111 | anycast ID |
+------------------------------+------------------+------------+
The anycast address structure implies that it is important to avoid creating a subnet prefix where the bits 65 to 121 are defined as "1111110111...111" (57 bits in total) in order to prevent confusion.
エニーキャストアドレス構造体は、121ビット65は、混乱を防ぐために「1111110111 ... 111」（合計57ビット）として定義されているサブネットプレフィックスを作成しないことが重要であることを意味します。
For other IPv6 address types (that is, with format prefixes other than those listed above), the interface identifier is not in 64-bit extended unique identifier (EUI-64) format and may not be 64 bits in length. The reserved subnet anycast addresses for such address types are constructed as follows:
他のIPv6アドレスタイプ（形式は上記以外の接頭辞を持つことがある）のために、インタフェース識別子は、64ビットの一意の識別子（EUI-64）フォーマットを拡張し、長さが64ビットでなくてもよいではありません。次のようなアドレスの種類の予約サブネットエニーキャストアドレスが構築されています。
| n bits | 121-n bits | 7 bits |
+------------------------------+------------------+------------+
| subnet prefix | 1111111...111111 | anycast ID |
+------------------------------+------------------+------------+
| interface identifier field |
It is recommended to avoid allocating this IPv6 address to a device that expects to have a normal unicast address.
通常のユニキャストアドレスを持っていることを期待デバイスに、このIPv6アドレスを割り当てないことをお勧めします。
B.2.6. Addresses Used by Embedded-RP ()
B.2.6。組み込み-RPによって使用されているアドレス（）
Embedded-RP [RFC3956] reflects the concept of integrating the Rendezvous Point (RP) IPv6 address into the IPv6 multicast group address. Due to this embedding and the fact that the length of the IPv6 address AND the IPv6 multicast address are 128 bits, it is not possible to have the complete IPv6 address of the multicast RP embedded as such.
埋め込み-RP [RFC3956]はIPv6マルチキャストグループアドレスにランデブーポイント（RP）のIPv6アドレスを統合する概念を反映しています。これにより埋め込みとIPv6アドレスとIPv6マルチキャストアドレスの長さは128ビットであるという事実のために、そのような埋め込まれたマルチキャストRPの完全なIPv6アドレスを持つことは不可能です。
This results in a restriction of 15 possible RP-addresses per prefix that can be used with embedded-RP. The space assigned for the embedded-RP is based on the 4 low-order bits, while the remainder of the Rendezvous Interface ID (RIID) is set to all '0'. The format of the IPv6 multicast group address used by embedded-RP is as follows:
これは、組み込みRPと共に使用することができるプレフィックス当たり15可能RP-アドレスの制限をもたらします。ランデブーインタフェースID（RIID）の残りはすべてに設定されている埋め込み-RPに割り当てられた空間は、下位4ビットに基づいている「0」。次のように埋め込まれ、RPが使用するIPv6マルチキャストグループアドレスの形式は次のとおりです。
(IPv6-prefix (64 bits))(60 bits all '0')(RIID)
（IPv6のプレフィクス（64ビット））（60ビット全て '0'）（RIID）
where: (RIID) = 4 bits.
ここで：（RIID）が4ビット=。
This format implies that when selecting subnet prefixes longer than 64, and when the bits beyond the 64th bit are non-zero, the subnet cannot use embedded-RP.
このフォーマットは、64より長いサブネットプレフィックスを選択するとき、および64番目のビットを超えてビットが非ゼロである場合、サブネットは埋め込み-RPを使用することができないことを意味します。
In addition, it is discouraged to assign a matching embedded-RP IPv6 address to a device that is not a real Multicast Rendezvous Point, even though it would not generate major problems.
また、大きな問題を発生しませんにもかかわらず、実際のマルチキャストランデブーポイントではないデバイスへのマッチング埋め込ま-RPのIPv6アドレスを割り当てることが推奨されていません。
B.2.7. ISATAP Addresses
B.2.7。 ISATAPアドレス
ISATAP [RFC5214] is an experimental automatic tunneling protocol used to provide IPv6 connectivity over an IPv4 campus or enterprise environment. In order to leverage the underlying IPv4 infrastructure, the IPv6 addresses are constructed in a special format.
ISATAP [RFC5214]はIPv4のキャンパスまたは企業環境上のIPv6接続性を提供するために使用される実験自動トンネリングプロトコルです。基礎となるIPv4インフラストラクチャを活用するためには、IPv6アドレスは、特殊な形式で構築されています。
An IPv6 ISATAP address has the IPv4 address embedded, based on a predefined structure policy that identifies them as an ISATAP address. The format is as follows:
IPv6 ISATAPアドレスがISATAPアドレスとしてそれらを識別する所定の構造ポリシーに基づいて、埋め込まれたIPv4アドレスを有しています。形式は次のとおりです。
[IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address]
【のIPv6プレフィックス（64ビット）] [0000：5EFE] [IPv4アドレス]
When using a subnet prefix length longer then 64 bits, it is good engineering practice to ensure that the portion of the IPv6 prefix from bit 65 to the end of the host-ID does not match with the well-known ISATAP [0000:5EFE] address when assigning an IPv6 address to a non-ISATAP interface.
もう次に64ビットのサブネットプレフィックス長を使用する場合、ビット65からホストIDの端にIPv6プレフィックスの部分は、周知のISATAP [：5EFE 0000]と一致しないことを確実にするために、良好な技術的手法であります非ISATAPインタフェースにIPv6アドレスを割り当てる場合に対処。
Note that the definition of ISATAP does not support multicast.
ISATAPの定義は、マルチキャストをサポートしていないことに注意してください。
Authors' Addresses
著者のアドレス
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 EMail: gunter@cisco.com
ギュンター・ヴァン・デ・ヴェルデシスコシステムズKleetlaan 6aはディーゲム1831ベルギー電話：+32 2704 5473 Eメール：gunter@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, North Carolina USA EMail: cpopovic@cisco.com
シプリアンPopoviciuシスコシステムズ7025から6キットクリーク道路リサーチトライアングルパーク、ノースカロライナ州USA Eメール：cpopovic@cisco.com
Tim Chown University of Southampton Highfield Southampton SO17 1BJ United Kingdom Phone: +44 23 8059 3257 EMail: tjc@ecs.soton.ac.uk
ティムのchown大学サウサンプトンのハイフィールドサウサンプトンSO17 1BJイギリス電話：+44 23 8059 3257 Eメール：tjc@ecs.soton.ac.uk
T-Systems Enterprise Services GmbH Goslarer Ufer 35 Berlin 10589 Germany Phone: +49 30 3497 3124 EMail: Olaf.Bonness@t-systems.com
Tシステムズエンタープライズサービス社Goslarerウーファー35ベルリン10589ドイツ電話：+49 30 3497 3124 Eメール：Olaf.Bonness@t-systems.com
Christian Hahn T-Systems Enterprise Services GmbH Goslarer Ufer 35 Berlin 10589 Germany Phone: +49 30 3497 3164 EMail: HahnC@t-systems.com
クリスチャン・ハーンTシステムズエンタープライズサービス社Goslarerウーファー35ベルリン10589ドイツ電話：+49 30 3497 3164 Eメール：HahnC@t-systems.com