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

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

[要約] RFC 6308は、インターネットのマルチキャストアドレッシングアーキテクチャの概要を提供しています。このRFCの目的は、マルチキャスト通信のアドレッシングに関する基本的な理解を提供し、インターネットのマルチキャストアプリケーションの開発とデプロイメントを支援することです。

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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6308で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

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を歴史的に廃止および再分類し、RFCS 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.

ほとんどすべてのマルチキャストドキュメントおよび他の多くのRFC（DHCPV4 [RFC2131]やDHCPV6 [RFC3315]など）は、「アドレス割り当て」と「アドレス割り当て」という用語を互換性がありました。ただし、オペレーターと住所管理コミュニティは、これらの用語を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.

ユニキャストの操作では、アドレスの割り当てでは、インターネットに割り当てられた数字の権限（IANA）から地域インターネットレジストリ（RIR）に、またはRIRからローカルインターネットレジストリ（LIR）に、おそらく全国的なインターネットを介して、大きな住所をリースすることを指します。レジストリ（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.

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を超えるが、計算する必要がある場合、接頭辞からは明らかではないことです（たとえば、[RFC3180]、AS 5662で説明する必要があります。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マッピングは、数字として4バイトでは使用できません[RFC4893]。必要に応じて、ユニキャスト-Prefixベースの割り当てまたは「アドホックブロックIII」（以前のいわゆる「エグロップ」（拡張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.

Unicast-Prefixベースの割り当て（以下で説明）が同じニーズに簡単に対処するため、GLOP割り当てアルゴリズムはIPv6マルチキャストでは定義されていません。

2.1.2. Unicast-Prefix-Based Allocation

2.1.2. Unicast-Prefixベースの割り当て

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]は、IPv6マルチキャストアドレスのプレフィックス部分に最大64の高次ビットのIPv6ユニキャストアドレスを埋め込むメカニズムを説明し、プレフィックスマッピング後に少なくとも32ビットのグループIDスペースを利用できます。

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 Unicast-Prefixベースの割り当ては、各サブネットであっても、各サブネットでさえ、簡単な計算を通じてマルチキャストアドレスを簡単に取得できるようにするための非常に便利な方法です。さらに、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 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.

IPv6埋め込みランデブーポイント（RP）技術[RFC3956]は、プロトコル独立したマルチキャスト - スパースモード（PIM-SM）で使用され、PIM-SMSMSMのUnicastプレフィックスと界面識別子を埋め込むことにより、ユニキャスト-Prefixベースの割り当てをさらに活用します。プレフィックスのRP。これにより、ルーティングシステムに必要なすべての情報が、ドメイン内または領域内操作でグループを実行するために必要なすべての情報を提供します。ただし、RFC 3306との違いは、ホストが「マルチキャストプレフィックス」を自動的に計算できないことです（プレフィックスはRPをセットアップするオペレーターの決定に依存するため）。代わりに割り当て方法が必要です。

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

すべてのIPv6 Unicast-Prefixベースの割り当て手法は、ネットワークオペレーターに十分な量のマルチキャストアドレススペースを提供します。

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の239.0.0.0/8未満、またはIPv6マルチキャストアドレスプレフィックス[RFC4291]での4ビットエンコードによって2つの異なる平均によって提供されます。

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で説明されているように、Unicast-Prefixベースのマルチキャストアドレス指定で管理的にスコープ割り当てを処理できるため、このセクションの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.

リンクまたはサイトに制限されている多数のマルチキャストアプリケーション（「Norton Ghost」など）があり、それらをさらに伝播することは非常に望ましくありません（リンクまたはサイトを超えて）。通常、そのようなアプリケーションの多くは、静的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].

特に、数として32ビットのみを持ち、IPv4アドレスを必要とする演算子にとって、「アドホックブロックIII」（以前のいわゆる「エグロップ」ブロック）からの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つの異なる層を提案しました。ここでレイヤー3（ドメイン間割り当て）とレイヤー2（ドメイン内割り当て）をここで適用できます。マルチキャストアドレスセットクレームプロトコル（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/Unicast-Prefixベースのメカニズムを超えて利益をもたらさず、放棄されていると結論付けることができます。

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.

派生した割り当てと比較して、派生アドレス割り当てのオプションは大幅に少ない。派生マルチキャストの割り当ては、IPv6リンクスコープマルチキャスト[RFC4489]に対してのみ指定されています。EUI64はマルチキャストアドレスに埋め込まれており、リンクローカルASM通信用の一意のマルチキャストアドレスを備えたノードを提供します。

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.

