RFC 6308 - Overview of the Internet Multicast Addressing Architecture 日本語訳

URL : https://tools.ietf.org/html/rfc6308
タイトル : RFC 6308 - インターネットマルチキャストアドレッシングアーキテクチャの概要
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                         P. Savola
Request for Comments: 6308                                     CSC/FUNET
Obsoletes: 2908                                                June 2011
Category: Informational
ISSN: 2070-1721

       Overview of the Internet Multicast Addressing Architecture

Abstract

抽象

The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use.

IPマルチキャストアドレスの割り当てと割り当て手続きに関する最新のドキュメントの欠如が大きな混乱を引き起こしています。状況を明確にするために、このメモは使用中（これを書いているように）現在割り当ておよび割り当て技術およびメカニズムを説明しています。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6308.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6308で取得することができます。

著作権表示

著作権（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ライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology: Allocation or Assignment ......................3
   2. Multicast Address Allocation ....................................3
      2.1. Derived Allocation .........................................3
           2.1.1. GLOP Allocation .....................................4
           2.1.2. Unicast-Prefix-Based Allocation .....................4
      2.2. Administratively Scoped Allocation .........................5
      2.3. Static IANA Allocation .....................................6
      2.4. Dynamic Allocation .........................................6
   3. Multicast Address Assignment ....................................6
      3.1. Derived Assignment .........................................6
      3.2. SSM Assignment inside the Node .............................7
      3.3. Manually Configured Assignment .............................7
      3.4. Static IANA Assignment .....................................7
           3.4.1. Global IANA Assignment ..............................7
           3.4.2. Scope-Relative IANA Assignment ......................8
      3.5. Dynamic Assignments ........................................8
   4. Summary and Future Directions ...................................9
      4.1. Prefix Allocation ..........................................9
      4.2. Address Assignment ........................................10
      4.3. Future Actions ............................................11
   5. Acknowledgements ...............................................11
   6. IANA Considerations ............................................11
   7. Security Considerations ........................................11
   8. References .....................................................12
      8.1. Normative References ......................................12
      8.2. Informative References ....................................13

1. Introduction

1. はじめに

Good, up-to-date documentation of IP multicast is close to non-existent. Particularly, this is an issue with multicast address allocations (to networks and sites) and assignments (to hosts and applications). This problem is stressed by the fact that there exists confusing or misleading documentation on the subject [RFC2908]. The consequence is that those who wish to learn about IP multicast and how the addressing works do not get a clear view of the current situation.

IPマルチキャストの良い、最新のドキュメントが存在しないに近いです。特に、これは（ホストおよびアプリケーション）との割り当て（ネットワークやサイトへの）マルチキャストアドレスの割り当ての問題です。この問題は、件名[RFC2908]の混乱や誤解を招くような文書が存在するという事実によって強調されています。その結果は、ご希望の方は、IPマルチキャストとどのように対処する作品は、現在の状況のクリアな視界を得ることはありませんについて学習することです。

The aim of this document is to provide a brief overview of multicast addressing and allocation techniques. The term "addressing architecture" refers to the set of addressing mechanisms and methods in an informal manner.

このドキュメントの目的は、マルチキャストのアドレス指定と割り当て手法の概要を提供することです。「アーキテクチャに対処する」という用語は、非公式な方法で機構および方法をアドレッシングのセットを指します。

It is important to note that Source-Specific Multicast (SSM) [RFC4607] does not have these addressing problems because SSM group addresses have only local significance; hence, this document focuses on the Any Source Multicast (ASM) model.

SSMのグループアドレスにのみローカルな意味を持っているので、そのソース固有マルチキャスト（SSM）[RFC4607]はこれらのアドレッシングの問題を持っていません注意することが重要です。したがって、この文書は、任意のソースマルチキャスト（ASM）モデルに焦点を当てています。

This memo obsoletes and re-classifies RFC 2908 to Historic, and re-classifies RFCs 2776 and 2909 to Historic.

このメモは廃止と再分類のRFC 2908を歴史的に、およびRFC 2776および歴史的に2909年に再分類します。

1.1. Terminology: Allocation or Assignment

1.1. 用語：割り振りまたは割り当て

Almost all multicast documents and many other RFCs (such as DHCPv4 [RFC2131] and DHCPv6 [RFC3315]) have used the terms "address allocation" and "address assignment" interchangeably. However, the operator and address management communities use these terms for two conceptually different processes.

ほとんどすべてのマルチキャストドキュメント及び（例えばのDHCPv4 [RFC2131]とDHCPv6 [RFC3315]のような）多くの他のRFCは互換的に「アドレス割付」と「アドレス割り当て」という用語を使用しています。しかし、オペレータやアドレス管理コミュニティは、2つの概念的に異なるプロセスのためにこれらの用語を使用します。

In unicast operations, address allocations refer to leasing a large block of addresses from the Internet Assigned Numbers Authority (IANA) to a Regional Internet Registry (RIR), or from an RIR to a Local Internet Registry (LIR), possibly through a National Internet Registry (NIR). Address assignments, on the other hand, are the leases of smaller address blocks or even single addresses to the end-user sites or end-users themselves.

ユニキャスト動作では、アドレスの割り当ては、おそらく国立インターネットを介して、地域インターネットレジストリ（RIR）に、またはRIRからローカルインターネットレジストリ（LIR）にインターネット割り当て番号機関（IANA）からのアドレスの大きなブロックをリースを指しレジストリ（NIR）。アドレスの割り当ては、他の一方で、エンドユーザーのサイトやエンドユーザー自身に小さなアドレスブロックまたは単一のアドレスのリースです。

