この文書はRFC 5375の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group G. Van de Velde
Request for Comments: 5375 C. Popoviciu
Category: Informational Cisco Systems
T. Chown
University of Southampton
O. Bonness
C. Hahn
T-Systems Enterprise Services GmbH
December 2008
IPv6 Unicast Address Assignment Considerations
ＩＰｖ６ユニキャストアドレス割当の考慮事項
Status of This Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
この文書はインターネット共同体に情報を提供します。これはいかなるイン
ターネット標準も指定しません。この文書の配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
著作権（Ｃ）２００８、ＩＥＴＦ信託と文書の著者と認識される人々。す
べての権利は当方に帰属します。
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.
この文書はＢＣＰ７８とこの文書の出版の日付に実施されているＩＥＴＦ
文書に関するＩＥＴＦ信託の法律条項(http://trustee.ietf.org/license-info)
の適用を受けます。それらがこの文書に関するあなたの権利と制限を記述
するので、慎重にこれらの文書を閲覧してください。
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.
ＩＰ通信基盤の１つの基本的な側面は番号計画(アドレスプラン)です。新し
いアドレス体系と割当方針を伴うＩＰｖ６のネットワークへの導入は、ネッ
トワーク設計者とオペレータが、既存のネットワークアドレスの扱いを再考
する必要性を意味します。ネットワーク設計のこの側面を扱うガイドライン
の不足はＩＰｖ６の展開と統合を減速させるかもしれません。この文書は、
ＩＰｖ６展開のアドレス面の計画と関連している情報と推薦を提供すること
を目指します。また、この文書は事業用ネットワークとＩＳＰネットワーク
の両方のためのＩＰｖ６アドレスケーススタディを提供します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Network-Level Addressing Design Considerations
2. ネットワークレベルアドレス設計の考察
2.1. Globally Unique Addresses
2.1. グローバル一意アドレス
2.2. Unique Local IPv6 Addresses
2.2. ローカル一意ＩＰｖ６アドレス
2.3. 6bone Address Space
2.3. ６ｂｏｎｅアドレス空間
2.4. Network-Level Design Considerations
2.4. ネットワークレベル設計の考察
2.4.1. Sizing the Network Allocation
2.4.1. ネットワーク割当の大きさ
2.4.2. Address Space Conservation
2.4.2. アドレス空間管理
3. Subnet Prefix Considerations
3. サブネットプレフィックスの考察
3.1. Considerations for /64 Prefixes
3.1. /64プレフィックスの考察
4. Allocation of the IID of an IPv6 Address
4. ＩＰｖ６アドレスのＩＩＤ割当
4.1. Automatic EUI-64 Format Option
4.1. 自動ＥＵＩ６４形式手法
4.2. Using Privacy Extensions
4.2. プライバシ拡張の使用
4.3. Manual/Dynamic Assignment Option
4.3. 手動/動的割当手法
5. Security Considerations
5. セキュリティの考察
6. Acknowledgements
6. 謝辞
7. Informative References
7. 有益な参考文献
Appendix A. Case Studies
付録Ａ. 事例研究
A.1. Enterprise Considerations
A.1. 事業用の考察
A.1.1. Obtaining General IPv6 Network Prefixes
A.1.1. 一般ＩＰｖ６ネットワークプレフィックスの取得
A.1.2. Forming an Address (Subnet) Allocation Plan
A.1.2. アドレス(サブネット)割当計画の形成
A.1.3. Other Considerations
A.1.3. その他の考慮
A.1.4. Node Configuration Considerations
A.1.4. ノード構成の考察
A.2. Service Provider Considerations
A.2. サービスプロバイダ問題
A.2.1. Investigation of Objective Requirements for an
IPv6 Addressing Schema of a Service Provider
A.2.1. サービスプロバイダーのＩＰｖ６アドレス計画の
客観的要件の調査
A.2.2. Exemplary IPv6 Address Allocation Plan for a
Service Provider
A.2.2. サービスプロバイダの模範的なＩＰｖ６アドレス割り当
て計画
A.2.3. Additional Remarks
A.2.3. 追加の発言
Appendix B. Considerations for Subnet Prefixes Different than /64
付録Ｂ． /64と異なるサブネットプレフィックスに対する考慮
B.1. Considerations for Subnet Prefixes Shorter than /64
B.1. /64より短いサブネットプレフィックスに対する考慮
B.2. Considerations for Subnet Prefixes Longer than /64
B.2. /64より長いサブネットプレフィックスに対する考察
B.2.1. /126 Addresses
B.2.1. /126アドレス
B.2.2. /127 Addresses
B.2.2. /127のアドレス
B.2.3. /128 Addresses
B.2.3. /128アドレス
B.2.4. EUI-64 'u' and 'g' Bits
B.2.4. ＥＵＩ−６４の'u'と'g'ビット
B.2.5. Anycast Addresses
B.2.5. エニキャストアドレス
B.2.6. Addresses Used by Embedded-RP (RFC 3956)
B.2.6 ．埋込みＲＰで使うアドレス（ＲＦＣ３９５６）
B.2.7. ISATAP Addresses
B.2.7. ISATAP アドレス
1. Introduction
1. はじめに
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].
インターネットプロトコル６版（ＩＰｖ６）アドレス体系[RFC4291]は３つの
主な種類のアドレスを定義します：ユニキャスト、エニキャスト、マルチキャ
スト。この文書はユニキャストアドレスに焦点を合わせます、このアドレスで、
現在２つの主な割当て種別があります：グローバル一意アドレス('globals')
[RFC3587]と、ローカル一意アドレス(ULAs) [RFC4193]。さらに、最近まで、
'実験的'６ｂｏｎｅアドレス空間[RFC3701]がありました、こえは２００６年
６月以降の使用は推奨されません[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.
この文書はＩＰｖ６展開時に考えられるＩＰｖ６ネットワークの設計と計画と
アドレス体系を含んでいます。ネットワークのＩＰｖ６アドレス計画はＩＰｖ６
のみのネットワークや、一部または全ての装置が両方のアドレスを持つ二重ス
タック基盤かもしれません。この考察は、組織に割り当てられたＩＰｖ６アド
レス空間を、ＩＰｖ６ネットワーク設計者が効率的で用心深く割り当てるのを
助けるでしょう。
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.
アドレス割当の考慮事項は、ＩＰｖ６ユニキャストアドレスの２個の主要要素
について別々に分析されます--すなわち、'ネットワークレベルアドレス'
(サブネットの割当)と'インタフェース識別子'(サブネットの中のインタ
フェースの識別)。したがって、この文書はＩＰｖ６ネットワークアドレス割当
の議論とノードとインタフェースのアドレス割当の議論を含んでいます。最終
的に、この文書はアドレス配布計画に関して、サービスプロバイダー(ISP)と事
業用ネットワークの２つの例を提供します。
Parts of this document highlight the differences that an experienced
IPv4 network designer should consider when planning an IPv6
deployment, for example:
この文書の一部では、ＩＰｖ６展開を計画しているとき経験豊富なＩＰｖ４
ネットワーク設計者が考えるべき相違点を強調します、例えば、:
o IPv6 devices will more likely be multi-addressed in comparison
with their IPv4 counterparts.
o おそらく、ＩＰｖ６装置はＩＰｖ４装置に比べて、複数アドレスを扱う可
能性が高いでしょう。
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 ＩＰｖ６サブネットの実際に無制限なサイズ(2^64ビット)は（ＩＰｖ４）
アドレス節約の目的のため、サブネットの大きさを装置数に合わせる要件
を減らします。
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).
私たちがここでサイトやＩＳＰがどのようにグローバルにルーチング可能な
ＩＰｖ６プレフィックスを獲得し続けるかの議論はここではしません。それ
ぞれの場合で、受け取ったプレフィックスはプロバイダーが割り当てた
（ＰＡ）か、プロバイダーから独立（ＰＩ）のどちらかです。
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.
私たちはここでＰＩ方針について議論しません。この文書の報告と推薦は、
使用するアドレスブロックがＰＡかＰＩかと、本質的に関係ありません。
現時点で私たちは、ＩＰｖ６ネットワークがプロバイダーを変更する時、
通常、[RFC4192]で説明されるように、アドレスの付替え過程を経る必要で
あると考えます。別の文書[THINKABOUT]はＩＰｖ６アドレスの付け替え楽に
する推薦をします。
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.
この文書は現在時代遅れになっているサイトローカルアドレスをＵＬＡへ
変更することに関連する実装面について議論しません。いくつかの実装は、
これは推奨しないのですが、サイトローカルアドレスを知っていて、現在の
仕様であるＵＬＡを知りません。その結果、これらの種類のアドレス間での
移行は困難があるかもしれません。
2. Network-Level Addressing Design Considerations
2. ネットワークレベルアドレス設計の考察
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.
この章はＩＰｖ６基盤のネットワークレベルで使用されるＩＰｖ６アドレスの
種類について論じます。考えられているのが、考慮するアドレスはグローバル
一意アドレスとＵＬＡです。また、推奨しない６ｂｏｎｅアドレス空間に関し
てコメントします。
2.1. Globally Unique Addresses
2.1. グローバル一意アドレス
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.
最も一般的に使用されるユニキャストアドレスはグローバル一意アドレス
('globals')でしょう。組織に割り当てられたアドレス空間があり、単一の上流
のプロバイダーを通して唯一のプレフィックスが配備されるならば、重大な問
題はありません。
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].
しかしながら、マルチホームのサイトは２つ以上のサービスプロバイダから
割り当てられたＩＰｖ６アドレス範囲からのアドレスを展開するかもしれま
せん。ここで、ネットワーク管理者は、マルチホーム基盤環境環境のどこで
どのようにこれらの範囲が使用されるかに関する認識を持たなければなりま
せん。複数のプレフィックスの使用はマルチホームが理由かもしれません。
(例えば、柔軟な冗長構成、負荷分散、ポリシ依存のルーティング、ＩＰｖ６
のアドレス変更のイベントの間のマルチホーム)ＩＰｖ６はRFC 3484 [RFC3484]
で説明されたＩＰｖ６デフォルトアドレス選択手順のマルチアドレスホスト
の改良サポートを導入します。その結果、マルチホームホストにはプレフィッ
クス（プロバイダ）毎に複数のアドレスがあり、そのＲＦＣで説明されるよう
に使用するソースアドレスと宛先アドレスを選択します。しかしながら、マル
チホームは、また、インタフェース毎に複数のアドレスを選ぶこと以外に、運
用上と管理上の負担があります[RFC4218] [RFC4219]。
2.2. Unique Local IPv6 Addresses
2.2. ローカル一意ＩＰｖ６アドレス
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.
ＵＬＡは、[RFC3879]で説明された理由で、元々のＩＰｖ６アドレス体系で発
想されたサイトローカルアドレスから置き換えられたものです。ＵＬＡは、サ
イトローカルアドレスを、使用するプレフィックスが世界的に一意である確率
を高くするように改良します、これは(計画的にか偶然の)漏出があったり、
ネットワークが合併されているときに、有益な場合があります。ＵＬＡは、
ＩＰｖ４ネットワークで割当てられたプライベート・アドレス空間[RFC1918]
と類似していますが、ＵＬＡがグローバル一意アドレスと並行して使用され、
ＵＬＡが内部で使用され、グローバル一意アドレスが外部に使用されると予
想される違いがあります。したがって、ＵＬＡを使用する場合はＩＰｖ６の
ＮＡＴの使用を意味しません。
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].
ＵＬＡアドレスの範囲は、ネットワーク管理者が世界的に一意に登録された
ＩＰｖ６アドレス範囲を求めないで、自己のネットワークにＩＰｖ６アドレス
の展開をするのを許します。ＵＬＡプレフィックスはは４８ビットで、すなわ
ち/48で、現在、世界的にルーチング可能なＩＰｖ６アドレス空間からサイト
に割当てる推薦された割当[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.
ＵＬＡを使用したがっているサイトは、(a)複数の/48プレフィックス(例え
ば、/44)、(b)１つの/48、(c)/48より小さいプレフィックス(例えば、/56や
/64)を持つことができます。上記の全ての場合で、ＵＬＡは[RFC4193]で指定
された原則によってランダムに選定できます。しかしながら、(a)の場合、
ランダムに選定されたＵＬＡの使用は、(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.
ＵＬＡはサービスプロバイダと対応するＰＡグローバルアドレスでの変更の
影響を受けない固定したアドレス計画を配備する手段を提供します。その結
果、ネットワーク内部の運用は番号変更の間に影響を受けません。それにも
かかわらず、この種類のアドレスは慎重に使用しなければなりません。
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.
また、ＵＬＡを使用するサイトはグローバルアドレスを配布するかもしれま
せん。孤立しているネットワークでは、ＵＬＡはネットワーク自身に配布さ
れるかもしれません。グローバルなアドレスを配布する接続ネットワークで
は、両方のアドレスが配布されるかもしれません、つまりホストは複数アド
レスで（グローバルが１個とＵＬＡが１個）、ＩＰｖ６デフォルトアドレス
選択アルゴリズムを使用して適切なソースと宛先アドレスを選ぶでしょう、
例えば、ソースと宛先ホストの両方にＵＬＡがある場合、ＵＬＡが選択され
るでしょう。ＵＬＡとグローバルサイトプレフィックスの両方が/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.
ＵＬＡが起す問題の例は、ネットワーク内でＩＰｖ６マルチキャストを使用す
るとき、ＩＰｖ６デフォルトアドレス選択アルゴリズムがＵＬＡをＩＰｖ６マ
ルチキャストのソースアドレスとして優先することです。２つの理由でＩＰｖ６
マルチキャストストリームをＩＰｖ６インターネットに送るとき、これは妥当
な選択ではありません。１つ目は、これらのアドレスがグローバルにルーチン
グ可能でないので、このようなトラフィックのための逆経路検査は内部ネット
ワークの外で失敗するでしょう。他の理由は、マルチキャスト範囲制御と境界
セキュリティポリシのため、おそらくトラフィックがネットワーク境界に達し
ないということです。
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.
プレフィックスがＲＦＣで説明されるように選ばれているなら、原則として、
ＵＬＡプレフィックスは他と異なる確率が高いので、ＩＰｖ４のRFC 1918ア
ドレスよりもＵＬＡは簡単にネットワーク合併を許すでしょう。
2.3. 6bone Address Space
2.3. ６ｂｏｎｅアドレス空間
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].
６ｂｏｎｅアドレス空間は地域インターネット登記所（ＲＩＲ）が'商用
'ＩＰｖ６プレフィックスを配布し始める前に使用されました。６ｂｏｎｅ
プレフィックスは最初の１６ビットが共通で、3FFE::/16のプレフィックス
です。このアドレスの範囲は、2006年6月6日から非推奨で[RFC3701]、新し
いＩＰｖ６ネットワーク展開で使用されてはなりません。６ｂｏｎｅアドレス
空間を使用するサイトは、[RFC4192]で定義される手順で、商用アドレス空間
に番号を付け替えるべきです。
2.4. Network-Level Design Considerations
2.4. ネットワークレベル設計の考察
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:
ＩＰｖ６はかなり大きいアドレス空間をネットワーク管理者に提供し、管理者
が非常に創造的に論理的で実用的なアドレス計画を定義するのを可能にします。
以下の要素等を含む様々な論理的計画に基づいて割当てられたプレフィックス
のサブネットができます。
o Using existing systems
o 既存システムを使用
* translate the existing subnet numbers into IPv6 subnet IDs
* 既存のサブネット番号をＩＰｖ６サブネットＩＤに読替え
* translate the VLAN IDs into IPv6 subnet IDs
* ＶＬＡＮ ＩＤをＩＰｖ６サブネットＩＤに読替え
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.
* サービス種別−事前に定義されたサービスのためにあるプレフィック
スを予約する、例えば：ＩＰ電話、コンテンツ配布、無線サービス、
インターネット接続、セキュリティ領域、など。この種類のアドレス
について、ネットワーク内のこれらのサービスを実行するノードやイ
ンタフェースがまばらに存在するなら、トポロジー内の番号変更をよ
り困難にするＩＰアドレス依存を引き起こすかもしれません。
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 プレフィックス集約−より大きいＩＰｖ６アドレスは、ネットワーク設計
者が積極的に集約を追求していない場合、より大きいルーチングテーブル
を発生させることがあります。プレフィックス集約はサービスプロバイダー
によって励行されるでしょうが、個々の組織がネットワーク設計過程で同
じ原則を遵守するのは有益です。
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 大きいネットワークにおけるＵＬＡ使用法−fc00::/7下のランダム/48を
デフォルトとするＵＬＡプレフィックスを持つ多く'サイト'を持つネット
ワークは、これらのプレフィックスの集約はないでしょう。したがって、
ネットワークには多量の非集約のＵＬＡプレフィックスがあるので、結末
は厄介であるかもしれません。しかしながら、ＵＬＡが内部的にサブネッ
トに使用するための１６ビットを供給するので、すべての'サイト'に唯一
のＵＬＡプレフィックスを使用する大きいネットワークを禁じる規則は全
くありません。
o Compact numbering of small sites - It is possible that as registry
policies evolve, a small site may experience an increase in prefix
length when renumbering, e.g., from /48 to /56. For this reason,
the best practice is to number subnets compactly rather than
sparsely, and to use low-order bits as much as possible when
numbering subnets. In other words, even if a /48 is allocated,
act as though only a /56 is available. Clearly, this advice does
not apply to large sites and enterprises that have an intrinsic
need for a /48 prefix.
o 小さいサイトの密集した番号付け−登録方針の発展で、小さいサイトは番
号変更時に、例えば/48から/56に、プレフィックス長が長くなるかもしれ
ません。この理由で、サブネットはまばらにではなく密集した番号付けを
するのが最も良い習慣で、サブネットに番号付けするときは下位ビットを
できるだけ使用するのが最も良い習慣です。言い換えれば、/48が割り当て
られても、/56だけが利用可能であるかのように行動してください。明らか
に、この助言は/48プレフィックスが本質的に必要な大きいサイトと企業に
は適用されません。
o Consider assigning more than one /64 to a site - A small site may
want to enable routing amongst interfaces connected to a gateway
device. For example, a residential gateway that receives a /48
and is situated in a home with multiple LANs of different media
types (sensor network, wired, Wi-Fi, etc.), or has a need for
traffic segmentation (home, work, kids, etc.), could benefit
greatly from multiple subnets and routing in IPv6. Ideally,
residential networks would be given an address range of a /48 or
/56 [RIPE_Nov07] such that multiple /64 subnets could be used
within the residence.
o サイトに複数の/64を割り当てる−小さいサイトはゲートウェイ装置に接
続されたインタフェースの内でルーティングを可能にしたいです。例えば、
/48を受け取り、家の中で異なるメディア(センサネットワーク、有線、
Ｗｉ−Ｆｉ、など)の複数のＬＡＮに位置するか、(家、仕事、子供などに)
トラフィックの分割が必要な住宅のゲートウェイは、ＩＰｖ６で複数サブ
ネットとルーチングから大きな利益を得ます。理想的には、住居の中で複
数の/64のサブネットを使用できるように住宅のネットワークは/48か/56
のアドレス範囲を割り当てられます[RIPE_Nov07]。
2.4.1. Sizing the Network Allocation
2.4.1. ネットワーク割当の大きさ
We do not discuss here how a network designer sizes their application
for address space. By default, a site will receive a /48 prefix
[RFC3177]; however, different RIR service regions policies may
suggest alternative default assignments or let the ISPs decide on
what they believe is more appropriate for their specific case (see
Section 6.5.4, "Assignments from LIRs/ISPs", of [ARIN]). The default
provider allocation via the RIRs is currently a /32 [RIPE_Nov07].
These allocations are indicators for a first allocation for a
network. Different sizes may be obtained based on the anticipated
address usage [RIPE_Nov07]. At the time of writing, there are
examples of allocations as large as /19 having been made from RIRs to
providers.
私たちはここでネットワーク設計者がどう彼らのアドレス空間のアプリケー
ションを大きさについて議論しません。デフォルトで、サイトは/48プレ
フィックスを受けるでしょう[RFC3177]；しかしながら、別のＲＩＲサービス
領域方針が別のデフォルト割当を示すか、ＩＳＰが特定の事例で、より適切
であると信じていることを決めるかもしれません(ＡＲＩＮの「ＬＩＲ／
ＩＳＰからの割当」の6.5.4章を参照)。現在、ＲＩＲを通したデフォルトの
プロバイダー割当は/32です[RIPE_Nov07]。これらの割当はネットワークの
最初の割当の指針です。予期されたアドレスの使用に基づいて異なる大きさ
を得るかもしれません[RIPE_Nov07]。この文の記述時点で、ＲＩＲからプロ
バイダへ/19ぐらいの大きさの割当の例があります。
2.4.2. Address Space Conservation
2.4.2. アドレス空間管理
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.
ＩＰｖ６アドレス空間は大きく、より簡単にサブネットを可能にしますが、
この資源の効率的な使用を確実にするのは重要です。集約と管理を容易にす
るいくつかのアドレス体系は、大量の未使用のアドレスを発生させるかもし
れません。アドレス管理要件はＩＰｖ６でそれほど厳しくはありませんが、
観測されるべきです。
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.
ＩＰｖ６のために提案されたホスト密度(HD)値[RFC3194]は０．９４で、
ＩＰｖ４の現行値は０．９６です。ＩＰｖ６でＨＤが、ＩＰｖ４のアドレス
の代わりに、サイト(例えば、/56ベースの)で計算されることに注意してく
ださい。
3. Subnet Prefix Considerations
3. サブネットプレフィックスの考察
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.)
ＩＰｖ４アドレス計画の重要な部分はそれぞれのサブネットプレフィックスの
長さの決定です。ＩＰｖ４と異なり、ＩＰｖ６アドレス体系[RFC4291]は、
グローバル一意アドレスやＵＬＡを使用する全てのサブネットが同一のプレ
フィックス長６４ビットを持つと指定します。(これは推奨しない６ｏｎｅと
サイトローカルアドレスにも適用されます。)
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.
この規則の唯一の例外は２進値000から始まるＩＰｖ４互換ＩＰｖ６アドレス
などの特別なアドレスです。これらの例外はこの文書の範囲外です。
Using a subnet prefix length other than a /64 will break many
features of IPv6, including Neighbor Discovery (ND), Secure Neighbor
Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of
Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode
(PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6
Intermediation (SHIM6) [SHIM6], among others. A number of other
features currently in development, or being proposed, also rely on
/64 subnet prefixes.
/64以外のサブネットプレフィックス長を使用すると、近隣探索（ＮＤ）や安
全な近隣探索（ＳＥＮＤ）[RFC3971]や、プライバシ拡張[RFC4941]や、モバイ
ルＩＰｖ６[RFC4866]の一部や、埋め込みＲＰ付きプロトコル非依存マルチキャ
スト−閑散モード(PIM-SM)[RFC3956]や、ＩＰｖ６仲介サイトマルチホーム
(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.
それにもかかわらず、多くのＩＰｖ６実装は管理者による６４ビットより短い
か長いサブネットプレフィックス長の構成を防ぎません。/64より短いサブ
ネットプレフィックスを使用するのはめったに役に立たないでしょう。議論に
関しては付録Ｂ．１を見てください。
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より長いプレフィックスを使用します。
リンクではすべてのアドレスが手動の構成で割当てられ、リンク上のすべて
のノードがネットワークを知っているルータ（終端ホストでない）で、管理
者は/64に依存する全てのＩＰｖ６の機能を必要としないなら、これは動作し
ます。/64より長いサブネットプレフィックスを使用するのは一般的な使用の
ためには推薦されません、そして終端ホストを含むリンクにそれらを使用する
のは、ホストが将来どんなＩＰｖ６の機能を使用するかを予測するのが難しい
ので、特に悪い考えでしょう。
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.
付録Ｂ．２は、限られた場合に/64より長いプレフィックスを使用するとき、
考慮する必要があるいくつかの実用的な問題について説明します。特に、多く
のＩＰｖ６の機能が特別な形式のインタフェース識別子(いくつかのビット位
置がある一定の値であるなど)を使用します。/64より長いプレフィックスを使
用するとき、プレフィックスが/64と仮定するノードがサブネットのアドレス
を特別な形式と誤って認識しないように、あるサブネットプレフィックス値を
避けるのが賢明です。付録Ｂ．２は、現在、潜在的に問題が多いと信じられて
いるサブネットプレフィックス値について説明します。しかしながら、リスト
は完全ではなく、将来増加すると予想できます。
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のサブネットを使用するのが強くお
勧めです。現在のＩＰｖ６仕様に準拠する設置では他のプレフィックス長を
使用できません。しかしながら、Ｖ６ＯＰＳ作業班は、欠点(そして、もし
/64に依存するＩＰｖ６機能が将来必要になった時に、ネットワークの再設
計が高価になる可能性)にもかかわらず、いく人かのネットワーク管理者が
/64より長いプレフィックスを使用すると信じています。
3.1. Considerations for /64 Prefixes
3.1. /64プレフィックスの考察
Based on RFC 3177 [RFC3177], 64 bits is the prescribed subnet prefix
length to allocate to interfaces and nodes.
RFC 3177 [RFC3177]に基づいて、６４ビットはインタフェースとノードに割当
てると規定されたサブネットプレフィックス長です。
When using a /64 subnet length, the address assignment for these
addresses can be made either by manual configuration, by a Dynamic
Host Configuration Protocol [RFC3315], by stateless autoconfiguration
[RFC4862], or by a combination thereof [RFC3736].
/64のサブネット長を使用するとき、これらのアドレスは手動設定や、動的
ホスト設定プロトコル[RFC3315]や、状態なし自動設定[RFC4862]や、これら
の組合せで簡単に生成できます。
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が一般的な用途で強く６４ビットのサブネットを定めて、ほとんど
のリンク層(イーサネットを含む)の状態なし自動設定が６４ビットのサブネッ
トにだけ定義されることに注意してください。将来の自動設定メカニズムが、
６４ビットより長いプレフィックス長の使用を許容するのが理論上可能ですが、
そのようなプレフィックスの使用は推薦されません。
4. Allocation of the IID of an IPv6 Address
4. ＩＰｖ６アドレスのＩＩＤ割当
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.
完全なＩＰｖ６アドレスを持つために、インタフェースはプレフィックスと
インターフェース識別子（ＩＩＤ）を連結しなければなりません。この文書
の３章はプレフィックス選択問題を分析しました。この章はＩＰｖ６アドレ
スのＩＩＤ部分を割り当てるとき考えるべき要素について論じます。
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.
ＩＰｖ６アドレスを装置やインタフェースに割当てる様々な方法があります。
ネットワーク管理者の警戒が最小となる方法はＥＵＩ−６４[RFC4862]に基づ
くアドレスです。手動、または、動的な方法で、周知のＩＰｖ６アドレスとの
重複は避けられるべきです。
4.1. Automatic EUI-64 Format Option
4.1. 自動ＥＵＩ６４形式手法
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.
この方法を使用するとき、ネットワーク管理者は有効な６４ビットのサブネッ
トプレフィックスを割当てなければなりません。いったん割当をすると、
ＥＵＩ−６４[RFC4862]割当手順が残りの６４ビットのＩＩＤビットを状態が
ない方法で割り当てます。有効なＩＩＤを選択するためのすべての問題は
ＥＵＩ−６４方法論に組み込まれています。
4.2. Using Privacy Extensions
4.2. プライバシ拡張の使用
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]に基づいて生成されたＩＩＤの主な目的はＩＰｖ６アド
レスを使用する人にプライバシを提供することです。[RFC4941]で定義される
ようにＩＰｖ６アドレスの使用法に特定の強制はありませんが、RFC 4941
[RFC4941]の４章に記載されるプライバシアドレスをいつ使用するかについて
暗黙の了解があります。
4.3. Manual/Dynamic Assignment Option
4.3. 手動/動的割当手法
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).
この章は、状態なしアドレス設定(４．１章)を通して設定されるのではない、
ＩＩＤ割当について論じます。リンク上で使用されるプレフィックス長にか
かわらずこれらは適用可能です。様々な割当手法(例えば、手動設定、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:
この状況で、実際の割当が人間の介入で実施され、既知のＩＰｖ６アドレス
と重複しない、完全なＩＰｖ６アドレスが与えられるための考慮が必要です:
o Subnet Router Anycast Address (Appendix B.2.5.1)
o サブネットルータエニキャストアドレス(付録B.2.5.1)
o Reserved Subnet Anycast Address (Appendix B.2.5.2)
o 予約サブネットエニキャストアドレス(付録B.2.5.2)
o Addresses used by Embedded-RP (Appendix B.2.6)
o ＲＰ埋め込みで使用されるアドレス(付録B.2.6)
o Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Addresses
(Appendix B.2.7)
o イントラサイトの自動トンネルアドレシングプロトコル(ISATAP)アドレス
(付録B.2.7)
When using an address assigned by human intervention, it is
recommended to choose IPv6 addresses that are not obvious to guess
and/or to avoid any IPv6 addresses that embed IPv4 addresses used in
the current infrastructure. Following these two recommendations will
make it more difficult for malicious third parties to guess targets
for attack, and thus reduce security threats to a certain extent.
人間の介入で割り当てられたアドレスを使用するとき、現在の基盤に使用さ
れるＩＰｖ４アドレスが埋め込まれたＩＰｖ６アドレスの憶測や防御のため、
明白でないＩＰｖ６アドレスを選ぶのはお勧めです。これらの２つの推薦に
従うと、悪意がある第三者が攻撃のための目標を推測するのが難しくなり、
その結果ある程度セキュリティの脅威を抑えられるでしょう。
5. Security Considerations
5. セキュリティの考察
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以外のサブネットプレフィックスを使用すると、暗号的生成アドレス
（ＣＧＡ）やハッシュベースアドレス（ＨＢＡ）などのセキュリティー対策
を壊し、その結果、それらに依存するプロトコルを使用するのが不可能にな
ることに注意してください。
6. Acknowledgements
6. 謝辞
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.
建設的なフィードバックと寄与がＩＥＳＧレビューサイクルの間と、Marla
AzingerとStig VenaasとPekka SavolaとJohn SpenceとPatrick Grossetete
とCarlos GarciaとschiとBrian CarpenterとMark SmithとJanos Mohacsi
とJim BoundとFred TemplinとGinny ListmanとSalman Assadullahと
Krishnan Thirukondaからと、ＩＥＳＧから受けられました。
7. Informative References
7. 有益な参考文献
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet
Anycast Addresses", RFC 2526, March 1999.
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
RFC 3021, December 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6
Address Allocations to Sites", RFC 3177,
September 2001.
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in
233/8", BCP 53, RFC 3180, September 2001.
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for
Address Assignment Efficiency An Update on the H
ratio", RFC 3194, November 2001.
[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.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3531] Blanchet, M., "A Flexible Method for Managing the
Assignment of Bits of an IPv6 Address Block",
RFC 3531, April 2003.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6
Global Unicast Address Format", RFC 3587,
August 2003.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between
Routers Considered Harmful", RFC 3627,
September 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version
6", RFC 3633, December 2003.
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day",
RFC 4192, September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6
Unicast Addresses", RFC 4193, October 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005.
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6)
Developers Should Think About", RFC 4219,
October 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
Configuration Protocol (DHCP): IPv4 and IPv6 Dual-
Stack Issues", RFC 4477, May 2006.
[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.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)",
RFC 5214, March 2008.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008.
[SHIM6] IETF, "Site Multihoming by IPv6 Intermediation
(shim6) Charter", <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>.
[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_Jul07] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and
Assignment Policy", ripe-412, July 2007,
<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>.
[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>.
[AFRINIC_IPv6] AfriNIC, "AfriNIC IPv6 Address Allocation and
Assignment Policy", March 2004,
<http://www.afrinic.net/docs/policies/
afpol-v6200407-000.htm>.
[THINKABOUT] Chown, T., Thompson, M., Ford, A., and S. Venaas,
"Things to think about when Renumbering an IPv6
network", Work in Progress, March 2007.
Appendix A. Case Studies
付録Ａ. 事例研究
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.
この付録はこの文書の声明と問題に基づいたＩＰｖ６アドレス計画の２つの
事例を含んでいます。これらの事例はこの文書が２つの特定のネットワーク
でどう使用されたかを例証します。事例は、事業用やＩＳＰネットワークの
ためにＩＰｖ６アドレス計画を設計する管理者に、基本的な考慮事項を供給
するかもしれませんが、あらゆる種類のＩＰｖ６ネットワークの一般的な設
計案を供給することを意図しません。この付録で使用されるすべてのサブネッ
トサイズは、具体的なイメージのためであり、ＲＩＲ方針を決めません。
A.1. Enterprise Considerations
A.1. 事業用の考察
In this section, one considers a case study of a campus network that
is deploying IPv6 in parallel with existing IPv4 protocols in a dual-
stack environment. The specific example is the University of
Southampton (UK), focusing on a large department within that network.
The deployment currently spans around 1,000 hosts and over 1,500
users.
この章は、デュアルスタック環境で、既存のＩＰｖ４プロトコルと平行して
ＩＰｖ６を配布しているキャンパスネットワークの事例を考えます。特定の
例はサウサンプトン大学(イギリス)で、そのネットワークの中の大きい部に
焦点を合わせます。現在およそ1,000のホストと1,500人以上のユーザへ配
布されています。
A.1.1. Obtaining General IPv6 Network Prefixes
A.1.1. 一般ＩＰｖ６ネットワークプレフィックスの取得
In the case of a campus network, the site will typically take its
connectivity from its National Research and Education Network (NREN).
Southampton connects to JANET, the UK academic network, via its local
regional network LeNSE (Learning Network South East). JANET
currently has a /32 allocation from RIPE NCC. The current
recommended practice is for sites to receive a /48 allocation; on
this basis, Southampton has received such a prefix for its own use.
The regional network also uses its own allocation from the NREN
provider.
キャンパスネットワークの場合、サイトは通常全米研究教育ネットワーク
(NREN)へ接続するでしょう。サウサンプトンは、ローカル地域ネットワーク
ＬｅＮＳＥ(学習網南東)を通して、イギリスの学術ネットワークのＪＡＮＥＴ
に接続します。ＪＡＮＥＴは、現在、RIPE NCCから/32割当があります。
現在の推奨案はサイトは/48の割当を受ける事です；この基準で、サウサン
プトンは自身で使用するためにプレフィックスを受け取りました。また、
地域ネットワークはＮＲＥＮプロバイダーからの割当も使用します。
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.
ＵＬＡアドレスはサイトで使用されていません。キャンパスは「マルチホー
ム」ではなく(ＪＡＮＥＴが唯一のプロバイダーです)サービスプロバイダー
を変える予定はなく、その結果、ネットワークのアドレス変更が簡単になる
(想定)利点のためにＵＬＡを使う予定はありません。実際には、キャンパス
は前記のアドレス変更手順[RFC4192]に従ったアドレス変更を２度行っていて、
([THINKABOUT]で書かれた条件付で)手順が適切であると判明しました。キャ
ンパスは内部または外部のネットワーク管理のためにＵＬＡを配布する必要
性を認めていません；サイトで基盤に割当てるために利用可能なＩＰｖ６プ
レフィックスは十分あります。いくつかの場合、ＩＰｖ４のプライベート
ＩＰアドレス空間の使用は問題を生じるので、サウサンプトン大学は、基盤
のための十分なグローバルＩＰｖ６アドレス空間が利用できるのは多くのサ
イトで利益があるかもしれないと信じています。
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.
６ｂｏｎｅアドレスはもうサイトで使用されていません。２００６年６月の
６ｂｏｎｅ段階的撤去[RFC3701]以降、ほとんどの中継ＩＳＰがこのような
プレフィックスを使う試みにフィルタをかけ始めました。
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).
サウサンプトンはグローバルと組織範囲のＩＰｖ６マルチキャストネットワー
クに参加します。マルチキャストはこの文書の範囲外なので、ここでマルチ
キャストアドレスの配布の議論はしません。ＩＰｖ６はマルチキャストグルー
プアドレス配布で利点があることに注意してください。ＩＰｖ４では、サイ
トは広範囲で一意に使用できるマルチキャストグループを選ぶのにＧＬＯＰ
[RFC3180]のようなテクニックを使用する必要があります。サイトがボーダ・
ゲイトウェイ・プロトコル（ＢＧＰ）[RFC4271]を使用せず、自律システム番
号（ＡＳＮ）を持たないなら、これは問題が多いです。ＩＰｖ６では、ユニ
キャストプレフィックスに基づくＩＰｖ６マルチキャストアドレスにより、
サイト自身のユニキャストサイトプレフィックスかユニキャストリンクプレ
フィックスに基づいて、サイトが広範囲に一意なグループアドレスを選ぶの
事ができます。埋込ＲＰも使用でき、ＩＰｖ６とマルチキャストの潜在的利
点と考えられて、(米国とイギリス間の経路を含む)プロバイダを経由したサ
イト間でテストが成功しました。
A.1.2. Forming an Address (Subnet) Allocation Plan
A.1.2. アドレス(サブネット)割当計画の形成
The campus has a /16 prefix for IPv4 use; in principle, 256 subnets
of 256 addresses. In reality, the subnetting is muddier, because of
concerns of IPv4 address conservation; subnets are sized to the hosts
within them, e.g., a /26 IPv4 prefix is used if a subnet has 35 hosts
in it. While this is efficient, it increases management burden when
physical deployments change, and IPv4 subnets require resizing (up or
down), even when DHCP is in use.
キャンパスには、ＩＰｖ４で使用する/16プレフィックスがあります；原則
として256アドレスの256サブネットです。実際は、サブネットはＩＰｖ４
アドレス保護の問題のため混乱しています；サブネットはその中のホストの
数で分けられます、例えば、サブネットに３５台のホストがあるならば、/26
のＩＰｖ４プレフィックスが使用されています。これは効率的ですが、物理
的な配置が変化し、ＩＰｖ４サブネットの大きさを（大きくか小さくか）変
える必要があるとき、ＤＨＣＰを使用していても管理負担が増加します。
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のＩＰｖ６プレフィックスはサイトに既に割当てられているＩＰｖ４の
割当てよりかなり大きいです。これは2^16(6万5000以上)のサブネットがあ
るので、おおよそ'クラスＡ'のＩＰｖ４プレフィックスと同等ですが、ＩＰ
ｖ４の２５６のサブネットアドレスと比較して、事実上無制限(2^64)のサブ
ネットアドレスがあります。サブネットサイズの増加は、後日サブネットサ
イズを変更するという条件なしに、すべてのサブネットで/64のＩＰｖ６プレ
フィックスが使用できることを意味します。サブネットの大きさの増加は、
キャンパスの学部と学科に気前よくサブネットを割り当てるのを許します。
アドレス管理は重要ですが、もうネットワーク管理の障害ではありません。
むしろ、アドレス(サブネット)割当ては、利用可能なアドレス空間と今後の
拡張計画を含みます。
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.
デュアルスタックネットワークでは、ＩＰサブネットにＩＰｖ４とＩＰｖ６
が一致するように割当ました。これはシステムが同じ管理ドメインと同じ場
所にあるからです。しばらくは、テストベッドやいくつかの初期のモバイル
ＩＰｖ６トライアル以外に、商用の使用でＩＰｖ６だけのサブネットがない
と予想されます。一致しているアドレスにより、サイト境界のファイアウォー
ルのポリシはＩＰｖ４とＩＰｖ６トラフィックで連携します。
The subnet allocation plan required a division of the address space
per school or department. Here, a /56 was allocated to the school
level of the university; there are around 30 schools currently. A
/56 of IPv6 address space equates to 256 /64 subnet allocations.
Further /56 allocations were made for central IT infrastructure, the
network infrastructure, and the server side systems.
サブネット割当て計画はアドレス空間を学部と学科に分割するのを要求しま
した。ここでは、大学の学部レベルに/56を割り当てました；現在、およそ
３０の学部があります。ＩＰｖ６アドレス空間の/56は256の/64サブネット
割当てに一致しています。主要なＩＴ基盤とネットワーク基盤とサーバ側シ
ステムのためにも/56を割当てました。
A.1.3. Other Considerations
A.1.3. その他の考慮
The network uses a Demilitarized Zone (DMZ) topology for some level
of protection of 'public' systems. Again, this topology is congruent
with the IPv4 network.
ネットワークは「公共」システムの保護に何らかのレベルの非武装地帯
(DMZ)トポロジーを使用します。このトポロジーもＩＰｖ４ネットワークと
一致します。
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.
モバイルＩＰｖ６の初期トライアルのために、ホームエージェント（ＨＡ）
で使用するために割当てられた１つのプレフィックスがあります。しかしな
がら、モバイルＩＰｖ６の使用がどれほど多くなるか、どれだけ多くのサブ
ネット(または、全てのサブネット)がＨＡサポートを必要とするかについて、
詳細な考察はありませんでした。
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]サービスを運営しま
すこれは大学サイトからの割当てでではなく、ＪＡＮＥＴからの別のアドレ
ス空間を使用します。
A.1.4. Node Configuration Considerations
A.1.4. ノード構成の考察
Currently, stateless autoconfiguration is used on most subnets for
IPv6 hosts. There is no DHCPv6 service deployed yet, beyond tests of
early code releases. It is planned to deploy DHCPv6 for address
assignment when robust client and server code is available (at the
time of writing, the potential for this looks good, e.g., via the
Internet Systems Consortium (ISC) implementation). University of
Southampton is also investigating a common integrated DHCP/DNS
management platform, even if the servers themselves are not co-
located, including integrated DHCPv4 and DHCPv6 server configuration,
as discussed in [RFC4477]. Currently, clients with statelessly
autoconfigured addresses are added to the DNS manually, though
dynamic DNS is an option. The network administrators would prefer
the use of DHCP because they believe it gives them more management
control.
現在、ＩＰｖ６ホストの状態なしの自動構成はほとんどのサブネットで使用
されます。早期コードリリースのテストを終えて配布されたＤＨＣＰｖ６サー
ビスは全くありません。強靭なクライアントとサーバコードが利用可能であ
れば、アドレス割当てにＤＨＣＰｖ６を配置する計画があります(これを書い
ている時点でこの可能性はありそうです、例えば、インターネットシステムズ
コンソーシアム(ISC)の実装です)。また、サウサンプトン大学は一般的なサー
バ自体を設置していなくても、[RFC4477]で議論する統合ＤＨＣＰｖ４とＤＨ
ＣＰｖ６サーバ構成を含め、統合DHCP/DNS管理プラットフォームを調査して
います。現在、動的ＤＮＳは任意ですが、状態なしアドレス自動設定のクライ
アントは、アドレスを手動でＤＮＳに加えています。ネットワーク管理者は、
ＤＨＣＰにより、より多くの管理制御を得られると信じているので、ＤＨＣＰ
の使用を好むでしょう。
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]にも係らず、すべてのホストがデュアルスタックで、その結
果、潜在的に両方のプロトコル上でさらされていることに注意してください。
すべてのアドレスがＤＮＳで公開されます、そしてサイトは裏表のあるＤＮ
Ｓ運用をしません。
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]の内部的な使い方があります
（あるプラットホームではデフォルトでオンの状態です）が、ネットワーク
管理者は管理の複雑さを緩和するために、(おそらくＤＨＣＰにより)プライ
バシアドレスを無効にすることを望むかもしれません。しかしながら、すべ
てのシステム、例えば無線ＬＡＮやユーザ管理システムで、プライバシアド
レスを無効にするのが希望されます。ネット管理とモニタは、どの物理ホス
トがどのアドレスを使用しているかを特定することに関して、RFC 4941なし
で運用するより簡単であるべきです、。RFC 4941が外向き接続での問題であ
り、ＤＨＣＰｖ６を通してプライバシーアドレスを割り当てる可能性がある
ことに注意してください。
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.).
手動で構成されたサーバアドレスは、ネットワークアダプタの変更によるア
ドレス変更を避けるのに使用されます。ＩＰｖ６で、ＤＮＳサーバに::53を、
不明瞭な装置にランダムアドレスを選択でき、これはアドレスを公開(ＤＮＳ，
メール、ウェブ等)した際に問題にはなりません。
A.2. Service Provider Considerations
A.2. サービスプロバイダ問題
In this section an IPv6 addressing schema is sketched that could
serve as an example for an Internet Service Provider.
この章で、インターネットサービスプロバイダのための例として、ＩＰｖ６
アドレス計画の概略を記載します。
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は、このようなアドレス計画の客観的な要件に関するいくつかの
考えから始まり、ＩＳＰのＩＰｖ６アドレス計画を設計するとき覚えておか
れなければならないいくつかの一般的な経験則を引き出します。
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は、ＭＰＬＳに基づくインターネットサービスと数百万の顧客へ
のネットワークアクセス・サービスを提供するＩＳＰの模範的ＩＰｖ６アド
レス計画のAppendix A.2.1の調査結果を記載します。
A.2.1. Investigation of Objective Requirements for an IPv6 Addressing
Schema of a Service Provider
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.
サービスプロバイダのＩＰｖ６アドレス計画設計の第一歩は、アドレス計画
で実施するサービスで満たされなければならないすべての技術的、運用的、
政治上、ビジネス的要件を特定する事です。
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のアドレス計画
は可能な１例です。
For this document, it is assumed that our exemplary ISP has to
fulfill several roles for its customers such as:
この文書で、私たちの模範的ＩＳＰは顧客のために以下のいくつかの役割等
を実現させなければならないと思われます。
o Local Internet Registry
o ローカルのインターネット登記所
o Network Access Provider
o ネットワークアクセスプロバイダ
o Internet Service Provider
o インターネットサービスプロバイダ
A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR
Perspective of the Service Provider
A.2.1.1. ＬＩＲからのＩＰｖ６アドレス計画の推薦
サービスプロバイダーの見解
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)の役割で、サービスプロバイダはＩＰｖ６
アドレスに関するＲＩＲポリシとＩＥＴＦ規格を考えなければなりません。
この状況で、以下の基本的な推薦を考えるべきで、サービスプロバイダの
ＩＰｖ６アドレス割当計画で満たされるべきです:
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]といくつかのＲＩＲポリシで推薦されるように、
「一般的」な顧客サイト(通常個人的な顧客)は、サービスプロバイダの
アドレス集合から/48プレフィックスを受け取るべきです。
(注意: アドレス計画は十分柔軟であるべきで、エンドユーザのための
ＲＩＲでの現在の定義での最小の割当サイズの変更の可能性を考慮に
入れなければなりません。)
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 「大顧客」(大企業や政府機関など)は、要求をＲＩＲを記録し正当化で
きるとき、彼らの要求に応じてより短いプレフィックスを受け取るかも
しれません、。
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 ＩＰｖ６アドレス割当計画はＩＰｖ６のために提案されたＨＤ率に従う
ことができなければなりません。この要件はサービスプロバイダの
ＩＰｖ６アドレス集約の効率的な使用の要求に対応します。(注意:現在の
有効なＩＰｖ６ＨＤ率の0.94は、/22プレフィックスのサービスプロバイ
ダで、/56割当に基づき、約２２％の使用率を意味します)
o All assignments to customers have to be documented and stored into
a database that can also be queried by the RIR.
o 顧客へのすべての割当は、ＲＩＲから調査できるデータベースに記録・
保存されなければなりません。
o The LIR has to make available the means for supporting the reverse
DNS mapping of the customer prefixes.
o ＬＩＲは顧客プレフィックスの逆ＤＮＳ検索をする手段を利用可能にしな
ければなりません。
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 ＩＰｖ６アドレス割当と指定ポリシは各ＲＩＲにあり、多くの面で同じで
す。[RIPE_Nov07]と[RIPE_Jul07]と[APNIC_IPv6]と[LACNIC_IPv6]と
[AFRINIC_IPv6]と[ARIN]の６章を参照してください。
A.2.1.2. IPv6 Addressing Schema Recommendations from the ISP
Perspective of the Service Provider
A.2.1.2. ＩＳＰからのＩＰｖ６アドレス計画の推薦
サービスプロバイダーの見解
From the ISP perspective, the following basic requirements can be
identified:
ＩＳＰの見解から、以下の基本的な要件を特定できます:
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 ＩＰｖ６アドレス割当て計画は、顧客へのすべてのＩＰｖ６アドレス割当
を、サービスプロバイダのアドレスへ、最大限集約できなければなりませ
ん。広域ルーチングテーブル（ＤＦＺ 「デフォルトなしのゾーン」）には、
このプロバイダ集約だけが広告・注入されるでしょう。この強い集約は
ＤＦＺのルーティングテーブルを小さくしておいて、そしてフィルタリン
グとアクセス制御を大変容易にします。
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 サービスプロバイダの基盤が新しい顧客と通信技術とビジネスによって、
長期的に変化するでしょうから、サービスプロバイダのＩＰｖ６アドレス
計画は最適な柔軟性を含んでいるべきです。最適な柔軟性の必要条件は、
強いＩＰｖ６アドレス集約と効率的なアドレス使用の推薦とは矛盾します
が、しかしそれぞれのサービスプロバイダはこれらの必要条件のどちらに
優先順位を付けるべきか決めなければなりません。
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 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 ＩＳＰの多レベルネットワーク階層を念頭におく間に、アドレス効率化の
o プロバイダネットワークのアドレスと顧客アドレスの分離が勧められます。
（注：強い集約（例えば、ＰＯＰや、集約ルータ（ＡＧ）や、ラベルエッ
ジルータ（LER））がＩＳＰネットワークで見える顧客経路の数を制限し
ますが、同じくＩＰｖ６アドレス計画の効率を落とします。これはそれぞ
れのＩＳＰがいくつの内部の集約レベルを作ることを望むか決めなければ
ならない理由です。）
A.2.1.3. IPv6 Addressing Schema Recommendations from the Network Access
Provider Perspective of the Service Provider
A.2.1.3. サービスプロバイダのネットワークアクセスプロバイダの見地からの
ＩＰｖ６アドレスの推薦
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:
すでにサービスプロバイダのＬＩＲとＩＳＰの役割のためにしたように、
ネットワークアクセスプロバイダの役割から来る必要条件を識別することも
必要です。基本的な必要条件のいくつかは以下です：
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 ＳＰのＩＰｖ６アドレス計画は、顧客側からの新しい必要条件を扱える
方法で選択されなくてはなりません。例えば、これは顧客のＩＰｖ６ア
ドレスの必要数の増加や、顧客によるアクセスネットワークトポロジー
の変更です（例えば、顧客がネットワーク接続点（ＰＯＰ）をある場所
か他へ変更した時）。（付録 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 それぞれの顧客へのＩＰｖ６アドレス割当てで、追加のプレフィックス
割当てやリナンバリングなしで、顧客のアドレス範囲の増加を可能とす
る「緩衝地帯」が予約されるべきです。
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のＩＰｖ６アドレス計画は、１人の顧客がＳＰの複数の接続点で接続
する事を扱えなければなりません（すなわち、同じＳＰでのマルチホー
ムネットワークアクセス）。
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.
これらの少数の必要条件は、サービスプロバイダがそのアドレス体系を定義
する段階で、調査し年頭に置かなければならない要求条件の一部に過ぎませ
ん。それぞれのＳＰがこのリストに条件を加える可能性が高いでしょう。
A.2.1.4. A Few Rules of Thumb for Designing an ISP IPv6 Addressing
Architecture
A.2.1.4. ＩＳＰのＩＰｖ６アドレス体系のを設計の少数の原則
As a result of the above enumeration of requirements regarding an ISP
IPv6 addressing plan, the following design "rules of thumb" have been
derived:
上に列挙したＩＳＰのＩＰｖ６アドレス計画の必要条件の結果として、次の
設計「原則」が得られました：
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 「すべてに適切なサイズ」はなしです。それぞれのＩＳＰが具体的なビジ
ネスニーズによって、それぞれのＩＰｖ６アドレス割当て計画を開発しな
くてはなりません。あらゆる種類のＩＳＰ（小/大、ルーチング可能/ＭＰ
ＬＳベース、アクセス／中継、ＬＩＲ／非ＬＩＲなど）で適切なアドレス
計画を設計することは現実的ではありません。
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 ＩＳＰアドレス計画のＩＰｖ６アドレス集約のレベルは、実際のネットワー
ク構造に強く依存し、そしてその数は効率理由で最小にされるべきです。
ＳＰの自身の基礎構造がかなり平坦に扱われると思われるのに対して、顧
客のアドレス体系の一部がいくつかのレベルの集約を含んでいると想定さ
れます。
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 ネットワーク内のＩＰｖ６顧客経路の数を可能な限り少なくしておいてく
ださい。 中間の集約なしの一律な顧客のＩＰｖ６アドレス体系は、ＳＰ
ネットワーク内にたくさんの顧客経路をもたらす。アドレス集約レベル
（とそれによるＳＰの内部経路表の大きさ）とアドレス体系のアドレス
の節約の間の公正トレードオフが見いだされなければなりません。
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 ＩＳＰのＩＰｖ６アドレス計画は最大の柔軟性を提供するべきです。
未来の成長率（例えば、顧客総数）と可能なトポロジ的あるいは基盤の
変化を許すために、異なる大きさの顧客のＩＰｖ６アドレス集約（「大」
顧客対「小」顧客）のサポートを実現しなければなりません。
o A limited number of aggregation levels and sizes of customer
aggregates will ease the management of the addressing schema.
This has to be weighed against the previous "rule of thumb" --
flexibility.
o 顧客総計の集約レベルと大きさを制限するのは、アドレス計画の管理を容
易にするでしょう。これは前の柔軟性の「原則」と天秤にかけなければな
りません。
A.2.2. Exemplary IPv6 Address Allocation Plan for a Service Provider
A.2.2. サービスプロバイダの模範的なＩＰｖ６アドレス割り当て計画
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.
この例で、サービスプロバイダは、ＭＰＬＳによるバックボーンを運用し、
完全２重スタックネットワークアクセスとエリア集約による異なる位置（Ｐ
ＯＰ）間で、ＩＰｖ６バックボーン転送のためＩＰｖ６プロバイダエッジルー
タ（６ＥＲ）[RFC4798]を実装すると仮定します。
In addition, it is assumed that the service provider:
加えて、サービスプロバイダは以下と仮定します：
o has received a /20 from its RIR
o ＲＩＲから /20 を受け取りました
o operates its own LIR
o 自身でＬＩＲを運用します
o has to address its own IPv6 infrastructure
o 自身のＩＰｖ６基礎構造を扱わなければなりません
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.
このアドレス計画は、ＳＰの/20ＩＰｖ６プレフックスを、上記の要求条件と
可能な限り原則に従って、どのようにＳＰ自身の基盤で使用し、顧客にＩＰｖ
６アドレスを割当てるかを例示します。
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.
下の図はＳＰネットワークの装置種別とＭＰＬＳベースのサービスプロバイダ
の典型的なネットワーク設計を要約します。ＳＰネットワークの階層はＩＰｖ
６アドレス計画の設計で考慮しなければなりません；これはアドレス計画の基
本的な形と集約の種々なレベルを定義します。
+------------------------------------------------------------------+
| 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
集約ルータ
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.
以下は、模範的なサービスプロバイダがＩＰｖ６アドレス計画の顧客プレフィッ
クスに関する基本的な設計決定をするとき、考慮に入れられるべきです。
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 同じＬＥＲ（あるいはＬＥＲ−ＢＢ）配下のすべての顧客に割当てられた
プレフィックスは、１つのＬＥＲプレフィックス下に集約可能です。これ
は６ＰＥが使われなければならないラベルの数を制限し、それ故にＭＰＬ
Ｓラベルの強い節約を提供することを保証します。
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 ＳＰの／２０プレフィックスはＳＰの顧客にＩＰｖ６プレフィックスを割
り当てるために使われる３つの異なるプールに分けられます：
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. 本当に／４８より大きいＩＰｖ６プレフィックス（例えば／３２）を
必要とする、（付録A.2.2.1.1で定義されるような）「大」顧客の需
要を満たすためのプール（例えば、／２４）。これらの顧客はアクセ
スネットワークのいくつかのＰＯＰに接続していると考えられます、
それでこの顧客プレフィックスはこれらのＰＯＰのそれぞれで見える
でしょう。
2. A pool (e.g., /24) for the LERs with direct customer
connections (e.g., dedicated line access) and without an
additional aggregation area between the customer and the LER.
(These LERs are mostly connected to a limited number of
customers because of the limited number of interfaces/ports.)
2. 直接顧客と接続し（例えば、専用線）、顧客とＬＥＲ間の集約エリア
ないＬＥＲのためのプール（例えば/24）。（これらのＬＥＲは、イン
ターフェース／ポートが限定されるので、顧客の数が限定的です。）
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. 何らかの種類の集約ネットワーク（例えば、ＢＢ−ＲＡＲのＤＳＬ顧
客やＲＡＲのダイヤルイン顧客）で接続する大多数の顧客にサービス
するＬＥＲ（又はＬＥＲ−ＢＢ）のための大きいプール。
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 それぞれのプール（顧客割当あるいはＬＥＲ自身に専用の割当）でのＩＰ
ｖ６アドレス割当は、将来の成長のために１００−３００％の緩衝領域を
取るべきです。すなわち、各顧客の将来の清張予想や各ネットワーク装置
の総数に応じて、プレフィックスの１あるいは２ビットを予約するべきで
す。
A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the
Service Provider
A.2.2.1. サービスプロバイダの顧客のＩＰｖ６アドレス割当計画の定義
A.2.2.1.1. "Big" Customers
A.2.2.1.1. 「大」顧客
The SP's "big" customers receive their prefix from the /24 IPv6
address aggregate that has been reserved for their "big" customers.
A customer is considered a "big" customer if it has a very complex
network infrastructure and/or huge IPv6 address needs (e.g., because
of very large customer numbers) and/or several uplinks to different
POPs of the SP network.
ＳＰの「大」顧客は、「大」顧客のために確保された／２４のＩＰｖ６アド
レスからプレフィックスを受け取ります。もし非常に複雑なネットワーク基
盤や、莫大なＩＰｖ６アドレスの必要性（例えば、非常に大きい顧客数のた
め）や、ＳＰネットワークの異なるＰＯＰへのいくつかのアップリンクを持
つなら、顧客が「大」顧客と思われます。
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.
割り当てられたＩＰｖ６アドレスプレフィックスは範囲は３２〜４８のプレ
フィックス長を持つことができます、そしてそれぞれの割当で１００％ある
いは３００％の将来の成長ゾーンがこの顧客のための「予約」というマーク
されます。例えば、これは顧客への／３４の割当と共に、（この／３４を含
む）／３２プレフィックスが顧客の未来の使用のために確保されることを意
味します。
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]に類似たメカニズムを使うことで、「大顧客」プールから
「大」顧客のプレフィックスが選択できます。
A.2.2.1.2. "Common" Customers
A.2.2.1.2. 「普通」顧客
All customers that are not "big" customers are considered as "common"
customers. They represent the majority of customers, hence they
receive a /48 out of the IPv6 customer address pool of the LER where
they are directly connected or aggregated.
「大」顧客でないすべての顧客は「普通」顧客と考えられます。これは大多
数の顧客に相当します、そして彼らが直接接続するされるか集められるＬＥ
ＲのＩＰｖ６顧客アドレスプールから／４８を受け取ります。
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.
やはり、１００-３００％の将来のＩＰｖ６アドレスの成長範囲がそれぞれの
顧客のために確保され、「普通」顧客が／４８の割当を受けますが／４７ある
いは／４６が予約されます。
(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.)
（注：もし、「普通」顧客が将来／４７や／４６を必要とする可能性が非常に
小さいことが明白であるなら、成長用の緩衝領域が確保されるべきではありま
せん、そして／４８だけが拡張領域なしで割り当てられるでしょう。）
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.
顧客が直接ＬＥＲに接続するネットワークアクセスの場合、顧客プレフィック
スは直接接続するＬＥＲの顧客ＩＰｖ６アドレス集約（例えば、／３８）から
取り出されます。
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.
他の場合（例えば、顧客はＡＧやＬＥＲ−ＢＢに集約されるＲＡＲに接続する
場合）、少なくとも２つの異なる方法が可能です。
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) 集約ネットワーク階層と顧客のＩＰｖ６アドレス計画の対応。ＬＥＲ
レベルと中間レベルで最大の集約を達成するために、集約ネットワー
ク階層は各階層の顧客プレフィックスプールに対応付けができます。
（例：顧客−/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（あるいは集約ネットワークのほかの装置、AGかRAR）のＩＰｖ６
顧客アドレスプールが使い尽くされた時、LER（かAGかRAR）のプレ
フィックスは１ビットか２ビット短くされ（つまり/38か/37か/36に）、
それで元々予約していた成長帯は顧客に追加のＩＰｖ６アドレス割当に
使うことができます。この成長帯が使い尽くされている場合、次の上
位階層のプールからの新しいプレフィックス範囲を求めることができ
ます。
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) 「平」顧客ＩＰｖ６アドレス計画。他の選択肢は、顧客が接続し集約をし
ているLERの顧客ＩＰｖ６アドレスプールから直接すべての顧客プレ
フィックスを割り当て、中間の集約ネットワーク基盤を無視することです。
もちろん、この方法はLERと集約ネットワークレベルでの大量の顧客経路
を導きますが、アドレス計画の複雑さを取り除きます。にもかかわらず、
上で必要とされるように、LER階層での１つのプレフィックスへの顧客プ
レフィックスの集約は実現されます。
Note: The handling of changes (e.g., technically triggered changes)
within the ISP access network is discussed briefly in
Appendix A.2.3.5.
注意：ＩＳＰアクセスネットワークの変更（例えば、技術的理由での変更）の
処理は付録A.2.3.5で短かく論じられます。
If the actual observed growing rates show that the reserved growing
zones are not needed, then they can be freed and used for assignments
for prefix pools to other devices at the same level of the network
hierarchy.
もし実際に観察された成長率が成長帯の予約を必要としないことを示すならば、
予約は解除され、ネットワーク階層の同階層の他の装置のプレフィックスプー
ルの割当に使うことができます。
A.2.2.2. Defining an IPv6 Address Allocation Plan for the Service
Provider Network Infrastructure
A.2.2.2. サービスプロバイダネットワーク基盤のＩＰｖ６アドレス割当て
計画の定義
For the IPv6 addressing of the SP's own network infrastructure, a /32
(or /40) from the "big" customers address pool can be chosen.
ＳＰの自身のネットワーク基盤のＩＰｖ６アドレスに対し、「大」顧客アドレ
スプールから/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.)
/48をすべてのＰＯＰや場所に割当てて、（例えば）/56をこのＰＯＰのルータ
をコード化するために使うことで、このＳＰ基礎プレフィックスはＳＰのネッ
トワーク基礎をコード化するために使われます。ルータインタフェースの背後
にあるＳＰの内部のリンクは/64プレフィックスを使ってコード化できます。
（注意：ＳＰネットワークのＰＯＰや場所のアドレスに/48を選択する事を示唆
しますが、ＰＯＰ内のルータとリンクにどのプレフィックス長を割当てると決め
ることはそれぞれのＳＰに任せられます。）
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.
ルータインタフェースのＩＩＤは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.
ここでも、１００〜３００％の成長帯がネットワーク階層のそれぞれのレベル
で必要で、必要なら追加のプレフィックス部分がＰＯＰやルータに割当てられ
るかもしれないと想定されます。
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.)
（注意：ＳＰの自身のＩＰｖ６ネットワーク基盤を扱うために選ばれたルー
タの/32(又は/40)プレフィックスは、セキュリティレベルや私的使用や試験
基盤の様な追加の機能をコード化するのに十分な空きがありますが、このよ
うな方法が今まで上記のＳＰで詳細に検討されませんでした。）
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.
顧客への１対１リンク（例えば、ＰＰＰリンクや、専用線など）で、アクセ
スルータのこのために予約された最初の/64プレフィックスの中の/126プレ
フィックスが使われるかもしれません。
A.2.3. Additional Remarks
A.2.3. 追加の発言
A.2.3.1. ULA
A.2.3.1. ULA
There are no compelling reasons for service providers to use ULAs.
See Section 2.2.
サービスプロバイダがＵＬＡを使う強制的な理由がありません。
セクション２.２を見てください。
ULAs 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.
ＵＬＡは、例えばネットワーク管理のため、ＳＰ自身の基盤の追加の「サイ
ト範囲」ＩＰｖ６アドレスを得るためや、ＳＰのネットワーク外から到達し
ない追加の計画として、ＳＰネットワーク内で使うことができます。
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.
ＵＬＡが使われるとき、/48のＰＯＰプレフィックスを/48のＵＬＡ際とプレ
フィックスに置換える事で、ＳＰ自身のネットワーク基盤に提案された内部
ＩＰｖ６アドレス（付録 A.2.2.2で記述されるように）を、ＵＬＡアドレス
計画に直接変換できます。
A.2.3.2. Multicast
A.2.3.2. マルチキャスト
IPv6 multicast-related addressing issues are out of the scope of this
document.
ＩＰｖ６マルチキャスト関連アドレス問題は、この文書の範囲外です。
A.2.3.3. POP Multihoming
A.2.3.3. ＰＯＰマルチホーム
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.
顧客の同じＳＰでのマルチホーム（あるいはより良い、ＬＥＲマルチホーム）
は、複数のＬＥＲ依存プレフィックスをこの顧客に割り当てることで（つま
り、それぞれの場所に１つの顧客がいると考える）、あるいは顧客プレフィッ
クスを「大」顧客プールから割り当てることで、ＳＰのＩＰｖ６アドレス計画
で実現できます。２番目の解決策は顧客の接続する全てのＬＥＲで、このプレ
フィックスがＩＧＰルーチングテーブルに現れる、つまり明示的なＭＰＬＳラ
ベルを必要とする欠点があります。
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.
注意：ＳＰアクセスネットワークのアドレス体系でのＰＯＰ／ＬＥＲマルチホー
ムの（上記の）否定的な効果は、ＩＰｖ６仲介者によるサイトマルチホーム
（SHIM6）で解決されません。SHIM6は末端システムで多数のプレフィックスを
取り扱うことだけのメカニズムです。ＳＰはその内部のルーティングテーブル
で顧客プレフィックスを分解することが期待されます。
A.2.3.4. Changing the Point of Network Attachment
A.2.3.4. ネットワーク接続点の変更
In the possible case that a customer has to change its point of
network attachment to another POP/LER within the ISP access network,
two different approaches can be applied, assuming that the customer
uses PA addresses out of the SP aggregate:
顧客がＩＳＰアクセスネットワーク内で、ネットワーク接続点を他のＰＯＰや
ＬＥＲに変える場合、顧客がＳＰアドレスからＰＡアドレスを使うと想定して、
２つの異なる方法が適用できます：
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の番号帯からの適
切な顧客プレフィックスで、顧客のネットワークに番号を付け直さなけれ
ばなりません。顧客の管理上の負担を最小にするために、プレフィックス
は前者と同じ大きさであるべきです。これはＳＰネットワークのＩＰｖ６
アドレス帯（そしてＭＰＬＳラベル空間）を節約しますが、顧客に負担が
あります。それ故にこの方法は、一時的なアドレスを必要とする「小顧客」
か、アドレス自動設定でのプレフィックス割当の場合にだけ選択される可
能性が高いでしょう。
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ルーティングテーブルの中のより多くに特定された
経路項目の追加となり、追加のＭＰＬＳラベルを消費すしますが、顧客に
は完全に透過です。これが管理負荷を増やし、ＩＳＰのルータ資源（ラベ
ル空間やメモリ）を圧迫するため、この解決策はＩＳＰの最も貴重な顧客
（例えば、「大顧客」あるいは「企業顧客」）に提供されるだけであるで
しょう。
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).
それにもかかわらず、ＩＳＰは顧客の番号変更とアドレス集約の低下
（すなわち、ＩＧＰの特定された経路項目の追加と、ＭＰＬＳラベル
空間の浪費）の間に公正な釣り合いを見つけなければなりません。
A.2.3.5. Restructuring of SP (Access) Network and Renumbering
A.2.3.5. ＳＰ（アクセス）ネットワークと番号変更の再構築
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.
技術的に引き起こされたＳＰ（アクセス）ネットワークの再構築（例えば、
装置の分割や新しい装置の導入）のため、顧客ネットワーク番号変更をする
べきではありません。この挑戦は思慮があるネットワーク設計とＩＰｖ６ア
ドレス計画によって前もって処理されるべきです。
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.)
最悪の場合、顧客ネットワークの番号変更はより特定された顧客ルート導入
により避けることができます。（注意：この種類のネットワーク再構築がＬ
ＥＲ下のアクセスネットワーク（レベル）で主に起きるでしょうから、ＬＥ
Ｒ集約レベルは損なわれないでしょう、そしてより特定された経路は追加の
ＭＰＬＳラベル空間を消費しないでしょう。）
A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases
A.2.3.6. 後のＩＰｖ６移行段階のために必要な拡張
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.
ＳＰのＩＰｖ６アドレス計画は、例えば、全てのＭＰＬＳバックボーン基盤
（ＬＤＰやＩＧＰなど）がＩＰｖ６上で実現されるときや、ＬＳＲのＩＰｖ
６アドレスが必要な場合など、後のＩＰｖ６移行段階での拡張や変更の軽視
を必要とします。他の変更も必要かもしれませんが、しかしこの時点で説明
されるべきではありません。
Appendix B. Considerations for Subnet Prefixes Different than /64
付録Ｂ． /64と異なるサブネットプレフィックスに対する考慮
B.1. Considerations for Subnet Prefixes Shorter than /64
B.1. /64より短いサブネットプレフィックスに対する考慮
An allocation of a prefix shorter then 64 bits to a node or interface
is considered bad practice. One exception to this statement is when
using 6to4 technology where a /16 prefix is utilized for the pseudo-
interface [RFC3056]. The shortest subnet prefix that could
theoretically be assigned to an interface or node is limited by the
size of the network prefix allocated to the organization.
ノードあるいはインタフェースに６４ビットより短いプレフィックスを割り当
てるのは良くない試みと思われます。この主張の１つの例外は、擬似インタ
フェースのために/16プレフィックス１つが利用される6to4技術を使うときで
す[RFC3056]。理論的に、インタフェースやノードに割当ることができる最短サ
ブネットプレフィックスは組織に割当てられたネットワークプレフィックスの
大きさによって制限されます。
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は、'g'ビットと
'u'ビット（ユニバーサル/ローカル）の、２つの機能的ビットを含みます、そし
てこれらは任意の選択はきません。しかし、２^６２がたくさんのノードアドレ
スを提供することを考えると、/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]によって作られ
るか、プレフィックスルータ広告（ＲＡ）による状態無し自動設定で暗示で
きます。
B.2. Considerations for Subnet Prefixes Longer than /64
B.2. /64より長いサブネットプレフィックスに対する考察
The following subsections describe subnet prefix values that should
be avoided in deployments because nodes who assume that the subnet
prefix is /64 could treat them incorrectly.
次の章は、サブネットプレフィックスが/64と想定するノードが誤りを犯す
可能性があるので、実装で避けられるべきサブネットプレフィックス値を記
述します。
B.2.1. /126 Addresses
B.2.1. /126アドレス
126-bit subnet prefixes are typically used for point-to-point links
similar to a the IPv4 address-conservative /30 allocation for point-
to-point links. The usage of this subnet address length does not
lead to any considerations beyond those discussed earlier in this
section, particularly those related to the 'u' and 'g' bits (see
B.2.4.
ＩＰｖ４で１対１リンクに/30を割当てるアドレスの習慣に類似して、126ビッ
トプレフィックスが一般に１対１リンクで使われます。このサブネットアドレ
ス長の使用は、特に'u'と'g'ビットに関連したものは、この章の最初で議論し
た以外の利点はありません（B.2.4参照)。
B.2.2. /127 Addresses
B.2.2. /127のアドレス
The usage of the /127 addresses, the equivalent of IPv4's RFC 3021
[RFC3021], is not valid and should be strongly discouraged as
documented in RFC 3627 [RFC3627].
ＩＰｖ４のＲＦＣ３０２１[RFC3021]相当の、/127アドレスの使用は、有効で
はなく、ＲＦＣで３６２７[RFC3627]で文書化したように、強く避けるべきで
す。
B.2.3. /128 Addresses
B.2.3. /128アドレス
The 128-bit address prefix may be used in those situations where we
know that one, and only one, address is sufficient. Example usage
would be the off-link loopback address of a network device.
１２８ビットのアドレスプレフィックスは、アドレスがたった１つのみ必要と
知っている状況で使われるかもしれません。使用例として、ネットワーク装置
のリンク外のループバックアドレスがあります。
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:
１２８ビットのプレフィックスを選択するとき、'u'と'g'ビットを考慮し、次
のよく知られているアドレスのいずれとも重複しないことを確認することが推
奨されます：
o Subnet Router Anycast Address
o サブネットルータエニキャストアドレス
o Reserved Subnet Anycast Address
o 予約されているサブネットエニキャストアドレス
o Addresses used by Embedded-RP
o 埋込みＲＰで使われるアドレス
o ISATAP Addresses
o ISATAPアドレス
B.2.4. EUI-64 'u' and 'g' Bits
B.2.4. ＥＵＩ−６４の'u'と'g'ビット
When using subnet prefix lengths other than /64, the interface
identifier cannot be in Modified EUI-64 format as required by
[RFC4291]. However, nodes not aware that a prefix length other than
/64 is used might still think it's an EUI-64; therefore, it's prudent
to take into account the following points when setting the bits.
/64以外のサブネットプレフィックス長を使うとき、インタフェース識別子は
[RFC4291]で要求された修正ＥＵＩ−６４フォーマットのはずがありません。
しかしながら、/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.
６４ビットより長いサブネットプレフィックス長を使う主な理由は、アドレス
空間の節約です；しかしながら、ＩＰｖ６アドレス計画を作成して保守すると
き、この種類のアドレス節約はその結果しなくてはならない追加の問題と比較
してほとんど利益のがありません。
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.
７０ビット以上のサブネットプレフィックスを割り当てるとき、ＲＦＣ
４２９１[RFC4291]によれば、'u'と'g'ビット（それぞれ第７１番目と第７２
番目のビット）を考慮する必要があり、正確に設定されるべきです。
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.
ＩＰｖ６アドレスの第７１番目のビットは反転した'u'（ユニバーサル/ローカ
ル）ビットであり、アドレスが広く管理されたものか、地域的に管理されたも
のか、決定するために使われます。もし１なら、ＩＥＥＥが、一意会社識別子
の指定を通して、アドレスを管理します。もし０なら、アドレスは地域的に管
理されます。ネットワーク管理者は製品のアドレスを上書きして、異なるアド
レスを指定しました。
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'（個人/グループ）ビットは第７２番目のビットで、アドレスが個別アドレ
ス（ユニキャスト）かグループアドレス（マルチキャスト）かを決定するため
に使われます。 もし「０」なら、アドレスはユニキャストアドレスです。
もし「１」なら、アドレスはマルチキャストアドレスです。
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.
現在のＩＰｖ６プロトコルスタックで、'u'と'g'ビットの関連は重要でなく、
一般に誤って設定してもエラーを与えないでしょう；しかしながら、もし未来
の実装がＩＥＥＥのような行動で'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.
６４ビットより長いサブネット長を使うとき、前もって定められた用途を持る
かもしれず、ＩＰｖ６プロトコルスタックを混乱させるかもしれない、アドレ
スの選択を避けることは重要です。代わりの用法が全て単純なユニキャストア
ドレスとは限りません。６４ビットより長いサブネット長を選択するとき、次
の点を考慮するべきです。
B.2.5. Anycast Addresses
B.2.5. エニキャストアドレス
B.2.5.1. Subnet Router Anycast Address
B.2.5.1. サブネットルーターエニキャストアドレス
RFC 4291 [RFC4291] provides a definition for the required Subnet
Router Anycast Address as follows:
ＲＦＣ４２９１[RFC4291]が次のように要請サブネットルータエニキャストアド
レスに定義を規定します：
| n bits | 128-n bits |
+--------------------------------------------+----------------+
| subnet prefix | 00000000000000 |
+--------------------------------------------+----------------+
It is recommended to avoid allocating this IPv6 address to a device
that expects to have a normal unicast address.
普通のユニキャストアドレスを持つことを見込む装置にこのＩＰｖ６アドレス
を割り当てるのを避けることは推奨されます。
B.2.5.2. Reserved IPv6 Subnet Anycast Addresses
B.2.5.2. 予約ＩＰｖ６サブネットエニキャストアドレス
RFC 2526 [RFC2526] stated that within each subnet, the highest 128
interface identifier values are reserved for assignment as subnet
anycast addresses.
ＲＦＣ２５２６[RFC2526]は、各サブネット内で、最上位の１２８のインタフェー
ス識別子値がサブネットエニキャストアドレスへの割り当てのために予約されて
いると明記しました。
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.
サブネットの予約されているサブネットエニキャストアドレスの構成は、アドレ
スのフォーマットプレフィックスで示された、ＩＰｖ６アドレスの種類に依存し
ます。
The first type of Subnet Anycast addresses have been defined as
follows for the Modified EUI-64 format:
サブネットエニキャストアドレスの１番目の種類は、修正ＥＵＩ−６４形式に
対して定義されます：
| 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.
エニキャストアドレス構造は、ビット６５から１２１が"1111110111...111"
（全５７ビット）のサブネットプレフィックスを作成するのを避けることが重
要であることを暗示します。
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:
他のＩＰｖ６アドレス種別（すなわち、フォーマットプレフィックスが上記以
外のもの）で、インタフェース識別子は６４ビットの拡張一意識別子（ＥＵＩ−
６４）形式ではなく、６４ビット長でないかもしれません。このようなアドレ
ス種別のための予約されているサブネットエニキャストアドレスは次のように
構成されます：
| 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.
普通のユニキャストアドレスを持つことを見込む装置にこのＩＰｖ６アドレス
を割り当てるのを避けることは推奨されます。
B.2.6. Addresses Used by Embedded-RP (RFC 3956)
B.2.6 ．埋込みＲＰで使うアドレス（ＲＦＣ３９５６）
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.
埋込みＲＰ[RFC3956]はＩＰｖ６マルチキャストグループアドレスのランデブー
ポイント（ＲＰ）ＩＰｖ６アドレスを統合する概念を反映します。この埋込と
ＩＰｖ６アドレス長とＩＰｖ６マルチキャストアドレス長が１２８ビットであ
るという事実のために、実際の埋込みマルチキャストＲＰの完全なＩＰｖ６ア
ドレスを持つことはできません。
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:
これは埋込みＲＰで使うプレフィックス毎に１５の可能なＲＰアドレスがある
という制約をもたらします。埋込みＲＰのために割り当てられた空間は４つの
下位ビットに依存し、残りのランデブーインタフェース識別子（RIID）がすべ
ての「０」に設定されます。埋込みＲＰで使われたＩＰｖ６マルチキャストグ
ループアドレスのフォーマットは次の通りです：
(IPv6-prefix (64 bits))(60 bits all '0')(RIID)
（ＩＰｖ６プレフィックス（６４ビット））
（６０ビット全て「０」）（RIID）
where: (RIID) = 4 bits.
ここで：（RIID） ＝ ４ビット。
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.
このフォーマットは６４以上のサブネットを選択した場合で、６４番目のビッ
トがゼロ以外場合、サブネットが埋込みＲＰを使うことができないことを意味
します。
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.
加えて、これが重大な問題を発生しないでしょうが、本当のマルチキャストラ
ンデブーポイントでない装置に埋込みＲＰＩＰｖ６アドレスと一致するアドレ
スを割り当てることに反対します。
B.2.7. ISATAP Addresses
B.2.7. ISATAP アドレス
ISATAP [RFC5214] is an experimental automatic tunneling protocol used
to provide IPv6 connectivity over an IPv4 campus or enterprise
environment. In order to leverage the underlying IPv4
infrastructure, the IPv6 addresses are constructed in a special
format.
ISATAP[RFC5214]はＩＰｖ４キャンパスや企業環境上にＩＰｖ６接続性を提供
するために使う実験的な自動設定トンネルプロトコルです。ＩＰｖ４基盤を利
用するため、ＩＰｖ６アドレスは特別な形式で作成されます。
An IPv6 ISATAP address has the IPv4 address embedded, based on a
predefined structure policy that identifies them as an ISATAP
address. The format is as follows:
IPv6 ISATAP アドレスは埋込みのＩＰｖ４アドレスを持ち、ISATAPＴＡＰアド
レスと識別できる既知の構造方針に基づきます。フォーマットは次の通りです：
[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.
６４ビットより長いサブネットプレフィックス長を使うときで、非ISATAPイ
ンタフェースにＩＰｖ６アドレスを割り当てるとき、ＩＰｖ６プレフィックス
のビット６５から、ホスト識別子の終端までを。既知のISATAPアドレス
[0000:5EFE]と一致させないことを保証するのは良い工学的な実行です。
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
Ciprian Popoviciu
Cisco Systems
7025-6 Kit Creek Road
Research Triangle Park, North Carolina
USA
EMail: 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
T-Systems Enterprise Services GmbH
Goslarer Ufer 35
Berlin 10589
Germany
Phone: +49 30 3497 3124
EMail: 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