RFC 6177 IPv6 Address Assignment to End Sites

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ブロックを割り当てる必要があると主張しました。 地域インターネットレジストリ（RIR）は2002年にその勧告を採用しましたが、2005年にポリシーの再検討を開始しました。 このドキュメントは、エンドサイトへのIPv6アドレススペースの割り当てに関するRFC 3177の推奨事項を廃止します。 エンドサイトを割り当てるアドレススペースの正確な選択は、運用コミュニティの問題です。 この場合のIETFの役割は、IPv6のアーキテクチャおよび運用上の考慮事項に関するガイダンスの提供に限定されています。 このドキュメントでは、エンドサイトの割り当てに関するアーキテクチャ上および運用上の考慮事項と、RFC 3177の元の推奨事項の背後にある動機について説明します。 さらに、このドキュメントは、/ 48の1つのサイズに適合する推奨事項は、広範囲のエンドサイトに対して十分に微妙に調整されておらず、単一のデフォルトとして推奨されなくなったことを明らかにしています。

   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（Internet Engineering Task Force）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 これは公開レビューを受けており、Internet Engineering Steering Group（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で入手できます。

Narten, et al.            Best Current Practice                 [Page 1]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

   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標準プロセスの範囲外でそのような資料の変更を許可する権利を付与していない可能性があります。 このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントは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

    1.はじめに............................................... ..... 3
    2. / 48のエンドサイトへの割り当て.................................4
    3.その他のRFC 3177の考慮事項................................... 6
    4. IPv6標準への影響........................................ 6
       4.1. RFC 3056：IPv4クラウドを介したIPv6ドメインの接続....... 6
       4.2. IPv6マルチキャストアドレッシング..........................7
    5.まとめ..........................................................7
    6.セキュリティに関する考慮事項....................................8
    7.謝辞............................................... ..8
    8.参考資料.......................................... 8

Narten, et al.            Best Current Practice                 [Page 2]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


1.  Introduction

1.はじめに

   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アドレス割り当てサイズとは何か（より狭い）質問に焦点を当てています。 つまり、エンドサイトが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.

RFC 3177 [RFC3177]は、デフォルトのエンドサイトIPv6割り当てサイズ/ 48を要求しました。 その後、リージョナルインターネットレジストリ（RIR）は、RFC 3177 [RIR-IPV6]の推奨事項と整合性のある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）/ 48、/ 64、/ 128のプレフィックス長を使用することを特に推奨するRFC 3177。 少数の固定境界を指定すると、実装と運用慣行が「ハードコード化」されてそれらの固定境界のみを認識する（つまり、「クラスフルアドレッシング」に戻る）ことが懸念されます。 実際の意図は常に、アドレス内にハードコーディングされた境界がないこと、およびクラスレスドメイン間ルーティング（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）が一般的なケースのすべてのエンドサイトに意味があるという以前の推奨事項から離れています。 最終サイトにはさまざまな形とサイズがあり、万能のアプローチは必要でも適切でもありません。

Narten, et al.            Best Current Practice                 [Page 3]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


   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から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のアーキテクチャおよび運用上の考慮事項に関するガイダンスの提供に限定されています。 このドキュメントはそれらの議論へのインプットを提供します。 このドキュメントの焦点は、アーキテクチャの問題と、エンドサイトの割り当てのサイズに関連する運用上の考慮事項のいくつかを調べることです。

2.  On /48 Assignments to End Sites

2. / 48の最終サイトへの割り当て

   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料金の増加は、RIRによって課される実際のアドレスあたりのコストでは正当化できませんが、追加アドレスは、多くの場合、エンドユーザーが別のタイプの一部としてのみ利用できます。追加料金が課されるサービスのより高い等級」。 ここでの要点は、追加コストはRIR料金体系によるものではなく、ISPが行うビジネス上の選択によるものです。）IPv6の重要な目標は、デフォルトおよび最小のエンドサイト割り当てを「単一アドレス」から「単一アドレス」に大幅に変更することです。複数のネットワーク」を使用して、エンドサイトがアドレス空間を簡単に取得できるようにします。

Narten, et al.            Best Current Practice                 [Page 4]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


   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




Narten, et al.            Best Current Practice                 [Page 5]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


   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のサブネットを使用することを主張するのは困難です。 同時に、ホームサイトに単一の/ 64を与えるのは魅力的かもしれません。これは、今日のIPv4プラクティスと比較して、すでにかなり大きなアドレススペースであるためです。 ただし、これにより、ホームサイトでさえも将来的に複数のサブネットをサポートするように成長するという期待は排除されます。 したがって、デフォルトでは、ホームサイトにも複数のサブネットに相当するスペースが与えられることが強く意図されています。 したがって、このドキュメントでは、単一の/ 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の予想される寿命に大きな影響を与えます。 たとえば、デフォルトの割り当てを/ 48から/ 56に変更すると（ホームサイトなどの大部分のエンドサイトの場合）、最大8ビットの節約となり、（予測されるアドレス消費の合計）が（up to）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の目標は、/ 56など、/ 48未満のデフォルト割り当てをホームユーザーに与えることで簡単に満たすことができます。