Therefore, in this memo, we will separate the two different functions: "allocation" describes how larger blocks of addresses are obtained by the network operators, and "assignment" describes how applications, nodes, or sets of nodes obtain a multicast address for their use.

「割り当て」は、アドレスの大きいブロックがネットワークオペレータによって得られる方法を説明し、「割り当て」は、アプリケーション、ノード、またはノードのセットは、それらのためのマルチキャストアドレスを取得する方法について説明します。したがって、このメモでは、我々は2つの異なる機能を分離しますつかいます。

2. Multicast Address Allocation

2.マルチキャストアドレスの割り当て

Multicast address allocation, i.e., how a network operator might be able to obtain a larger block of addresses, can be handled in a number of ways, as described below.

以下に説明するように、マルチキャストアドレス割り当ては、すなわち、ネットワークオペレータは、アドレスの大きなブロックを得ることができるかもしれませんどのように、いくつかの方法で扱うことができます。

Note that these are all only pertinent to ASM -- SSM requires no address block allocation because the group address has only local significance (however, we discuss the address assignment inside the node in Section 3.2).

これらは、ASMへのすべての唯一の適切であることに注意してください - グループアドレスのみがローカルな意味を持っているので、SSMは（ただし、我々は3.2節でノード内のアドレス割り当てを議論する）は、アドレスブロックの割り当てを必要としません。

2.1. Derived Allocation

2.1. 派生配分

Derived allocations take the unicast prefix or some other properties of the network (e.g., an autonomous system (AS) number) to determine unique multicast address allocations.

誘導された割り当ては、一意のマルチキャストアドレス割り当てを決定するために、ユニキャストプレフィックスまたはネットワーク（例えば、自律システム（AS）番号）のいくつかの他の特性を取ります。

2.1.1. GLOP Allocation

2.1.1. GLOP割り当て

GLOP address allocation [RFC3180] inserts the 16-bit public AS number in the middle of the IPv4 multicast prefix 233.0.0.0/8, so that each AS number can get a /24 worth of multicast addresses. While this is sufficient for multicast testing or small-scale use, it might not be sufficient in all cases for extensive multicast use.

数AS各マルチキャストアドレスの/ 24の価値を得ることができるようにGLOPアドレス割り当て[RFC3180]は、IPv4マルチキャストプレフィックス233.0.0.0/8の途中で数ように、16ビットのパブリックを挿入します。これは、マルチキャストテストまたは小規模な使用のためには十分であるが、それは大規模なマルチキャストの使用のため、すべての場合には十分ではないかもしれません。

A minor operational debugging issue with GLOP addresses is that the connection between the AS and the prefix is not apparent from the prefix when the AS number is greater than 255, but has to be calculated (e.g., as described in [RFC3180], AS 5662 maps to 233.22.30.0/24). A usage issue is that GLOP addresses are not tied to any prefix but to routing domains, so they cannot be used or calculated automatically.

GLOPアドレスを持つマイナーな操作のデバッグ問題がAS番号が255よりも大きいが、5662 AS、[RFC3180]で説明したように、例えば（計算しなければならないとき、ASとプレフィックスとの間の接続は、接頭辞から明らかではないということです233.22.30.0/24にマップ）。使い方の問題は、彼らが使用したり、自動的に計算することができないので、GLOPアドレスは、任意のプレフィックスになく、ルーティングドメインに縛られないということです。

GLOP mapping is not available with 4-byte AS numbers [RFC4893]. Unicast-prefix-based allocation or an IANA allocation from "AD-HOC Block III" (the previous so-called "EGLOP" (Extended GLOP) block) could be used instead, as needed.

GLOPマッピングは番号[RFC4893] AS 4バイトでは使用できません。必要に応じて、「AD-HOCブロックIII」（前いわゆる「EGLOP」（拡張GLOP）ブロック）からユニキャストプレフィックスベース割り当て又はIANA割り当てが、代わりに使用することができます。

The GLOP allocation algorithm has not been defined for IPv6 multicast because the unicast-prefix-based allocation (described below) addresses the same need in a simpler fashion.

（後述する）ユニキャストプレフィックスベース割り当ては単純な方法で同じ必要性に対処するためGLOP割り当てアルゴリズムは、IPv6マルチキャストのために定義されていません。

2.1.2. Unicast-Prefix-Based Allocation

2.1.2. ユニキャストプレフィックスベースの割り当て

RFC 3306 [RFC3306] describes a mechanism that embeds up to 64 high-order bits of an IPv6 unicast address in the prefix part of the IPv6 multicast address, leaving at least 32 bits of group-id space available after the prefix mapping.

RFC 3306 [RFC3306]はプレフィックスマッピングの後に利用可能なグループID空間の少なくとも32ビットを残して、IPv6マルチキャストアドレスのプレフィックス部分のIPv6ユニキャストアドレスの64上位ビットまで埋め込む機構が記載されています。

A similar IPv4 mapping is described in [RFC6034], but it provides a limited number of addresses (e.g., 1 per IPv4 /24 block).

同様のIPv4のマッピングは[RFC6034]に記載されているが、それはアドレス（例えば、IPv4の/ 24ブロック当たり1）の限定された数を提供します。

The IPv6 unicast-prefix-based allocations are an extremely useful way to allow each network operator, even each subnet, to obtain multicast addresses easily, through an easy computation. Further, as the IPv6 multicast header also includes the scope value [RFC4291], multicast groups of smaller scope can also be used with the same mapping.

