[要約] RFC 6177は、IPv6アドレスのエンドサイトへの割り当てに関するガイドラインです。その目的は、効率的で持続可能なIPv6アドレスの割り当てを促進し、インターネットの成長に対応するためのベストプラクティスを提供することです。
Internet Engineering Task Force (IETF) T. Narten
Request for Comments: 6177 IBM
BCP: 157 G. Huston
Obsoletes: 3177 APNIC
Category: Best Current Practice L. Roberts
ISSN: 2070-1721 Stanford University
March 2011
IPv6 Address Assignment to End Sites
IPv6は、エンドサイトへの割り当てをアドレスします
Abstract
概要
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.
RFC 3177は、IPv6では、ほとんどの場合、終了部位 /48ブロックを割り当てる必要があると主張しました。地域のインターネットレジストリ（RIRS）は、2002年にその勧告を採用しましたが、2005年にポリシーの再考を開始しました。この文書は、IPv6アドレススペースをエンドサイトに割り当てるRFC 3177の推奨事項を廃止しました。エンドサイトを割り当てるためのアドレススペースの正確な選択は、運用コミュニティにとって問題です。この場合のIETFの役割は、IPv6アーキテクチャおよび運用上の考慮事項に関するガイダンスを提供することに限定されています。このドキュメントでは、RFC 3177の元の推奨事項の背後にあるエンドサイトの割り当てのアーキテクチャおよび運用上の考慮事項をレビューします。さらに、このドキュメントは、 /48の万能の推奨事項が広範囲に微妙に微妙になっていないことを明確にしています。エンドサイトの範囲で、単一のデフォルトとして推奨されなくなりました。
This document obsoletes RFC 3177.
このドキュメントは、RFC 3177を廃止します。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモは、インターネットの最高の現在の練習を文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPの詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6177.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6177で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. On /48 Assignments to End Sites .................................4
3. Other RFC 3177 Considerations ...................................6
4. Impact on IPv6 Standards ........................................6
4.1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds .......6
4.2. IPv6 Multicast Addressing ..................................7
5. Summary .........................................................7
6. Security Considerations .........................................8
7. Acknowledgments .................................................8
8. Informative References ..........................................8
There are a number of considerations that factor into address assignment policies. For example, to provide for the long-term health and scalability of the public routing infrastructure, it is important that addresses aggregate well [ROUTE-SCALING]. Likewise, giving out an excessive amount of address space could result in premature depletion of the address space. This document focuses on the (more narrow) question of what is an appropriate IPv6 address assignment size for end sites. That is, when end sites request IPv6 address space from ISPs, what is an appropriate assignment size.
アドレス割り当てポリシーに考慮される多くの考慮事項があります。たとえば、パブリックルーティングインフラストラクチャの長期的な健康とスケーラビリティを提供するためには、集計に適切に対処することが重要です[ルートスケーリング]。同様に、アドレススペースの過剰な量を与えると、アドレススペースが早期に枯渇する可能性があります。このドキュメントは、エンドサイトの適切なIPv6アドレスの割り当てサイズであるものの（より狭い）質問に焦点を当てています。つまり、終了サイトがISPSからIPv6アドレススペースを要求する場合、適切な割り当てサイズは何ですか。
RFC 3177 [RFC3177] called for a default end site IPv6 assignment size of /48. Subsequently, the Regional Internet Registries (RIRs) developed and adopted IPv6 address assignment and allocation policies consistent with the recommendations of RFC 3177 [RIR-IPV6]. In 2005, the RIRs began discussing IPv6 address assignment policy again. Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have revised the end site assignment policy to encourage the assignment of smaller (i.e., /56) blocks to end sites.
RFC 3177 [RFC3177]は、 /48のデフォルトエンドサイトIPv6割り当てサイズを要求しました。その後、地域のインターネットレジストリ（RIRS）は、RFC 3177 [RIR-IPV6]の推奨事項と一致するIPv6アドレスの割り当ておよび割り当てポリシーを開発および採用しました。2005年、RIRSはIPv6アドレスの割り当てポリシーについて再び議論し始めました。それ以来、Apnic [Apnic-endsite]、Arin [Arin-endsite]、およびRipe [Ripe-endsite]は、エンドサイトの割り当てポリシーを修正して、小規模な（つまり、 /56）ブロックを終了するサイトの割り当てを促進しました。
This document obsoletes RFC 3177, updating its recommendations in the following ways:
このドキュメントはRFC 3177を廃止し、次の方法で推奨事項を更新します。
1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition, implies multiple subnets and multiple devices.
1) /128を配布することはもうお勧めしません。単一のアドレスのみを割り当てることが正当化される場合がある場合がありますが、定義上、サイトは複数のサブネットと複数のデバイスを意味します。
2) RFC 3177 specifically recommended using prefix lengths of /48, /64, and /128. Specifying a small number of fixed boundaries has raised concerns that implementations and operational practices might become "hard-coded" to recognize only those fixed boundaries (i.e., a return to "classful addressing"). The actual intention has always been that there be no hard-coded boundaries within addresses, and that Classless Inter-Domain Routing (CIDR) continues to apply to all bits of the routing prefixes.
2) RFC 3177は、 /48、 /64、および /128のプレフィックス長さを使用して特別に推奨されています。少数の固定境界を指定することで、実装と運用慣行がこれらの固定境界のみを認識するために「ハードコーディング」になる可能性があるという懸念が提起されました（つまり、「クラスフルアドレス指定」への復帰）。実際の意図は、常にアドレス内にハードコーディングされた境界がなく、クラスレスドメイン間ルーティング（CIDR）がルーティングのプレフィックスのすべてのビットに引き続き適用されることです。
3) This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate.
3) このドキュメントは、単一のデフォルトの割り当てサイズ（A /48など）が一般的なケースのすべてのエンドサイトにとって理にかなっているという以前の推奨事項から離れて移動します。エンドサイトにはさまざまな形状とサイズがあり、万能のアプローチは必要または適切ではありません。
This document does, however, reaffirm an important assumption behind RFC 3177:
ただし、このドキュメントは、RFC 3177の背後にある重要な仮定を再確認します。
A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.
アドレス管理の重要な原則は、エンドサイトでは、実際の使用と計画された使用のために、および数か月ではなく数年で指定された時間の経過とともに、妥当な量のアドレススペースを常に取得できることです。実際には、それは少なくとも1 /64を意味し、ほとんどの場合は大幅に多くを意味します。避けなければならない特定の状況の1つは、十分なアドレススペースを取得できないため、IPv6-to-IPV6ネットワークアドレスの翻訳またはその他の負担のあるアドレス保存技術を使用することを強いられている最終サイトの感触を持つことです。
This document does not make a formal recommendation on what the exact assignment size should be. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document provides input into those discussions. The focus of this document is to examine the architectural issues and some of the operational considerations relating to the size of the end site assignment.
このドキュメントでは、正確な割り当てサイズがどうあるべきかについての正式な推奨事項はありません。エンドサイトを割り当てるためのアドレススペースの正確な選択は、運用コミュニティにとって問題です。この場合のIETFの役割は、IPv6アーキテクチャおよび運用上の考慮事項に関するガイダンスを提供することに限定されています。このドキュメントは、これらの議論への入力を提供します。このドキュメントの焦点は、アーキテクチャの問題と、エンドサイトの割り当てのサイズに関連する運用上の考慮事項のいくつかを調べることです。
Looking back at some of the original motivations behind the /48 recommendation [RFC3177], there were three main concerns. The first motivation was to ensure that end sites could easily obtain sufficient address space without having to "jump through hoops" to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification. As a comparison point, in IPv4, typical home users are given a single public IP address (though even this is not always assured), but getting any more than one address is often difficult or even impossible -- unless one is willing to pay a (significantly) increased fee for what is often considered to be a "higher grade" of service. (It should be noted that increased ISP charges to obtain a small number of additional addresses cannot usually be justified by the real per-address cost levied by RIRs, but additional addresses are frequently only available to end users as part of a different type or "higher grade" of service, for which an additional charge is levied. The point here is that the additional cost is not due to the RIR fee structures, but to business choices ISPs make.) An important goal in IPv6 is to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks" and to ensure that end sites can easily obtain address space.
/48推奨の背後にある元の動機のいくつかを振り返って[RFC3177]、3つの主な懸念がありました。最初の動機は、エンドサイトが「フープを飛び越えて」そうすることなく、十分なアドレス空間を簡単に取得できるようにすることでした。たとえば、誰かがより多くのスペースが必要だと感じた場合、尋ねる行為だけがある程度の正当化になるでしょう。比較ポイントとして、IPv4では、典型的なホームユーザーには単一のパブリックIPアドレスが与えられます（これも常に保証されているわけではありませんが）が、複数のアドレスを取得することは難しいか不可能でさえあります - （大幅に）サービスの「より高いグレード」としばしば考えられるものの料金の増加。（少数の追加アドレスを取得するためのISP料金の増加は、通常、RIRSによって課される実際のアドレス通りコストによって正当化できないことに注意してください。追加料金が徴収されるサービスのより高いグレード」。ここでのポイントは、追加コストがRIR料金構造によるものではなく、ISPが作成するビジネスの選択によるものです。）IPv6の重要な目標は、デフォルトを大幅に変更することです。「単一のアドレス」から「複数のネットワーク」まで、最小限のエンドサイトの割り当て、およびエンドサイトでアドレススペースを簡単に取得できるようにします。
A second motivation behind the original /48 recommendation was to simplify the management of an end site's addressing plan in the presence of renumbering (e.g., when switching ISPs). In IPv6, a site may simultaneously use multiple prefixes, including one or more public prefixes from ISPs as well as Unique Local Addresses [ULA-ADDRESSES]. In the presence of multiple prefixes, it is significantly less complex to manage a numbering plan if the same subnet numbering plan can be used for all prefixes. That is, for a link that has (say) three different prefixes assigned to it, the subnet portion of those prefixes would be identical for all assigned addresses. In contrast, renumbering from a larger set of "subnet bits" into a smaller set is often painful, as it can require making changes to the network itself (e.g., collapsing subnets). Hence, renumbering a site into a prefix that has (at least) the same number of subnet bits is more straightforward, because only the top-level bits of the address need to change. A key goal of the recommendations in RFC 3177 is to ensure that upon renumbering, one does not have to deal with renumbering into a smaller subnet size.
オリジナル /48の推奨の背後にある2番目の動機は、変更の存在下でエンドサイトのアドレス指定計画の管理を簡素化することでした（例えば、ISPを切り替えるとき）。IPv6では、サイトは、ISPからの1つ以上のパブリックプレフィックスと、一意のローカルアドレス[ULA-Addresses]を含む複数の接頭辞を同時に使用できます。複数の接頭辞が存在する場合、すべてのプレフィックスに同じサブネットの番号付け計画を使用できる場合、ナンつ計画を管理するのは大幅に複雑ではありません。つまり、（たとえば）3つの異なるプレフィックスが割り当てられているリンクの場合、それらのプレフィックスのサブネット部分は、割り当てられたすべてのアドレスと同じです。対照的に、「サブネットビット」の大きなセットから小さなセットに変更することは、ネットワーク自体（サブネットの崩壊など）を変更する必要があるため、多くの場合痛みを伴うことがよくあります。したがって、サイトを（少なくとも）同じ数のサブネットビットを持つプレフィックスに変更することは、アドレスのトップレベルビットのみを変更する必要があるため、より簡単です。RFC 3177の推奨事項の重要な目標は、名前を変更すると、より小さなサブネットサイズに変更する必要がないことを保証することです。
It should be noted that similar arguments apply to the management of zone files in the DNS. In particular, managing the reverse (ip6.arpa) tree is simplified when all links are numbered using the same subnet ids.
同様の引数がDNSのゾーンファイルの管理に適用されることに注意する必要があります。特に、すべてのリンクに同じサブネットIDを使用して番号が付けられている場合、逆（IP6.ARPA）ツリーの管理が簡素化されます。
A third motivation behind the /48 recommendation was to better support network growth common at many sites. In IPv4, it is usually difficult (or impossible) to obtain public address space for more than a few months worth of projected growth. Thus, even slow growth over several years can lead to the need to renumber into a larger address block. With IPv6's vast address space, end sites can easily be given more address space (compared with IPv4) to support expected growth over multi-year time periods.
/48の推奨の背後にある3番目の動機は、多くのサイトで一般的なネットワーク成長をよりよくサポートすることでした。IPv4では、通常、数ヶ月以上の予測される成長のためにパブリックアドレススペースを取得することは通常困難です（または不可能）。したがって、数年にわたって成長が遅いことでさえ、より大きなアドレスブロックに変更する必要性につながる可能性があります。IPv6の広大なアドレススペースを使用すると、エンドサイトをより多くのアドレススペース（IPv4と比較して）を簡単に与えて、数年間の期間にわたる予想される成長をサポートできます。
While the /48 recommendation does simplify address space management for end sites, it has also been widely criticized as being wasteful. For example, a large business (which may have thousands of employees) would, by default, receive the same amount of address space as a home user, who today typically has a single (or small number of) LAN and a small number of devices (dozens or less). While it seems likely that the size of a typical home network will grow over the next few decades, it is hard to argue that home sites will make use of 65K subnets within the foreseeable future. At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.
/48の推奨事項は、エンドサイトの住所スペース管理を簡素化しますが、無駄になっていると広く批判されています。たとえば、大企業（何千人もの従業員がいる可能性がある）は、デフォルトでは、現在、今日では単一（または少数の）LANと少数のデバイスを持っているホームユーザーと同じ量の住所スペースを受け取ります。（数十以下）。典型的なホームネットワークの規模は今後数十年にわたって成長する可能性がありますが、ホームサイトが近い将来65Kサブネットを利用すると主張するのは困難です。同時に、今日のIPv4プラクティスと比較してすでに大幅に多くのアドレス空間であるため、ホームサイトにシングル /64を与えることは魅力的かもしれません。ただし、これは、故郷のサイトでさえ、今後の複数のサブネットをサポートするために成長するという期待を排除します。したがって、デフォルトでは、故郷のサイトでさえ複数のサブネット相当のスペースを与えることを強く意図しています。したがって、このドキュメントは、ホームサイトに1つの /64を大幅に多く提供することを推奨していますが、すべてのホームサイトにA /48を与えられることも推奨していません。
A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites, e.g., home sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.)
ポリシーの変更（上記など）は、住所消費投影とIPv6の予想される寿命に大きな影響を与えます。たとえば、デフォルトの割り当てをA /48から /56に変更すると（エンドサイトの大部分など、ホームサイトなど）、最大8ビットの節約になり、「総予測アドレス消費」が（上昇して」減少します。に）8ビットまたは2桁。（貯蓄の正確な量は、大きなサイトの数と比較して、ホームユーザーの相対的な数に依存します。）
The above-mentioned goals of RFC 3177 can easily be met by giving home users a default assignment of less than /48, such as a /56.
RFC 3177の上記の目標は、A /56などの /48未満のデフォルトの割り当てをホームユーザーに提供することで簡単に満たすことができます。
RFC 3177 suggested that some multihoming approaches (e.g., Generalized Structure Element (GSE)) might benefit from having a fixed /48 boundary. This no longer appears to be a consideration.
RFC 3177は、一部のマルチホームアプローチ（例：一般化構造要素（GSE））が固定 /48境界を持つことで恩恵を受ける可能性があることを示唆しました。これはもはや考慮事項ではないようです。
RFC 3177 argued that having a "one-size-fits-all" default assignment size reduced the need for customers to continually or repeatedly justify the usage of existing address space in order to get "a little more". Likewise, it also reduces the need for ISPs to evaluate such requests. Given the large amount of address space in IPv6, there is plenty of space to grant end sites enough space to be consistent with reasonable growth projections over multi-year time frames. Thus, it remains highly desirable to provide end sites with enough space (on both initial and subsequent assignments) to last several years. Fortunately, this goal can be achieved in a number of ways and does not require that all end sites receive the same default size assignment.
RFC 3177は、「One-Size-Fit-All」デフォルトの割り当てサイズを持つことで、顧客が「もう少し」を取得するために既存のアドレススペースの使用を継続的または繰り返し正当化する必要性が減少すると主張しました。同様に、ISPがそのような要求を評価する必要性も減らします。IPv6のアドレススペースが大量にあることを考えると、エンドサイトに十分なスペースを付与するスペースが十分にあり、複数年の時間枠にわたって合理的な成長予測と一致するのに十分なスペースがあります。したがって、最後のサイト（初期およびその後の課題の両方で）を持続するために、エンドサイトに十分なスペースを提供することが非常に望ましいままです。幸いなことに、この目標はさまざまな方法で達成でき、すべてのエンドサイトが同じデフォルトサイズの割り当てを受信する必要はありません。
RFC 3056 [RFC3056] describes a way of generating IPv6 addresses from an existing public IPv4 address. That document describes an address format in which the first 48 bits concatenate a well-known prefix with a globally unique public IPv4 address. The "SLA ID" field is assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To facilitate transitioning from the address numbering scheme in RFC 3056 to one based on a prefix obtained from an ISP, an end site would be advised to number out of the right most bits first, using the leftmost bits only if the size of the site made that necessary.
RFC 3056 [RFC3056]は、既存のパブリックIPv4アドレスからIPv6アドレスを生成する方法を説明しています。このドキュメントでは、最初の48ビットがグローバルに一意のパブリックIPv4アドレスを持つよく知られているプレフィックスを連結するアドレス形式について説明します。「SLA ID」フィールドは16ビットであると想定されており、16ビットの「サブネットID」フィールドと一致しています。ISPから取得したプレフィックスに基づいてRFC 3056のアドレス番号付けスキームから1つへの移行を容易にするために、左端のビットを使用して、最初に右のビットから番号を出すことをお勧めします。それは必要です。
Similar considerations apply to other documents that allow for a subnet id of 16 bits, including [ULA-ADDRESSES].
同様の考慮事項は、[ula-addresses]を含む16ビットのサブネットIDを可能にする他のドキュメントにも適用されます。
Some IPv6 multicast address assignment schemes embed a unicast IPv6 prefix into the multicast address itself [RFC3306]. Such documents do not assume a particular size for the subnet id, per se, but do assume that the IPv6 prefix is a /64. Thus, the relative size of the subnet id has no direct impact on multicast address schemes.
一部のIPv6マルチキャストアドレスの割り当てスキームは、Unicast IPv6プレフィックスをマルチキャストアドレス自体に埋め込みました[RFC3306]。このようなドキュメントは、サブネットID自体の特定のサイズを想定していませんが、IPv6プレフィックスがA /64であると仮定しています。したがって、サブネットIDの相対サイズは、マルチキャストアドレススキームに直接影響を与えません。
The exact choice of how much address space to assign end sites is an issue for the operational community. The recommendation in RFC 3177 [RFC3177] to assign /48s as a default is not a requirement of the IPv6 architecture; anything of length /64 or shorter works from a standards perspective. However, there are important operational considerations as well, some of which are important if users are to share in the key benefit of IPv6: expanding the usable address space of the Internet. The IETF recommends that any policy on IPv6 address assignment policy to end sites take into consideration the following:
エンドサイトを割り当てるためのアドレススペースの正確な選択は、運用コミュニティにとって問題です。RFC 3177 [RFC3177]の推奨事項 /48Sをデフォルトとして割り当てることは、IPv6アーキテクチャの要件ではありません。標準的な観点から長さ /64または短い作品。ただし、重要な運用上の考慮事項もあります。ユーザーがIPv6の主要な利点を共有する場合に重要なものもあります。インターネットの使用可能なアドレススペースを拡大することです。IETFは、IPv6アドレスの割り当てポリシーに関するポリシーが終了サイトを考慮することを推奨しています。
- it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64) and to support reasonable growth projections over long time periods (e.g., a decade or more).
- エンドサイトがアドレススペースを取得して、複数のサブネット（つまり、単一 /64よりも大きいブロック）を数え、長期間にわたって合理的な成長予測（10年以上）をサポートするのは簡単です。
- the default assignment size should take into consideration the likelihood that an end site will have need for multiple subnets in the future and avoid the IPv4 practice of having frequent and continual justification for obtaining small amounts of additional space.
- デフォルトの割り当てサイズは、エンドサイトが将来複数のサブネットを必要とする可能性を考慮し、少量の追加スペースを取得するために頻繁かつ継続的な正当化を持つというIPv4の慣行を回避する必要があります。
- Although a /64 can (in theory) address an almost unlimited number of devices, sites should be given sufficient address space to be able to lay out subnets as appropriate, and not be forced to use address conservation techniques such as using bridging. Whether or not bridging is an appropriate choice is an end site matter.
- A /64は（理論的には）ほぼ無制限の数のデバイスに対処できますが、必要に応じてサブネットをレイアウトできるように十分なアドレススペースを提供する必要があり、ブリッジングの使用などのアドレス保存技術を使用することを余儀なくされません。ブリッジングが適切な選択であるかどうかは、最終サイトの問題です。
- assigning a longer prefix to an end site, compared with the existing prefixes the end site already has assigned to it, is likely to increase operational costs and complexity for the end site, with insufficient benefit to anyone.
- エンドサイトが既に割り当てている既存のプレフィックスと比較して、より長いプレフィックスをエンドサイトに割り当てることは、エンドサイトの運用コストと複雑さを増加させる可能性が高く、誰にも不十分な利益をもたらします。
- the operational considerations of managing and delegating the reverse DNS tree under ip6.arpa on nibble versus non-nibble boundaries should be given adequate consideration.
- ニブルと非ナブル境界に関するIP6.ARPAの下で逆DNSツリーを管理および委任するという運用上の考慮事項には、適切な考慮事項が与えられる必要があります。
This document has no known security implications.
このドキュメントには、セキュリティへの影響は既知のものではありません。
This document was motivated by and benefited from numerous conversations held during the ARIN XV and RIPE 50 meetings in April-May, 2005.
この文書は、2005年4月の5月のARIN XVとRipe 50の会議で開催された多数の会話によって動機付けられ、恩恵を受けました。
[APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment and utilisation requirement policy," http://www.apnic.net/policy/proposals/prop-031
[APNIC-ENDSITE] "Prop-031：APNIC IPv6の割り当ておよび利用要件ポリシーを修正する提案、" http://www.apnic.net/policy/proposals/prop-031
[ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement", http://www.arin.net/policy/proposals/2005_8.html
[ARIN-ENDSITE] "2005-8：Arin IPv6の割り当ておよび利用要件を修正する提案"、http://www.arin.net/policy/proposals/2005_8.html
[RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE
Document ID: ripe-267, Date: 22 January 2003
http://www.ripe.net/ripe/docs/ipv6policy.html; APNIC:
http://www.apnic.net/docs/policy/ipv6-address-
policy.html
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306] Haberman、B。およびD. Thaler、「Unicast-PrefixベースのIPv6マルチキャストアドレス」、RFC 3306、2002年8月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABおよびIESG、「IPv6に関するIAB/IESGの推奨事項は、サイトへの割り当てアドレス」、RFC 3177、2001年9月。
[RIPE-ENDSITE] "Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy", 2005-8, http://www.ripe.net/ripe/policies/proposals/2005-08.
[Ripe-Endsite]「IPv6の割り当ておよび利用要件ポリシーを改正する提案」、2005-8、http：//www.ripe.net/ripe/policies/proposals/2005-08。
[ROUTE-SCALING] "Routing and Addressing Problem Statement", Work in Progress, February 2010.
[ルートスケーリング]「ルーティングとアドレス指定の問題声明」、2010年2月の進行中の作業。
[ULA-ADDRESSES] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[Ula-Addresses] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
Authors' Addresses
著者のアドレス
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park、NC 27709-2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
電話：919-254-7798メール：narten@us.ibm.com
Geoff Huston APNIC
Geoff Huston Apnic
EMail: gih@apnic.net
Rosalea G Roberts Stanford University, Networking Systems P.O. Box 19131 Stanford, CA 94309-9131
Rosalea G Roberts Stanford University、Networking Systems P.O.Box 19131 Stanford、CA 94309-9131
EMail: lea.roberts@stanford.edu
Phone: +1-650-723-3352