[要約] RFC 5375は、IPv6ユニキャストアドレスの割り当てに関する考慮事項を提供する。その目的は、IPv6ネットワークのアドレス割り当てに関するガイドラインを提供し、効率的で持続可能なアドレス割り当てを促進することである。
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
IPv6ユニキャストアドレス割り当ての考慮事項
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.
Copyright（c）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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の展開のアドレス指定の側面の計画に関連する情報と推奨事項を提供することを目的としています。このドキュメントは、企業とISPネットワークの両方のケーススタディに対処するIPv6を提供します。
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]は、ユニキャスト、anycast、およびマルチキャストの3つの主なタイプのアドレスを定義しています。このドキュメントは、現在2つの主要な割り当てられたタイプがあるユニキャストアドレスに焦点を当てています。グローバルに一意のアドレス（「Globals」）[RFC3587]と一意のローカルIPv6アドレス（ULAS）[RFC4193]。さらに、最近まで、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.
アドレス割り当ての考慮事項は、IPv6ユニキャストアドレスの2つの主要なコンポーネント（つまり、「ネットワークレベルアドレス指定」（サブネットの割り当て）と「インターフェイスID」（サブネット内のインターフェイスの識別）について個別に分析されます。。したがって、このドキュメントには、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:
このドキュメントの一部は、経験豊富なIPv4ネットワークデザイナーがIPv6展開を計画する際に考慮すべき違いを強調しています。
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].
ただし、マルチホームサイトは、2つ以上のサービスプロバイダーが割り当てられたIPv6アドレス範囲からアドレスを展開する場合があります。ここでは、ネットワーク管理者は、これらの範囲がマルチホームインフラストラクチャ環境でどこでどのように使用されるかについて認識を持たなければなりません。複数のプレフィックスの使用の性質は、マルチホームの理由に依存する可能性があります（例えば、Resilienceフェールオーバー、負荷分散、ポリシーベースのルーティング、またはIPv6の変更イベント中のマルチホーム）。IPv6は、RFC 3484 [RFC3484]に記載されているIPv6デフォルトアドレス選択方法を通じて、多重化されたホストのサポートの改善を導入します。したがって、マルチホームのホストには、プレフィックスごと（プロバイダー）が1つ以上、2つ以上のアドレスがあり、そのRFCで説明されているように使用するソースと宛先のアドレスを選択します。ただし、Multihomingには、インターフェイスごとの複数のアドレスを選択する以外に、いくつかの運用上および管理上の負担もあります[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は、IPv4ネットワークに割り当てられたプライベートアドレススペース[RFC1918]に似ていますが、IPv6ネットワークでは、ULAが内部で使用され、グローバルが外部で使用されるGlobalアドレスとともにULASが使用されることが予想される場合があります。したがって、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ビット、つまりA /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プレフィックス（例：a /44）（b）1 /48、または（c）より少ない /48プレフィックス（例：a /56または /64）。上記のすべてのケースでは、[RFC4193]で指定された原則に従ってULASをランダムに選択できます。ただし、（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は独自に展開される場合があります。また、グローバルアドレスを展開する接続されたネットワークでは、ホストがマルチアドレス（1つのグローバルと1つの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.
ULASが引き起こす可能性のある問題の例として、ネットワーク内でIPv6マルチキャストを使用する場合、IPv6デフォルトアドレス選択アルゴリズムは、IPv6マルチキャストストリームのソースアドレスとしてULAを好みます。これは、2つの理由でIPv6マルチキャストストリームをIPv6インターネットに送信する場合の有効なオプションではありません。1つは、これらのアドレスがグローバルにルーティング可能ではないため、そのようなトラフィックの逆パス転送チェックは内部ネットワークの外で失敗します。もう1つの理由は、マルチキャストドメイン制御と境界セキュリティポリシーにより、トラフィックがネットワーク境界を越えない可能性が高いことです。
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.
原則として、ULAは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].
6boneアドレススペースは、地域のインターネットレジストリ（RIRS）が「生産」IPv6プレフィックスの配布を開始する前に使用されました。6boneプレフィックスは、3ffe ::/16のIPv6プレフィックスに共通の最初の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
* VLAN IDをIPv6サブネットIDに変換します
o Redesign
o 再設計
* allocate according to your need
* あなたの必要に応じて割り当てます
o Aggregation
o 集約
* 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、コンテンツ配信、ワイヤレスサービス、インターネットアクセス、セキュリティエリアなど、事前定義されたサービスの特定のプレフィックスを予約することにより。ネットワーク上のこれらのサービスは、トポロジ内でまばらです。
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 :: /7の下で「ランダム」 /48であるULAプレフィックスを展開する多数の「サイト」を備えたネットワークには、それらのプレフィックスが集約されません。したがって、ネットワークには大量の凝集していない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の名前を変更すると、プレフィックスの長さが増加する可能性があります。このため、ベストプラクティスは、サブネットをまばらではなくコンパクトに数え、サブネットを番号付けするときに可能な限り低次ビットを使用することです。言い換えれば、A /48が割り当てられていても、A /56のみが利用可能であるかのように動作します。明らかに、このアドバイスは、A /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 1 /64以上をサイトに割り当てることを検討してください。小さなサイトでは、ゲートウェイデバイスに接続されたインターフェイス間でルーティングを有効にする場合があります。たとえば、A /48を受け取り、異なるメディアタイプ（センサーネットワーク、有線、Wi-Fiなど）の複数のLANを備えた家に位置する、または交通セグメンテーション（自宅、仕事、子供など）は、IPv6の複数のサブネットとルーティングから大きな恩恵を受ける可能性があります。理想的には、住宅のネットワークには、A /48または /56 [RIPE_NOV07]の住所範囲が与えられ、複数 /64サブネットを住宅内で使用できるようにします。
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.
ここでは、ネットワークデザイナーがアドレススペースのアプリケーションのサイズをどのようにサイズ化するかについては説明しません。デフォルトでは、サイトはA /48プレフィックス[RFC3177]を受け取ります。ただし、異なるRIRサービス領域のポリシーは、代替デフォルトの割り当てを提案するか、ISPが特定のケースに対してより適切であると考えていることを決定させる可能性があります（[ARIN]のセクション6.5.4、「LIRS/ISPSからの割り当て」を参照）。RIRSを介したデフォルトのプロバイダー割り当ては、現在A /32 [RIPE_NOV07]です。これらの割り当ては、ネットワークの最初の割り当ての指標です。予想されるアドレスの使用法[RIPE_NOV07]に基づいて、さまざまなサイズが取得される場合があります。執筆時点では、RIRSからプロバイダーに作られた /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.
Subnettingを簡単にすることを可能にする大規模な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では、IPv4のようにアドレスではなく、サイト（たとえば、 /56に基づいて）についてHDが計算されることに注意してください。
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.) 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アドレス指定計画の重要な部分は、各サブネットプレフィックスの長さを決定することです。IPv4とは異なり、IPv6アドレス指定アーキテクチャ[RFC4291]は、グローバルに一意のアドレスとULAを使用してすべてのサブネットが常に64ビットの同じプレフィックス長を持っていることを指定します。（これは、非推奨6BONEおよびサイトローカルアドレスにも適用されます。）このルールの唯一の例外は、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.
A /64以外のサブネットプレフィックスの長さを使用すると、近隣発見（ND）、セキュアネイバーディスカバリー（送信）[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.
ただし、一部のネットワーク管理者は、ルーターを接続するリンクに /64より長いプレフィックスを使用しています。通常、ポイントツーポイントリンク上の2つのルーターのみです。すべてのアドレスが手動構成によって割り当てられ、リンク上のすべてのノードがネットワークで知られているルーター（エンドホストではない）であるリンクでは、管理者は /64サブネットプレフィックスに依存するIPv6機能を必要としません。働ける。Subnetプレフィックスを使用することは /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].
A /64サブネットの長さを使用する場合、これらのアドレスのアドレス割り当ては、手動設定、動的ホスト構成プロトコル[RFC3315]、Stateless Autoconfiguration [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]
RFC 4941 [RFC4941]に基づいて生成されたIIDの主な目的は、IPv6アドレスを使用してエンティティにプライバシーを提供することです。[RFC4941]で定義されているIIDを使用したIIDアドレスの使用には特別な制約はありませんが、RFC 4941 [RFC4941]のセクション4で文書化されているようにプライバシーアドレスを使用する場合に注意すべき意味があります。
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 サブネットルーターANYCASTアドレス（付録B.2.5.1）
o Reserved Subnet Anycast Address (Appendix B.2.5.2)
o 予約されたサブネットのaycastアドレス（付録B.2.5.2）
o Addresses used by Embedded-RP (Appendix B.2.6)
o 埋め込みRPで使用されるアドレス（付録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.
/64以外のサブネットプレフィックスを使用すると、暗号化されたアドレス（CGA）やハッシュベースのアドレス（HBA）などのセキュリティメカニズムを破壊するため、それらに依存するプロトコルを使用することが不可能になることに注意する必要があります。
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レビューサイクル中に建設的なフィードバックと貢献が受け取られ、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、および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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526] Johnson、D。およびS. Deering、「予約済みのIPv6サブネットAnycastアドレス」、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.、White、R.、Fuller、V。、およびD. McPherson、「IPv4ポイントツーポイントリンクで31ビットプレフィックスを使用」、RFC 3021、2000年12月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABおよびIESG、「IPv6に関するIAB/IESGの推奨事項は、サイトへの割り当てアドレス」、RFC 3177、2001年9月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180] Meyer、D。およびP. Lothberg、「233/8での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] Durand、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3531] Blanchet, M., "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block", RFC 3531, April 2003.
[RFC3531] Blanchet、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.、Deering、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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004.
[RFC3701] Fink、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。and B. Carpenter、「Depricating Site Local Addresses」、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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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] Baker、F.、Lear、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. Haberman、「ユニークなローカル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. Li、「IPv6 Multihoming Solutionsに関連する脅威」、RFC 4218、2005年10月。
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers Should Think About", RFC 4219, October 2005.
[RFC4219] Lear、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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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. Deering、「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] de Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用してIPv6 MPLSを介してIPv6島を接続する」、RFC 4798、2007年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866] Arkko、J.、Vogt、C。、およびW. Haddad、「モバイル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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（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 Number Resource Policy Manual」、バージョン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アドレス割り当ておよび割り当てポリシー」、Ripe-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アドレス割り当ておよび割り当てポリシー」、Ripe-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.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.、Thompson、M.、Ford、A。、およびS. Venaas、「IPv6ネットワークを変更するときに考えるべきこと」、2007年3月、進行中の作業。
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ポリシーを決定しません。
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.
このセクションでは、デュアルスタック環境で既存のIPv4プロトコルと並行してIPv6を展開しているキャンパスネットワークのケーススタディを検討します。具体的な例は、サウサンプトン大学（英国）で、そのネットワーク内の大規模な部門に焦点を当てています。展開は現在、約1,000人のホストと1,500人以上のユーザーに及びます。
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.
キャンパスネットワークの場合、サイトは通常、National Research and Education Network（NREN）から接続性を取ります。サウサンプトンは、地域の地域ネットワークレンズ（学習ネットワーク南東）を介して、英国のアカデミックネットワークであるジャネットに接続しています。ジャネットには現在、RIPE NCCから /32の割り当てがあります。現在の推奨慣行は、サイトがA /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アドレス指定は使用されていません。キャンパスはマルチホームではなく（ジャネットは唯一のプロバイダーです）、サービスプロバイダーを変更することを期待していないため、ネットワークの変更を緩和する（認識されている）利点にULASを使用する予定はありません。実際、キャンパスは、前述の変更手続き[RFC4192]に続いて2回、これが適切であることが証明されています（[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月の6bone段階的アウト[RFC3701]以来、ほとんどの輸送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]などの手法を使用して、グローバルにユニークなマルチキャストグループを選択する必要があります。これは、サイトがBorder Gateway Protocol（BGP）[RFC4271]を使用せず、自律システム番号（ASN）を持っていない場合に問題があります。IPv6,0では、Unicast-PrefixベースのIPv6マルチキャストアドレスが、独自のユニキャストサイトまたはリンクプレフィックスに基づいて、グローバルにユニークなグループアドレスを選択できるようになります。埋め込まれたRPも使用されており、IPv6およびマルチキャストの潜在的な利点と見なされており、サイト（米国および英国からのパスを含む）間のプロバイダー全体で正常にテストされています。
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アドレス保存の懸念のため、サブネットは泥だらけです。サブネットは、その中のホストにサイズがあります。たとえば、サブネットに35のホストがある場合、A /26 IPv4プレフィックスが使用されます。これは効率的ですが、物理的な展開が変更されると管理の負担が増加し、DHCPが使用されている場合でもIPv4サブネットがサイズ変更（上下）が必要です。
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を超える）サブネットを備えているという点で、「クラスA」IPv4プレフィックスに大まかに相当しますが、IPv4相当の256と比較して、効果的に無制限のサブネットアドレスサイズ（2^64）を持っています。サブネットサイズの増加は、 /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.
サブネットの割り当て計画には、学校または部門ごとの住所スペースの分割が必要でした。ここで、A /56は大学の学校レベルに割り当てられました。現在、約30の学校があります。IPv6アドレス空間のA /56は、256 /64サブネットの割り当てに相当します。中央ITインフラストラクチャ、ネットワークインフラストラクチャ、およびサーバーサイドシステムのために、さらに /56の割り当てが行われました。
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.
大学は、ジャネットサイトの英国教育研究ネットワーク協会（UKERNA）を代表して、トンネルブローカー[RFC3053]サービスを運営しています。これは、大学のサイトの割り当てではなく、ジャネットからの個別のアドレススペースを使用します。
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ホストのほとんどのサブネットでは、Statelestesteless Autoconfigurationが使用されています。初期コードリリースのテストを超えて、DHCPV6サービスはまだ展開されていません。堅牢なクライアントとサーバーコードが利用可能な場合、アドレス割り当てにDHCPV6を展開することが計画されています（執筆時点で、これの可能性は、たとえば、インターネットシステムコンソーシアム（ISC）の実装を介して見栄えがよくなります）。サウサンプトン大学は、[RFC4477]で説明されているように、統合されたDHCPV4およびDHCPV6サーバーの構成を含む、サーバー自体が共同で共同で配置されていなくても、一般的な統合DHCP/DNS管理プラットフォームも調査しています。現在、動的なDNSがオプションですが、ステートレスにAutoConfiguredアドレスを持つクライアントは手動でDNSに追加されます。ネットワーク管理者は、DHCPがより多くの管理制御を提供すると考えているため、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、Webなど）の問題ではありません。
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の調査結果を示しています。
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.
さまざまな技術的制約とビジネスモデル、およびこれらの要件のさまざまな重み（対応するサービスプロバイダーの観点から）によれば、異なるアドレス指定スキーマが開発および展開される可能性が非常に高いです。それにもかかわらず、付録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 インターネットサービスプロバイダ
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）としての役割において、サービスプロバイダーは、IPv6アドレス指定に関するRIRSのポリシーの制約と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.)
o RFC 3177 [RFC3177]およびいくつかのRIRポリシーで推奨されているように、「一般的な」顧客サイト（通常は個人顧客）は、サービスプロバイダーの集合体からA /48プレフィックスを受け取る必要があります。（注：アドレス指定計画は十分に柔軟であり、RIRSが現在定義しているエンドユーザーの最小割り当てサイズの可能性のある変更を考慮してください。）
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-Ratioを満たすことができる必要があります。この要件は、サービスプロバイダーによるIPv6アドレスの集計の効率的な使用に対する需要に対応しています。（注：0.94の現在有効なIPv6 HD-Ratioは、 /56の割り当てに基づいて、サービスプロバイダーのA /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アドレスの割り当ておよび割り当てポリシーは、RIRSで見つけることができ、多くの面で類似しています。[ripe_nov07]、[ripe_jul07]、[apnic_ipv6]、[lacnic_ipv6]、[afrinic_ipv6]、および[arin]のセクション6を参照してください。
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のインフラストラクチャは、新しい顧客、輸送技術、およびビジネスケースとともに時間とともに変化するため、SPのIPv6アドレス指定スキーマには最適な柔軟性が含まれている必要があります。最適な柔軟性の要件は、強力な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.)
o ISPのマルチレベルネットワーク階層を念頭に置いている間、効率の理由に対処するため、すべての階層レベルをISPのIPv6アドレス指定スキーマにマッピングできるわけではなく、マッピングする必要があることに注意してください。ISPネットワークのより「フラットな」アドレス指定を実装する方が、ネットワーク階層の各レベルにアドレス指定する際にIPv6アドレスの集計の大きなチャンクを失うよりもはるかに良いことがあります。（注：特別な場合は、実際に「小さい」ISPが、レベルの階層なしで完全にフラットなIPv6アドレス指定スキーマを設計および実装することさえ推奨されています。）
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 プロバイダーネットワークのアドレス指定と顧客アドレス指定のデカップリングをお勧めします。（注：強力な集約（例：ポップ、集約ルーター（AG）、またはラベルエッジルーター（LER）レベル）は、ISPネットワーク内で見える顧客ルートの数を制限しますが、IPv6の効率も低下させますスキーマに対処します。そのため、各ISPは、展開する内部集約レベルの数を決定する必要があります。
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".)
o SPのスキーマに対処するIPv6は、顧客側からトリガーされる新しい要件を処理できるように選択する必要があります。たとえば、これは、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は、おそらくこのリストにさらに制約を追加します。
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アドレス割り当てスキーマを開発する必要があります。あらゆる種類のISPに適合する1つのアドレス指定計画を設計することは実用的ではありません（小 /大きく、ルーティング / MPLSベース、アクセス /トランジット、LIR / NO LIRなど）。
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.
o ISPアドレス指定スキーマ内のIPv6アドレス集計のレベルは、実装されたネットワーク構造に強く対応する必要があり、効率の理由によりその数は最小限に抑える必要があります。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 顧客集約の限られた数の集約レベルとサイズは、アドレス指定スキーマの管理を容易にします。これは、以前の「経験則」、つまり柔軟性と比較検討する必要があります。
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からA /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）の背後にあるすべての顧客に割り当てられたプレフィックスは、1つのプレフィックスの下に集約されます。これにより、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プレフィックスは、IPv6プレフィックスをSPの顧客に割り当てるために使用される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.
1. /48（例えば、 /32）より大きいIPv6プレフィックスが必要な、実際の「大規模な」顧客（付録A.2.2.1.1で定義されている）のアドレス指定ニーズを満たすためのプール（ /24）。これらの顧客は、アクセスネットワークのいくつかのポップに接続されていると想定されているため、この顧客プレフィックスはこれらの各ポップで表示されます。
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. 直接顧客接続（専用のラインアクセスなど）を備えたLERのプール（ /24）、および顧客と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. 何らかの集計ネットワーク（例えば、BB-RARまたはダイヤルインの背後にあるDSL顧客など、通常接続されている多数の顧客にサービスを提供するLER（またはLER-BBSなど）の大きなプール（14*/24）RARの背後にある顧客）。
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 IPv6は、各プール内の代表団（エンドカスタマー代表団またはLER自体に専念する集合体）にアドレス指定します）は、将来の成長のために100〜300％の追加のバッファゾーンで選択する必要があります。つまり、対応する顧客または対応するネットワークデバイスの集計の予想される将来の成長率に従って、1つまたは2つの追加のプレフィックスビットを予約する必要があります。
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アドレスの集約からプレフィックスを受け取ります。顧客は、非常に複雑なネットワークインフラストラクチャおよび/または巨大なIPv6アドレスのニーズ（たとえば、非常に大きな顧客番号のため）および/またはSPネットワークの異なるポップへのいくつかのアップリンクを持っている場合、「大きな」顧客と見なされます。
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％の将来の成長ゾーンは、この顧客にとって「予約済み」としてマークされます。たとえば、これは、A /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].
等距離アルゴリズムを使用するか、スパース割り当てアルゴリズム（SAA）[RIPE_NOV07]と同様のメカニズムを使用することにより、「大きな」顧客の接頭辞を「対応する「大手」プールから選択できます。
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カスタマーアドレスプールからA /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.
繰り返しますが、将来の100〜300％の将来のIPv6アドレス範囲は各顧客に予約されているため、「一般的な」顧客はA /48割り当てを受け取りますが、A /47または /46は予約されています。
(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.)
（注：「一般的な」顧客にとっては、将来的にA /47または /46を必要とする可能性が非常に少ないことが明らかな場合、成長するバッファーは予約されてはならず、A /48のみがA /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.
他のケース（たとえば、顧客はそれ自体がAGまたはLER-BBに集約されているRARに添付されます）の場合、少なくとも2つの異なるアプローチが可能です。
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.)
1) 集約ネットワーク階層のマッピング顧客IPv6アドレス指定スキーマへ。集約ネットワーク階層は、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.
LERのIPv6カスタマーアドレスプール（または集約ネットワークの別のデバイス-AGまたはRAR）が使い果たされると、関連するLER（またはAGまたはRAR）プレフィックスが1ビットまたは2ビット（ /38から /38から）短縮されます。/37または /36）そのため、元々予約された成長ゾーンを使用して、IPv6アドレスの顧客へのアドレスをさらに使用できます。この成長ゾーンも使い果たされている場合、新しい接頭辞は、次の高さの階層レベルの対応するプールの範囲を要求できます。
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アドレス指定スキーマ。もう1つのオプションは、顧客が添付および集約されている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.
実際に観察された成長率が、予約された成長ゾーンが不要であることを示している場合、それらは解放され、ネットワーク階層の同じレベルで他のデバイスへのプレフィックスプールの割り当てに使用できます。
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アドレス指定の場合、「大規模な」顧客アドレスプールからのA /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インフラストラクチャプレフィックスは、A /48をすべてのポップ /ロケーションに割り当て、このポップ内の対応するルーターをコーディングするために（たとえば）A /56を使用することにより、SPのネットワークインフラストラクチャをコーディングするために使用されます。ルーターインターフェイスの背後にある各SP内部リンクは、A /64プレフィックスを使用してコーディングできます。（注：SPネットワークのポップ /場所に対処するためにA /48を選択することをお勧めしますが、各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％の成長ゾーンが必要であり、必要に応じて追加のプレフィックスビットをポップおよび/またはルーターに割り当てることができます。
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（OR /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プレフィックスを使用してアドレス指定できます。
There are no compelling reasons for service providers to use ULAs. See Section 2.2.
サービスプロバイダーがULAを使用する説得力のある理由はありません。セクション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ネットワーク内でSPネットワーク内で使用できます。たとえば、ネットワーク管理上の理由により、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を使用すると、SPのネットワークインフラストラクチャの提案された内部IPv6アドレス指定（付録A.2.2.2に記載されているように）を、A /48 ULAに /48 POPプレフィックスに置き換えることにより、ULAアドレス指定スキーマに直接マッピングすることができます。サイトプレフィックス。
IPv6 multicast-related addressing issues are out of the scope of this document.
IPv6マルチキャスト関連のアドレス指定の問題は、このドキュメントの範囲外です。
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で、このプレフィックスがIGPルーティングテーブル内に表示されるため、明示的なMPLSラベルが必要であるという欠点があります。
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には、内部ルーティングテーブルに類似のない顧客のプレフィックスがあると予想されます。
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つの異なるアプローチを適用できます。
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").
このアプローチは、LERのIGPルーティングテーブル内の追加のより固有のルーティングエントリにつながり、したがって追加のMPLSラベルを消費しますが、顧客には完全に透明です。これにより、追加の管理努力が発生し、ISPのルーターリソース（ラベルスペース、メモリ）を強調するため、このソリューションはISPの最も価値のある顧客にのみ提供されます（例：「大手顧客」または「エンタープライズ顧客」）。
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 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以下のアクセスネットワーク内（レベルで）内でほとんど発生するため、集約レベルは害を受けず、より固有のルートは追加のMPLSラベルスペースを消費しません。）
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統合の後期段階のわずかな強化 /変更を必要とします。LSRSが必要です。他の変更も必要になる場合がありますが、この時点で説明すべきではありません。
Appendix B. Considerations for Subnet Prefixes Different than /64
付録B. /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ビットより短いプレフィックスの割り当ては、悪い練習と見なされます。このステートメントの1つの例外は、A /16プレフィックスが擬似インターフェイス[RFC3056]に使用される6to4テクノロジーを使用する場合です。理論的にはインターフェイスまたはノードに割り当てることができる最短サブネットプレフィックスは、組織に割り当てられたネットワークプレフィックスのサイズによって制限されます。
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」（ユニバーサル /ローカル）ビットが含まれており、これらは自由に選択できません。ただし、2^62が多くのノードアドレスを提供することを考慮すると、ほとんどのネットワークではA /64よりも大きなアドレススペースが不要です。
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).
サブネットプレフィックスの割り当ては、ステートフルなホスト構成プロトコル[RFC3315]、ステートフルプレフィックス委任メカニズム[RFC3633]によって、または接頭辞Router Advertisements（RAS）からのStateless Autoconfigurationによって暗示されることによって、手動構成によって作成できます。
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であると仮定するノードがそれらを誤って処理できるため、展開で避けるべきサブネットのプレフィックス値について説明します。
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を参照してください。
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].
IPv4のRFC 3021 [RFC3021]に相当する /127アドレスの使用は、有効ではなく、RFC 3627 [RFC3627]で文書化されているように強く落胆する必要があります。
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つだけが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 サブネットルーターANYCASTアドレス
o Reserved Subnet Anycast Address
o 予約されたサブネットAnycastアドレス
o Addresses used by Embedded-RP
o 埋め込みRPで使用されるアドレス
o ISATAP Addresses
o ISATAPアドレス
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ビットより長いサブネットプレフィックスの長さを使用する主な動機です。ただし、この種のアドレス保存は、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ビットより長いサブネットの長さを選択する場合は、次のポイントを考慮する必要があります。
RFC 4291 [RFC4291] provides a definition for the required Subnet Router Anycast Address as follows:
RFC 4291 [RFC4291]は、次のように、必要なサブネットルーターAnycastアドレスの定義を提供します。
| 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アドレスを通常のユニキャストアドレスがあると予想されるデバイスに割り当てることを避けることをお勧めします。
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インターフェイス識別子値がサブネットのAnycastアドレスとしての割り当てのために予約されていると述べました。
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.
予約されたサブネットのAnycastアドレスの構築は、アドレスの形式のプレフィックスで示されるように、サブネット内で使用されるIPv6アドレスのタイプに依存します。
The first type of Subnet Anycast addresses have been defined as follows for the Modified EUI-64 format:
修正されたEUI-64形式では、最初のタイプのサブネットAnycastアドレスは次のように定義されています。
| 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.
Anycastアドレス構造は、混乱を防ぐために、ビット65〜121が「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ビットではない場合があります。このようなアドレスタイプの予約されたサブネットAnycastアドレスは、次のように構築されます。
| 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アドレスを通常のユニキャストアドレスがあると予想されるデバイスに割り当てることを避けることをお勧めします。
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]は、Rendezvous Point（RP）IPv6アドレスを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アドレスが制限されます。埋め込まれたRPに割り当てられたスペースは4つの低次ビットに基づいており、残りのランデブーインターフェイスID（RIID）はすべての「0」に設定されています。Embedded-RPが使用するIPv6マルチキャストグループアドレスの形式は次のとおりです。
(IPv6-prefix (64 bits))(60 bits all '0')(RIID)
（IPv6-Prefix（64ビット））（60ビットAll '0'）（riid）
where: (RIID) = 4 bits.
WHERE：（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アドレスを実際のマルチキャストランデブーポイントではないデバイスに割り当てることは落胆します。
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アドレスには、IPV4アドレスが組み込まれており、それらをISATAPアドレスとして識別する定義済みの構造ポリシーに基づいています。フォーマットは次のとおりです。
[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ビットより長いサブネットプレフィックスの長さを使用する場合、Bit 65からHost-IDの終わりまでのIPv6プレフィックスの部分がよく知られているISATAP [0000：5EFE]と一致しないことを確認するのが適切なエンジニアリング慣行です。アドレスIPv6アドレスを非ISATAPインターフェイスに割り当てるとき。
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
Gunter Van de Velde Cisco Systems de Kleetlaan 6a Diegem 1831 Belgium電話：32 2704 5473メール：gunter@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, North Carolina USA EMail: cpopovic@cisco.com
Ciprian Popoviciu Cisco Systems 7025-6 Kit Creek Road Research Triangle Park、North Carolina USAメール：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
ティムチャウン大学サウサンプトン大学サウサンプトン大学17 17 1BJ英国電話：44 23 8059 3257メール：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-Systems Enterprise Services GmbH Goslarer Ufer 35 Berlin 10589ドイツ電話：49 30 3497 3124メール：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
Christian Hahn T-Systems Enterprise Services Gmbh Goslarer Ufer 35 Berlin 10589ドイツ電話：49 30 3497 3164メール：hahnc@t-Systems.com