IANAは、[RFC2365]に記載されているように、各IPv4管理スコープの最高のアドレスから整数オフセットとして番号を割り当てます。たとえば、SLPV2ディスカバリースコープ相関オフセットは「2」であるため、IPv4ローカルスコープ内のSLPV2ディスカバリーアドレス（239.255.0.0/16）は「239.255.255.253」です。IPv4組織Local-Scope（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は、マルチキャストアドレス割り当てサーバー（MAAS）からアプリケーションおよびノードへの動的割り当てを説明し、マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）[RFC2730]を例として説明しました。それ以来、他のメカニズムも提案されています（例：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.

o IPv4を使用すると、GLOP割り当ては、16ビットの数を持っている人に十分なIPv4マルチキャスト割り当てメカニズムを提供します。IPv4 Unicast-Prefixベースの割り当ては、いくつかのアドレスを提供します。IANAはまた、アドホックブロックIII（以前は「Eglop」と呼ばれていた）から割り当てています。管理上スコープ割り当ては、内部IPv4割り当ての機会を提供します。

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

o IPv6を使用すると、Unicast-Prefixベースのアドレスとデリバティブが優れた割り当て戦略を提供し、これはスコープされたマルチキャストアドレスでも機能します。

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などの動的な割り当てが実装されていますが、幅広い展開はありません。したがって、マルチキャストアーキテクチャには他のギャップがあります。または、手動INAおよび静的IANAの割り当てが利用可能な場合、そもそも十分な需要がありません。SAPを使用した割り当ても存在しますが、一般的ではありません。IPv6では、グローバルSAPの割り当ては実行不可能です。

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 マルチキャストアドレスの発見/「rendezvous」をより長さで分析する必要があり、適切なソリューションを提供する必要があります。詳細については、[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).

o IETFは、インターネットを介してルーティングしてはならないアプリケーション（バックアップソフトウェアなど）の静的割り当てのために、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は、静的IANAの割り当てポリシーを考慮する必要があります。たとえば、「ITのロックダウン」（「IETFコンセンサス」など）に「ロックダウン」し、必要に応じて発見/ランデブー関数の開発を検討する必要があります。

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-IITF59]の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.

Dave Thaler、James Lingard、およびBeau Williamsonは、このメモの予備バージョンに有用なフィードバックを提供しました。Myung-ki Shin、Jerome Durand、John Kristoff、Dave Price、Spencer Dawkins、およびAlfred 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.

廃止された現在の歴史的[RFC2908]のセクション4.1.1および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] Meyer、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] Meyer、D。およびP. Lothberg、「233/8のGlopアドレス指定」、BCP 53、RFC 3180、2001年9月。

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

[RFC3306] Haberman、B。およびD. Thaler、「Unicast-PrefixベースのIPv6マルチキャストアドレス」、RFC 3306、2002年8月。

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

[RFC3307] Haberman、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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（RP）アドレスを埋め込む」、RFC 3956、2004年11月。

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

[RFC4291] Hinden、R。およびS. Deering、「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] Park、J-S。、Shin、M-K。、およびH-J。キム、「リンクスコープ付きIPv6マルチキャストアドレスを生成する方法」、RFC 4489、2006年4月。

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

[RFC4607] Holbrook、H。およびB. Cain、「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] Cotton、M.、Vegoda、L。、およびD. Meyer、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 5771、2010年3月。

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

[RFC6034] Thaler、D。、「Unicast-Prefixベースの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] Handley、M。and S. Hanna、「マルチキャストアドレス割り当てプロトコル（AAP）」、2000年6月の作業。

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

[mboned-ietf59] "mboned wg session at ietf59"、<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] Durand、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. Roca、「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. Deering、「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] Hanna、S.、Patel、B。、およびM. Shah、「マルチキャストアドレスダイナミッククライアント割り当てプロトコル（MADCAP）」、RFC 2730、1999年12月。

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

[RFC2771] Finlayson、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] Handley、M.、Thaler、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] Thaler、D.、Handley、M。、およびD. Estrin、「The Internet Multicast Address Arlocation Architecture」、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.、Govindan、R.、Handley、M.、Kumar、S.、およびD. Thaler、「マルチキャストアドレスセットクレーム（MASC）プロトコル」、RFC 2909、9月2000。

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

[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、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. Chen、「Number Spaceとしての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 Report、InternetWorkingのセミナー、2004年5月、<http://www.tml.hut.fi/studies/t-10.551/2004/papers/>。

Author's Address

著者の連絡先

Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland

Pekka Savola CSC -Scientific Computing Ltd. Espoo Finland

   EMail: psavola@funet.fi