IPv6のユニキャストプレフィックスベースの割り当ては、各ネットワークオペレータも各サブネットは、簡単な演算により、容易にマルチキャストアドレスを取得することを可能にする非常に有用な方法です。 IPv6マルチキャストヘッダはまた、スコープ値[RFC4291]を含むように、さらに、より小さな範囲のマルチキャストグループは、同じマッピングに使用することができます。

The IPv6 Embedded Rendezvous Point (RP) technique [RFC3956], used with Protocol Independent Multicast - Sparse Mode (PIM-SM), further leverages the unicast-prefix-based allocations, by embedding the unicast prefix and interface identifier of the PIM-SM RP in the prefix. This provides all the necessary information needed to the routing systems to run the group in either inter- or intra-domain operation. A difference from RFC 3306 is, however, that the hosts

スパースモード（PIM-SM）、さらに、PIM-SMのユニキャストプレフィクスとインタフェース識別子を埋め込むことにより、ユニキャストプレフィックスベースの割り当てを活用 - IPv6は、ランデブーポイント（RP）技術[RFC3956]は、プロトコル独立マルチキャストと共に使用エンベデッド接頭辞でRP。これは、どちらかの間またはドメイン内の操作でグループを実行するために、ルーティングシステムに必要なすべての必要な情報を提供します。 RFC 3306との違いは、しかし、あるホストこと

cannot calculate their "multicast prefix" automatically (as the prefix depends on the decisions of the operator setting up the RP), but instead require an assignment method.

（接頭辞がRPを設定するオペレータの意思決定に依存する）、自動的に「マルチキャスト接頭辞」を計算するが、代わりに割り当て方法を必要とすることはできません。

All the IPv6 unicast-prefix-based allocation techniques provide a sufficient amount of multicast address space for network operators.

すべてのIPv6ユニキャストプレフィックスベース割り当て技術は、ネットワークオペレータのためのマルチキャストアドレス空間の十分な量を提供します。

2.2. Administratively Scoped Allocation

2.2. 管理スコープの割り当て

Administratively scoped multicast address allocation [RFC2365] is provided by two different means: under 239.0.0.0/8 in IPv4 or by 4-bit encoding in the IPv6 multicast address prefix [RFC4291].

管理マルチキャストアドレス割り当て[RFC2365]をスコープ二つの異なる手段によって提供されたIPv4またはIPv6マルチキャストアドレスプレフィックス[RFC4291]の4ビットの符号化によって239.0.0.0/8下。

Since IPv6 administratively scoped allocations can be handled with unicast-prefix-based multicast addressing as described in Section 2.1.2, we'll only discuss IPv4 in this section.

IPv6の管理スコープの割り当ては、ユニキャストプレフィックスベースのマルチキャストは、2.1.2項で説明したようにアドレッシングで扱うことができるので、私たちは、このセクションではIPv4を説明します。

The IPv4 administratively scoped prefix 239.0.0.0/8 is further divided into Local Scope (239.255.0.0/16) and Organization Local Scope (239.192.0.0/14); other parts of the administrative scopes are either reserved for expansion or undefined [RFC2365]. However, RFC 2365 is ambiguous as to whether the enterprises or the IETF are allowed to expand the space.

IPv4が管理プレフィックス239.0.0.0/8は、さらにローカルスコープ（239.255.0.0/16）と組織ローカルスコープ（239.192.0.0/14）に分割されているスコープ。管理スコープの他の部分は、いずれかの膨張または未定義[RFC2365]のために予約されています。しかし、RFC 2365は、企業またはIETFの空間を拡大できるかどうかに関して曖昧です。

Topologies that act under a single administration can easily use the scoped multicast addresses for their internal groups. Groups that need to be shared between multiple routing domains (even if not propagated through the Internet) are more problematic and typically need an assignment of a global multicast address because their scope is undefined.

単回投与の下で行動するトポロジは、簡単に自分の内部のグループのスコープのマルチキャストアドレスを使用することができます。複数のルーティングドメイン間で共有される必要がある基が（インターネットを介して伝播しない場合であっても）より問題であり、その範囲が定義されていないため、一般的にグローバルマルチキャストアドレスの割り当てを必要とします。

There are a large number of multicast applications (such as "Norton Ghost") that are restricted either to a link or a site, and it is extremely undesirable to propagate them further (beyond the link or the site). Typically, many such applications have been given or have hijacked a static IANA address assignment. Given the fact that assignments to typically locally used applications come from the same range as global applications, implementing proper propagation limiting is challenging. Filtering would be easier if a separate, identifiable range would be used for such assignments in the future; this is an area of further future work.

そこのいずれかのリンクやサイトに制限されている（例えば、「ノートンゴースト」など）マルチキャストアプリケーションが多数あり、（リンクまたはサイトを超えて）、さらにそれらを伝播することは非常に望ましくありません。典型的には、このような多くのアプリケーションが与えられたまたは静的IANAアドレス割り当てをハイジャックしています。割り当てが一般的にローカルで使用するアプリケーションは、グローバル・アプリケーションと同じ範囲から来ているという事実を考えると、制限適切な伝播を実装することは困難です。別個の識別可能な範囲は、今後このような割り当てのために使用される場合、フィルタリングが容易であろう。これは今後の仕事の領域です。

There has also been work on a protocol to automatically discover multicast scope zones [RFC2776], but it has never been widely implemented or deployed.

そこにも自動的にマルチキャストスコープゾーンを発見するためのプロトコルでの作業[RFC2776]となっているが、それは広く実装されなかったり展開されたことがありません。

