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