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
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ブロックを割り当てられるべきであると主張しました。地域インターネットレジストリ（RIRは）2002年にその勧告を採択したが、このドキュメントでは、サイトを終了するには、IPv6アドレス空間の割り当て上のRFC 3177勧告を廃止2005年に政策を見直し始めました。エンドサイトを割り当てる方法くらいのアドレス空間の正確な選択は、運用コミュニティのための問題です。この場合、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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
アドレス割り当てポリシーに考慮検討事項がいくつかあります。例えば、公共のルーティングインフラストラクチャの長期的な健康とスケーラビリティを提供するために、アドレスは[ROUTEスケーリング]も集約することが重要です。同様に、アドレス空間の過剰量を与えることは、アドレス空間の早すぎる枯渇につながる可能性があります。この文書は、エンドサイトに適したIPv6アドレスの割り当てサイズが何であるかの（より狭い）問題に焦点を当てています。エンドサイトは、適切な割り当てサイズが何であるかのISPからの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.
/ 48のデフォルトのエンドサイトのIPv6の割り当てサイズを呼びかけRFC 3177 [RFC3177]。その後、地域インターネットレジストリ（RIRは）RIR-IPV6] RFC 3177の勧告と一致したIPv6アドレスの割り当てと割り当てポリシーを開発し、採用しました。 2005年には、RIRは再びの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）それはもはや128Sが配られる/ことをお勧めではありません。定義によって、サイトを正当化することができる唯一の単一のアドレスを割り当てる場合があるかもしれませんが、複数のサブネットと複数のデバイスを意味します。
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）この文書は、（例えば、/ 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を意味し、ほとんどの場合、かなり多くの。それは十分なアドレス空間を得ることができなかったので、エンドサイトがIPv6ツーIPv6ネットワークアドレス変換（NAT）または他の厄介なアドレス保全技術を使用せざるを得ないと感じたされて避けなければならない一つの特定の状況。
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]の背後にあるオリジナルの動機の一部を振り返ると、三つの主要な懸念がありました。最初の動機は、エンドサイトが簡単にそうするように、「フープを介してジャンプ」することなく、十分なアドレス空間を得ることができたことを確実にするためでした。誰かが、彼らはより多くのスペースを必要と感じた場合、尋ねるだけの行為は、いくつかのレベルで十分な正当化だろう。比較のポイントとして、IPv4の中で、典型的なホームユーザーは、単一のパブリックIPアドレスを（でも、これは必ずしも保証されないが）与えられているが、任意の複数のアドレスを取得することはしばしば困難または不可能でさえある - 1が支払うことをいとわない限り（大幅に）多くの場合、サービスの「高品位」であると考えられているもののための手数料が増加しました。 （追加のアドレスの数が少ない通常のRIRで徴収実際のアドレス毎のコストによって正当化することはできません得るために、ISP料金の増加ことに留意すべきであるが、追加のアドレスは、しばしば「異なるタイプまたはの一部としてエンドユーザーにのみ使用可能です追加料金が徴収されるサービスの高グレード」、。ここでのポイントは、追加コストが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勧告の背後にある第二の動機は、リナンバリングの存在下でエンドサイトのアドレス指定計画の管理を簡素化することであった（例えば、ISPの切り替え時）。 IPv6では、サイトが同時に一の以上のISPからの公共のプレフィックスだけでなく、ユニークローカルアドレス[ULA-ADDRESSES]を含む複数のプレフィックスを使用することができます。複数のプレフィックスの存在下で、それは同じサブネットの番号計画はすべてのプレフィックスのために使用することができる場合は番号計画を管理するために大幅に少なく複雑です。それはそれに割り当てられている（例えば）3つの異なるプレフィックスを持つリンクのために、これらのプレフィックスのサブネット部分が割り当てられているすべてのアドレスについて同一である、です。それは、ネットワーク自体への変更（例えば、サブネットを崩壊）を製造する必要ができるようにこれとは対照的に、小さなセットに「サブネットビット」のより大きな集合からリナンバリングは、しばしば痛みを伴います。アドレスの唯一の最上位ビットを変更する必要があるので、従って、サブネット同じビット数がより簡単である（少なくとも）を有するプレフィックスへサイトをリナンバリング。 RFC 3177の推奨事項の重要な目標はリナンバリング時に、1が小さいサブネットサイズにリナンバリングに対処する必要がないことを確認することです。
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の勧告の背後にある第三の動機は、より良い多くのサイトでの一般的なネットワークの成長をサポートすることでした。 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を与えるために誘惑される可能性があります。しかし、これも、ホームのサイトは今後、複数のサブネットをサポートするために、成長する期待を排除します。したがって、強くも、家庭サイトは、デフォルトでは、スペースの価値が複数のサブネットを与えられることが意図されています。したがって、この文書はまだ独身/ 64よりも有意に多くの家庭のサイトを与えることをお勧めしますが、すべての家庭サイトが/ 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の予想寿命に大きな影響を有するであろう。例えば、（例えば、エンドサイトの大半のホームサイト）/ 56まで/ 48からデフォルトの割り当てを変更すると、（アップにより、「総投影アドレスの消費を」還元、最大8ビットの節約になるでしょう8ビットまたは二桁）へ。 （貯蓄の正確な量は、大規模なサイトの数と比較ホームユーザーの相対数によって異なります。）
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の上記の目標は簡単な/ 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には、「フリーサイズ」デフォルトの割り当てサイズを有する顧客が継続的にまたは繰り返し「もう少し」を取得するために、既存のアドレススペースの使用を正当化する必要性が減少することを主張しました。同様に、それはまた、そのような要求を評価するための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ビットの「サブネットID」フィールドと一致する16ビットであると仮定されます。 ISPから取得したプレフィックスに基づいて一つにRFC 3056のアドレスナンバリングスキームからの移行を容易にするために、エンドサイトは、サイトのサイズが行わ場合にのみ、左端のビットを使用して、最初の右端のビットのうちの番号を付けるように助言されますその必要。
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マルチキャストアドレス割り当て方式は、マルチキャストアドレス自体[RFC3306]にユニキャストIPv6プレフィックスを埋め込みます。このような文書は、それ自体、サブネットIDの特定のサイズを想定していませんが、IPv6プレフィックスが/ 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:
エンドサイトを割り当てる方法くらいのアドレス空間の正確な選択は、運用コミュニティのための問題です。デフォルトとして/ 48Sを割り当てるRFC 3177に推薦[RFC3177]は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よりも大きい、すなわち、ブロック）番号し、長い期間（例えば、十年以上）にわたって合理的成長予測をサポートするためにアドレス空間を得ることが容易であるべきです。
- 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.
- / 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.
この文書は、が動機と4〜5月、2005年に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 "プロプ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
[RIR-IPV6] ARIN：http://www.arin.net/policy/nrpm.html#ipv6。 RIPEドキュメントID：熟し-267、日：2003年1月22日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]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースの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、RFC 3177、2001年9月 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"。
[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.
[ROUTEスケーリング]「ルーティングとアドレッシング問題文」、進歩、2010年2月での作業。
[ULA-ADDRESSES] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[ULA-ADDRESSES] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
Authors' Addresses
著者のアドレス
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 Research Triangle Park, NC 27709-2195
トーマスNarten氏IBMコーポレーション3039コーンウォリスアベニュー。私書箱12195リサーチトライアングルパーク、ノースカロライナ州27709から2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
電話：919-254-7798 Eメール：narten@us.ibm.com
Geoff Huston APNIC
ジェフ・ヒューストンAPNIC
EMail: gih@apnic.net
メールアドレス：gih@apnic.net
Rosalea G Roberts Stanford University, Networking Systems P.O. Box 19131 Stanford, CA 94309-9131
Rosalea G・ロバーツスタンフォード大学、ネットワークシステムの私書箱ボックス19131スタンフォード、CA 94309から9131
EMail: lea.roberts@stanford.edu Phone: +1-650-723-3352
メールアドレス：lea.roberts@stanford.edu電話：+ 1-650-723-3352