2.3. Static IANA Allocation

2.3. 静的IANAの割り当て

In some rare cases, organizations may have been able to obtain static multicast address allocations (of up to 256 addresses) directly from IANA. Typically, these have been meant as a block of static assignments to multicast applications, as described in Section 3.4.1. If another means of obtaining addresses is available, that approach is preferable.

いくつかのまれなケースでは、組織は、IANAから直接（最大256のアドレスの）静的マルチキャストアドレスの割り当てを得ることができたかもしれません。セクション3.4.1で説明したように、典型的には、これらは、マルチキャストアプリケーションに対する静的割り当てのブロックとして意図されています。アドレスを得るための別の手段が利用可能である場合、そのアプローチが好ましいです。

Especially for those operators that only have a 32-bit AS number and need IPv4 addresses, an IANA allocation from "AD-HOC Block III" (the previous so-called "EGLOP" block) is an option [RFC5771].

特にのみAS番号32ビットを有し、IPv4アドレスを必要とするオペレータのために、「AD-HOCブロックIII」（前いわゆる「EGLOP」ブロック）からIANA割り当てはオプション[RFC5771]です。

2.4. Dynamic Allocation

2.4. ダイナミックアロケーション

RFC 2908 [RFC2908] proposed three different layers of multicast address allocation and assignment, where layer 3 (inter-domain allocation) and layer 2 (intra-domain allocation) could be applicable here. The Multicast Address-Set Claim Protocol (MASC) [RFC2909] is an example of the former, and the Multicast Address Allocation Protocol (AAP) [MALLOC-AAP] (abandoned in 2000 due to lack of interest and technical problems) is an example of the latter.

RFC 2908 [RFC2908]はここで適用できるマルチキャストアドレスの割り当てと割り当て、レイヤ3（ドメイン間の割り当て）及びレイヤ2（ドメイン内の割り当て）の三つの異なる層を提案しています。マルチキャストアドレス-SETクレームプロトコル（MASC）[RFC2909]は前者の例であり、マルチキャストアドレス割り当てプロトコル（AAP）[MALLOC-AAP]（利息及び技術的な問題の不足のために2000年に放棄された）は一例であり、後者の。

Both of the proposed allocation protocols were quite complex, and have never been deployed or seriously implemented.

提案された割り当てプロトコルの両方が非常に複雑だったし、展開しないか、真剣に実装されたことはありません。

It can be concluded that dynamic multicast address allocation protocols provide no benefit beyond GLOP/unicast-prefix-based mechanisms and have been abandoned.

動的マルチキャストアドレス割当プロトコルはGLOP /ユニキャストプレフィックスベースのメカニズムを超えて何の利益を提供せず、放棄されたと結論付けることができます。

3. Multicast Address Assignment

3.マルチキャストアドレスの割り当て

There are a number of possible ways for an application, node, or set of nodes to learn a multicast address, as described below.

後述のようにマルチキャストアドレスを学習するアプリケーションのための可能な方法の数、ノードまたはノードのセットがあります。

Any IPv6 address assignment method should be aware of the guidelines for the assignment of group-IDs for IPv6 multicast addresses [RFC3307].

任意のIPv6アドレス割当方法は、IPv6マルチキャストアドレス[RFC3307]のためのグループIDの割り当てのためのガイドラインを認識しなければなりません。

3.1. Derived Assignment

3.1. 派生割り当て

There are significantly fewer options for derived address assignment compared to derived allocation. Derived multicast assignment has only been specified for IPv6 link-scoped multicast [RFC4489], where the EUI64 is embedded in the multicast address, providing a node with unique multicast addresses for link-local ASM communications.

派生割り当てに比べ派生アドレス割り当てのための非常に少ないのオプションがあります。誘導されたマルチキャスト割り当てのみリンクローカルASM通信のための一意のマルチキャストアドレスを持つノードを提供する、EUI64は、マルチキャストアドレスに埋め込まれているIPv6リンクスコープマルチキャスト[RFC4489]に指定されています。

3.2. SSM Assignment inside the Node

3.2. ノード内のSSMの割り当て

While SSM multicast addresses have only local (to the node) significance, there is still a minor issue on how to assign the addresses between the applications running on the same IP address.

SSMマルチキャストアドレスは、ローカル（ノード）の意味を有するが、同じIPアドレス上で実行されるアプリケーション間でアドレスを割り当てる方法の軽微な問題が依然として存在しています。

This assignment is not considered to be a problem, because typically the addresses for these applications are selected manually or statically, but if done using an Application Programming Interface (API), the API could check that the addresses do not conflict prior to assigning one.

この割り当ては、これらのアプリケーションのために、通常のアドレスは、手動または静的に選択されているので、問題ないと考えられるが、アプリケーションプログラミングインタフェース（API）を使用して行う場合は、APIは、アドレスが1を割り当てる前に競合しないことを確認することができます。

3.3. Manually Configured Assignment

3.3. 手動で設定した割り当て

With manually configured assignment, a network operator who has a multicast address prefix assigns the multicast group addresses to the requesting nodes using a manual process.

手動で設定割り当てと、マルチキャストアドレスプレフィックスを有するネットワークオペレータは、手動プロセスを使用して、要求元のノードにマルチキャストグループアドレスを割り当てます。

Typically, the user or administrator that wants to use a multicast address for a particular application requests an address from the network operator using phone, email, or similar means, and the network operator provides the user with a multicast address. Then the user/administrator of the node or application manually configures the application to use the assigned multicast address.