3.  Other RFC 3177 Considerations

3. RFC 3177に関するその他の考慮事項

   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-fits-all」のデフォルトの割り当てサイズを使用することで、顧客が「もう少し」を取得するために既存のアドレス空間の使用を継続的または繰り返し正当化する必要性を減らすと主張しました。 同様に、ISPがそのような要求を評価する必要性も減少します。 IPv6には大量のアドレススペースがあるため、複数年の時間枠にわたる合理的な成長予測と整合するのに十分なスペースをエンドサイトに付与するための十分なスペースがあります。 したがって、エンドサイトに（最初の割り当てとその後の割り当ての両方で）数年続くのに十分なスペースを提供することが非常に望ましいままです。 幸い、この目標はさまざまな方法で達成でき、すべてのエンドサイトが同じデフォルトサイズの割り当てを受け取る必要はありません。

4.  Impact on IPv6 Standards

4. IPv6標準への影響

4.1.  RFC 3056: Connection of IPv6 Domains via IPv4 Clouds

4.1。 RFC 3056：IPv4クラウドを介した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」フィールドと一致しています。 RFC 3056のアドレス番号付けスキームからISPから取得したプレフィックスに基づくものへの移行を容易にするために、エンドサイトは、サイトのサイズが作成された場合にのみ、左端のビットを使用して、最初に右端のビットから番号を付けることをお勧めします それが必要です。

Narten, et al.            Best Current Practice                 [Page 6]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


   Similar considerations apply to other documents that allow for a
   subnet id of 16 bits, including [ULA-ADDRESSES].

[ULA-ADDRESSES]など、16ビットのサブネットIDを許可する他のドキュメントにも同様の考慮事項が適用されます。

4.2.  IPv6 Multicast Addressing

4.2。 IPv6マルチキャストアドレス指定

   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マルチキャストアドレス割り当てスキームは、ユニキャストIPv6プレフィックスをマルチキャストアドレス自体に埋め込みます[RFC3306]。 そのようなドキュメントは、それ自体、サブネットIDの特定のサイズを想定していませんが、IPv6プレフィックスが/ 64であることを想定しています。 したがって、サブネットIDの相対的なサイズは、マルチキャストアドレススキームに直接影響しません。

5.  Summary

5.まとめ

   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:

エンドサイトを割り当てるアドレススペースの正確な選択は、運用コミュニティの問題です。 / 48をデフォルトとして割り当てるという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よりも大きいブロック）に番号を付けるためのアドレス空間を取得し、長期間（たとえば、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.

-/ 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.

-エンドサイトに割り当てられている既存のプレフィックスと比較して、エンドサイトに長いプレフィックスを割り当てると、エンドサイトの運用コストと複雑さが増し、誰にとっても十分なメリットが得られない可能性があります。

Narten, et al.            Best Current Practice                 [Page 7]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


      - 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ツリーの管理と委任の運用上の考慮事項には、十分な考慮が必要です。

6.  Security Considerations

6.セキュリティに関する考慮事項

   This document has no known security implications.

このドキュメントには、既知のセキュリティ上の影響はありません。

7.  Acknowledgments

7.謝辞

   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会議中に開催された数多くの会話から動機付けられ、その恩恵を受けました。

8.  Informative References

8.参考情報

   [APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment
                   and utilisation requirement policy,"
                   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

   [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.

   [RFC3306]       Haberman, B. and D. Thaler, "Unicast-Prefix-based
                   IPv6 Multicast Addresses", RFC 3306, August 2002.

   [RFC3177]       IAB and IESG, "IAB/IESG Recommendations on IPv6
                   Address Allocations to Sites", RFC 3177, September
                   2001.

   [RIPE-ENDSITE]  "Proposal to Amend the IPv6 Assignment and
                   Utilisation Requirement Policy", 2005-8,
                   http://www.ripe.net/ripe/policies/proposals/2005-08.

   [ROUTE-SCALING] "Routing and Addressing Problem Statement", Work in
                   Progress, February 2010.





Narten, et al.            Best Current Practice                 [Page 8]

RFC 6177          IPv6 Address Assignment to End Sites        March 2011


   [ULA-ADDRESSES] Hinden, R. and B. Haberman, "Unique Local IPv6
                   Unicast Addresses", RFC 4193, October 2005.

Authors' Addresses

   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


   Geoff Huston
   APNIC

   EMail: gih@apnic.net


   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























Narten, et al.            Best Current Practice                 [Page 9]