典型的には、特定のアプリケーションのためのマルチキャストアドレスを使用したいユーザーまたは管理者は、電話、電子メール、または同様の手段を使用して、ネットワークオペレータからアドレスを要求し、ネットワークオペレータは、マルチキャストアドレスをユーザに提供します。その後、ノードまたはアプリケーションのユーザー/管理者が手動で割り当てられたマルチキャストアドレスを使用するようにアプリケーションを構成します。

This is a relatively simple process; it has been sufficient for certain applications that require manual configuration in any case, or that cannot or do not want to justify a static IANA assignment. The manual assignment works when the number of participants in a group is small, as each participant has to be manually configured.

これは、比較的単純なプロセスです。それはどのような場合には手動設定を必要とする特定の用途のために十分なされている、またはそれは、静的またはIANAの割り当てを正当化したくないことはできません。各参加者が手動で設定しなければならないように、グループ内の参加者の数が少ない場合、手動割り当てが働きます。

This is the most commonly used technique when the multicast application does not have a static IANA assignment.

これは、マルチキャストアプリケーションは、静的IANAの割り当てを持っていない最も一般的に使用される技術です。

3.4. Static IANA Assignment

3.4. 静的IANAの割り当て

In contrast to manually configured assignment, as described above, static IANA assignment refers to getting an assignment for the particular application directly from IANA. There are two main forms of IANA assignment: global and scope-relative. Guidelines for IANA are described in [RFC5771].

上記のように、手動で割り当てを構成とは対照的に、静的IANA割り当てはIANAから直接、特定の用途のための割当を得ることをいいます。グローバルとスコープ相対：IANAの割り当てには主に2つの形式があります。 IANAのためのガイドラインは、[RFC5771]に記載されています。

3.4.1. Global IANA Assignment

3.4.1. グローバルIANAの割り当て

Globally unique address assignment is seen as lucrative because it's the simplest approach for application developers, since they can then hard-code the multicast address. Hard-coding requires no lease of the usable multicast address, and likewise the client applications do not need to perform any kind of service discovery (but depend on hard-coded addresses). However, there is an architectural scaling problem with this approach, as it encourages a "land-grab" of the limited multicast address space.

彼らはその後、ハードコードマルチキャストアドレスをすることができるので、それは、アプリケーション開発者のための最も簡単な方法ですので、グローバルにユニークなアドレス割り当ては収益性の高いと見られています。ハードコーディングは、使用可能なマルチキャストアドレスのないリースを必要とせず、同様にクライアントアプリケーションは、サービス・ディスカバリのいずれかの種類を実行する必要があります（ただし、ハードコードされたアドレスに依存）しません。それは限られたマルチキャストアドレス空間の「土地グラブ」を奨励しかし、このアプローチの建築スケーリング問題があります。

3.4.2. Scope-Relative IANA Assignment

3.4.2. スコープ相対IANAの割り当て

IANA also assigns numbers as an integer offset from the highest address in each IPv4 administrative scope, as described in [RFC2365]. For example, the SLPv2 discovery scope-relative offset is "2", so the SLPv2 discovery address within IPv4 Local-Scope (239.255.0.0/16) is "239.255.255.253"; within the IPv4 Organization Local-Scope (239.192.0.0/14), it is "239.195.255.253"; and so on.

[RFC2365]で説明されるようにIANAはまた、各IPv4の管理範囲内の最高アドレスからのオフセットを整数として番号を割り当てます。例えば、オフセットSLPv2の検出スコープ相対が「2」であるので、IPv4のローカルスコープ内SLPv2の検出アドレス（239.255.0.0/16）が「239.255.255.253」です。 IPv4の組織ローカルスコープ（239.192.0.0/14）内で、それが「239.195.255.253」です。等々。

Similar scope-relative assignments also exist with IPv6 [RFC2375]. As IPv6 multicast addresses have much more flexible scoping, scope-relative assignments are also applicable to global scopes. The assignment policies are described in [RFC3307].

同様のスコープ相対割り当てものIPv6 [RFC2375]で存在します。 IPv6マルチキャストアドレスは、はるかに柔軟なスコープを持っているように、スコープ相対割り当ては、グローバルスコープに適用可能です。割り当てポリシーは、[RFC3307]に記載されています。

3.5. Dynamic Assignments

3.5. 動的な割り当て

Layer 1 as defined in RFC 2908 [RFC2908] described dynamic assignment from Multicast Address Allocation Servers (MAAS) to applications and nodes, with the Multicast Address Dynamic Client Allocation Protocol (MADCAP) [RFC2730] as an example. Since then, other mechanisms have also been proposed (e.g., DHCPv6 assignment [MCAST-DHCPv6]), but these have not gained traction.

RFC 2908 [RFC2908]で定義されるように、レイヤ1は、一例として、マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）[RFC2730]と、アプリケーションノードへのマルチキャストアドレス割り当てサーバ（MAAS）からの動的割り当てを記載しました。それ以来、他のメカニズムも（例えば、DHCPv6の割り当て[MCAST-のDHCPv6]）が提案されているが、これらは牽引力を得ていません。

It would be rather straightforward to deploy a dynamic assignment protocol that would lease group addresses based on a multicast prefix to applications wishing to use multicast. However, only few have implemented MADCAP (i.e., it is not significantly deployed). It is not clear if the sparse deployment is due to a lack of need for the protocol. Moreover, it is not clear how widely, for example, the APIs for communication between the multicast application and the MADCAP client operating at the host have been implemented [RFC2771].

マルチキャストを使用したいアプリケーションへのマルチキャストプレフィックスに基づいてグループアドレスをリースう動的に割り当てるプロトコルを展開する、むしろ簡単なことでしょう。しかし、わずか数はMADCAP（すなわち、それは非常に配備されていない）を実装しました。まばらな展開は、プロトコルの必要性の欠如によるものであるかどうかは明らかではありません。また、それは明らかではないがどのように広く、例えば、ホストで動作するマルチキャストアプリケーションとMADCAPクライアント間の通信のためのAPIは、[RFC2771]を実装されています。

An entirely different approach is the Session Announcement Protocol (SAP) [RFC2974]. In addition to advertising global multicast sessions, the protocol also has associated ranges of addresses for both IPv4 and IPv6 that can be used by SAP-aware applications to create new groups and new group addresses. Creating a session (and obtaining an address) is a rather tedious process, which is why it isn't done all that often. It is also worth noting that the IPv6 SAP address is unroutable in the inter-domain multicast.

全く異なるアプローチは、セッションアナウンスメントプロトコル（SAP）[RFC2974]です。広告グローバルマルチキャストセッションに加えて、プロトコルはまた、新しいグループと新しいグループアドレスを作成するために、SAP対応のアプリケーションで使用することができ、IPv4とIPv6の両方のアドレスの範囲が関連付けられています。セッションの作成（とアドレスを取得することは）それはすべてが頻繁に行われていない理由である、かなり退屈なプロセスです。それはまたのIPv6 SAPアドレスは、ドメイン間のマルチキャストルーティング不可能であることは注目に値します。

Conclusions about dynamic assignment protocols are that:

動的な割り当てプロトコルについての結論は、以下のとおりです。

1. multicast is not significantly attractive in the first place,

1.マルチキャストは、最初の場所でかなり魅力的ではありません

2. most applications have a static IANA assignment and thus require no dynamic or manual assignment,

2.ほとんどのアプリケーションは、静的IANA割り当てを有し、したがって、動的なまたは手動割り当てを必要としません

3. those applications that cannot be easily satisfied with IANA or manual assignment (i.e., where dynamic assignment would be desirable) are rather marginal, or

3.（動的割り当てが望ましいであろう、すなわち、）IANAまたは手動割り当てで容易に満たすことができないこれらのアプリケーションは、かなり限界である、又は

4. there are other reasons why dynamic assignments are not seen as a useful approach (for example, issues related to service discovery/rendezvous).

4.（サービス発見/ランデブーに関連例えば、問題）その他の動的割り当てが有用なアプローチと見られていない理由があります。

In consequence, more work on rendezvous/service discovery would be needed to make dynamic assignments more useful.

その結果、ランデブー/サービスの発見に多くの作業は、動的な割り当ては、より便利にするために必要とされるであろう。

4. Summary and Future Directions

4.まとめと今後の方向性

This section summarizes the mechanisms and analysis discussed in this memo, and presents some potential future directions.

このセクションでは、このメモで説明するメカニズムと分析をまとめたものであり、いくつかの潜在的な将来の方向性を提示します。

4.1. Prefix Allocation

4.1. プレフィックスの割り当て

A summary of prefix allocation methods for ASM is shown in Figure 1.

ASMのプレフィックス割当て方法の概要は図1に示されています。

       +-------+--------------------------------+--------+--------+
       | Sect. | Prefix allocation method       | IPv4   | IPv6   |
       +-------+--------------------------------+--------+--------+
       | 2.1.1 | Derived: GLOP                  |  Yes   | NoNeed*|
       | 2.1.2 | Derived: Unicast-prefix-based  |   No   |  Yes   |
       |  2.2  | Administratively scoped        |  Yes   | NoNeed*|
       |  2.3  | Static IANA allocation         |  Yes** |   No   |
       |  2.4  | Dynamic allocation protocols   |   No   |   No   |
       +-------+--------------------------------+--------+--------+
       *  = the need satisfied by IPv6 unicast-prefix-based allocation
       ** = mainly using the AD-HOC block III (formerly called "EGLOP")

Figure 1

図1

o Only ASM is affected by the assignment/allocation issues.

OのみASMは、割り当て/割り当ての問題の影響を受けています。

o With IPv4, GLOP allocations provide a sufficient IPv4 multicast allocation mechanism for those that have a 16-bit AS number. IPv4 unicast-prefix-based allocation offers some addresses. IANA is also allocating from the AD-HOC block III (formerly called "EGLOP"), especially with 32-bit AS number holders in mind. Administratively scoped allocations provide the opportunity for internal IPv4 allocations.

IPv4のとO、GLOP割り当てはAS番号16ビットを有するもののために十分なIPv4マルチキャスト割り当てメカニズムを提供します。 IPv4ユニキャストプレフィックスベースの割り当ては、いくつかのアドレスを提供しています。 IANAは、特に念頭に置いて数ホルダAS 32ビットで、（以前の「EGLOP」と呼ばれる）AD-HOCブロックIIIから割り当てされます。管理スコープの割り当ては内部のIPv4の割り当てのための機会を提供します。

o With IPv6, unicast-prefix-based addresses and the derivatives provide a good allocation strategy, and this also works for scoped multicast addresses.

IPv6でO、ユニキャストプレフィックスベースアドレスおよび誘導体は、優れたアロケーション戦略を提供し、これはまた、スコープのマルチキャストアドレスのために動作します。

o Dynamic allocations are too complex and unnecessary a mechanism.

Oダイナミックアロケーションは、メカニズムは複雑すぎると不必要です。

4.2. Address Assignment

4.2. アドレスの割り当て

A summary of address assignment methods is shown in Figure 2.

アドレス割り当て方法の概要は、図2に示されています。

      +--------+--------------------------------+----------+----------+
      | Sect.  | Address assignment method      | IPv4     | IPv6     |
      +--------+--------------------------------+----------+----------+
      |  3.1   | Derived: link-scope addresses  |  No      |   Yes    |
      |  3.2   | SSM (inside the node)          |  Yes     |   Yes    |
      |  3.3   | Manual assignment              |  Yes     |   Yes    |
      |  3.4.1 | Global IANA/RIR assignment     |LastResort|LastResort|
      |  3.4.2 | Scope-relative IANA assignment |  Yes     |   Yes    |
      |  3.5   | Dynamic assignment protocols   |  Yes     |   Yes    |
      +--------+--------------------------------+----------+----------+

Figure 2

図2

o Manually configured assignment is typical today, and works to a sufficient degree in smaller scale.

Oを手動で設定した割り当ては、今日の典型的なものであり、より小さな規模で十分に動作します。

o Global IANA assignment has been done extensively in the past. Scope-relative IANA assignment is acceptable, but the size of the pool is not very high. Inter-domain routing of IPv6 IANA-assigned prefixes is likely going to be challenging, and as a result that approach is not very appealing.

OグローバルIANAの割り当ては、過去に広く行われてきました。スコープ相対IANA割り当ては許容可能であるが、プールの大きさはあまり高くありません。 IPv6のIANAによって割り当てられたプレフィックスのドメイン間ルーティングは、おそらく挑戦になるだろうし、その結果そのアプローチは非常に魅力的ではありません。

o Dynamic assignment, e.g., MADCAP, has been implemented, but there is no wide deployment. Therefore, either there are other gaps in the multicast architecture, or there is no sufficient demand for it in the first place when manual and static IANA assignments are available. Assignments using SAP also exist but are not common; global SAP assignment is infeasible with IPv6.

Oダイナミックな割り当ては、例えば、MADCAPは、実装されていますが、何の広い展開はありません。したがって、いずれかのマルチキャスト・アーキテクチャの他のギャップが存在する、または手動および静的IANA割り当てが利用可能である最初の場所でそれのための十分な需要がありません。 SAPを使用して割り当ても存在するが、一般的ではありません。グローバルなSAPの割り当ては、IPv6で実行不可能です。

o Derived assignments are only applicable in a fringe case of link-scoped multicast.

O派生割り当ては、リンクスコープのマルチキャストのフリンジ場合にのみ適用されます。

4.3. Future Actions

4.3. 今後のアクション

o Multicast address discovery/"rendezvous" needs to be analyzed at more length, and an adequate solution provided. See [ADDRDISC-PROB] and [MSA-REQ] for more information.

Oマルチキャストアドレス発見/「ランデブー」は、より長さで分析する必要があり、十分な溶液が得られました。詳細については、[ADDRDISC-PROB]と[MSA-REQ]を参照してください。

o The IETF should consider whether to specify more ranges of the IPv4 administratively scoped address space for static allocation for applications that should not be routed over the Internet (such as backup software, etc. -- so that these wouldn't need to use global addresses, which should never leak in any case).

これらは、グローバルを使用する必要がないように - IETF oをなどバックアップソフトウェアなど、インターネット経由でルーティングされるべきではないアプリケーション（のための静的割り当てのIPv4管理スコープのアドレス空間の複数の範囲を指定するかどうかを検討すべきですどのような場合に漏れることはありませんアドレス、）。

o The IETF should consider its static IANA allocations policy, e.g., "locking it down" to a stricter policy (like "IETF Consensus") and looking at developing the discovery/rendezvous functions, if necessary.

O IETFは、（「IETFコンセンサス」のような）より厳しいポリシーに「それをロックダウン」し、必要であれば、発見/ランデブ機能を開発見て、例えばその静的IANA割り当てポリシーを、検討すべきです。

5. Acknowledgements

5.謝辞

Tutoring a couple of multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN], convinced the author that updated multicast address assignment/allocation documentation is needed.

マルチキャスト関連の論文、KAARLE Ritvanen [RITVANEN]による、最新のカップルを指導、更新されたマルチキャストアドレスの割り当て/割り当てのドキュメントが必要とされている著者を確信させました。

Multicast address allocations/assignments were discussed at the MBONED WG session at IETF 59 [MBONED-IETF59].

マルチキャストアドレスの割り当て/割り当てはIETF 59 [MBONED-IETF59]でMBONED WGセッションで議論されました。

Dave Thaler, James Lingard, and Beau Williamson provided useful feedback for the preliminary version of this memo. Myung-Ki Shin, Jerome Durand, John Kristoff, Dave Price, Spencer Dawkins, and Alfred Hoenes also suggested improvements.

デーブターラー、ジェームズ・リンガード、およびボー・ウィリアムソンは、このメモの暫定版のための有用なフィードバックを提供します。ミョン-KI新、ジェロームデュラン、ジョンKristoff、デイブ価格、スペンサードーキンスとアルフレッドHoenesも改善を示唆しました。

6. IANA Considerations

6. IANAの考慮事項

IANA considerations in Sections 4.1.1 and 4.1.2 of obsoleted and now Historic [RFC2908] were never implemented in the IANA registry.

セクション4.1.1および廃止され、現在は歴史的な[RFC2908]の4.1.2でIANAの考慮事項は、IANAレジストリに実装されませんでした。

7. Security Considerations

7.セキュリティの考慮事項

This memo only describes different approaches to allocating and assigning multicast addresses, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo.

このメモは、マルチキャストアドレスを割り当て、割り当てに異なるアプローチを記載するのみであり、これにはセキュリティ問題を有していません。前述のプロトコルのセキュリティ分析は、このメモの範囲外です。

Obviously, the dynamic assignment protocols in particular are inherently vulnerable to resource exhaustion attacks, as discussed, e.g., in [RFC2730].

例えば、[RFC2730]で説明したように、明らかに、特に動的割当プロトコルは、消耗攻撃をリソースに本質的に脆弱です。

8. References

8.参照文献

8.1. Normative References

8.1. 引用規格

[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.

[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。

[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.

[RFC3180]マイヤー、D.およびP. Lothberg、 "8分の233にアドレッシングGLOP"、BCP 53、RFC 3180、2001年9月。

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

[RFC3306]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。

[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.

[RFC3307]ハーバーマン、B.、 "IPv6マルチキャストアドレスの割り当てに関するガイドライン"、RFC 3307、2002年8月。

[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.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。

[RFC4489] Park, J-S., Shin, M-K., and H-J. Kim, "A Method for Generating Link-Scoped IPv6 Multicast Addresses", RFC 4489, April 2006.

[RFC4489]パーク、J-S。、シン、M-K。、およびH-J。キム、RFC 4489、2006年4月「の生成リンクスコープのIPv6マルチキャストアドレスのための方法」。

[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.

[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.

[RFC5771]綿、M.、Vegoda、L.、およびD.マイヤー、 "IPv4マルチキャストアドレス割り当てのためのIANAガイドライン"、BCP 51、RFC 5771、2010年3月。

[RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast Addresses", RFC 6034, October 2010.

[RFC6034]ターラー、D.、 "ユニキャストプレフィックスベースのIPv4マルチキャストアドレス"、RFC 6034、2010年10月。

8.2. Informative References

8.2. 参考文献

[ADDRDISC-PROB] Savola, P., "Lightweight Multicast Address Discovery Problem Space", Work in Progress, March 2006.

[ADDRDISC-PROB] Savola、P.、 "軽量マルチキャストアドレスディスカバリー問題空間"、進歩、2006年3月での作業。

[MALLOC-AAP] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in Progress, June 2000.

[MALLOC-AAP]ハンドレー、M.およびS.ハンナ、 "マルチキャストアドレス割り当てプロトコル（AAP）"、進歩、2000年6月ワーク。

[MBONED-IETF59] "MBONED WG session at IETF59", <http://www.ietf.org/proceedings/04mar/172.htm>.

[MBONED-IETF59 "IETF59でMBONED WGセッション"、<http://www.ietf.org/proceedings/04mar/172.htm>。

[MCAST-DHCPv6] Durand, J., "IPv6 multicast address assignment with DHCPv6", Work in Progress, February 2005.

[MCAST-のDHCPv6]デュラン、J.、 "DHCPv6のとIPv6マルチキャストアドレスの割り当て"、進歩、2005年2月に働いています。

[MSA-REQ] Asaeda, H. and V. Roca, "Requirements for IP Multicast Session Announcement", Work in Progress, March 2010.

[MSA-REQ] Asaeda、H.およびV.ロカ、 "IPマルチキャストセッションの発表のための要件"、進歩、2010年3月に作業。

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。

[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.

[RFC2375] HindenとR.とS.デアリング、 "IPv6のマルチキャストアドレスの割り当て"、RFC 2375、1998年7月。

[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

[RFC2730]ハンナ、S.、パテル、B.、およびM.シャー、 "マルチキャストアドレス動的クライアント割り当てプロトコル（MADCAP）"、RFC 2730、1999年12月。

[RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation", RFC 2771, February 2000.

[RFC2771]フィンレイソン、R.、 "マルチキャストアドレスの割り当てのための抽象API"、RFC 2771、2000年2月。

[RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", RFC 2776, February 2000.

[RFC2776]ハンドレー、M.、ターラー、D.、およびR. Kermode、 "マルチキャストスコープゾーン発表プロトコル（MZAP）"、RFC 2776、2000年2月。

[RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.

[RFC2908]ターラー、D.、ハンドリー、M.、およびD. Estrin、 "インターネットマルチキャストアドレス配分アーキテクチャ"、RFC 2908、2000年9月。

[RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., Kumar, S., and D. Thaler, "The Multicast Address-Set Claim (MASC) Protocol", RFC 2909, September 2000.

[RFC2909] Radoslavov、P.、Estrin、D.、ゴヴィンダン、R.、ハンドレー、M.、クマー、S.、およびD.ターレル、 "マルチキャストアドレスセットクレーム（MASC）プロトコル"、RFC 2909、9月2000。

[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.

[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。

[RFC3315] Droms, R., Ed., 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.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。

[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.

[RFC4893] Vohra著、Q.およびE.チェン、 "ナンバースペースAS 4オクテットのためのBGPのサポート"、RFC 4893、2007年5月。

[RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.

[RITVANEN] Ritvanen、K.、 "マルチキャストルーティングおよびアドレス指定"、HUT報告書、インターネットワーキングセミナー、2004年5月、<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>。

Author's Address

著者のアドレス

Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland

ペッカSavola CSC - 科学計算株式会社エスポー、フィンランド

EMail: psavola@funet.fi

メールアドレス：psavola@funet.fi