RFC2365 日本語訳
2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. (Format: TXT=17770 bytes) (Also BCP0023) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Meyer Request for Comments: 2365 University of Oregon BCP: 23 July 1998 Category: Best Current Practice
コメントを求めるワーキンググループD.マイヤー要求をネットワークでつないでください: 2365オレゴン大学BCP: 1998年7月23日のカテゴリ: 最も良い現在の習慣
Administratively Scoped IP Multicast
行政上見られたIPマルチキャスト
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
1. Abstract
1. 要約
This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes.
このドキュメントが範囲になるように「行政上見られたIPv4マルチキャストスペース」を定義する、239.0、.0、.0、239.255 .255 .255。 さらに、それはAdministratively Scoped IP Multicastの実装のために簡単な意味論について説明します。 最終的に、それはIPv6マルチキャストアドレスのクラス[RFC1884]とIPv4マルチキャストアドレスのクラスの間にマッピングを提供します。
This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
このメモはインターネット・エンジニアリング・タスク・フォースのOperationsとManagement AreaのMBONE Deployment作業部会(MBONED)の製品です。 コメント to <mboned@ns.uoregon.edu を提出してください、gt;、または、作者。
2. Acknowledgments
2. 承認
Much of this memo is taken from "Administratively Scoped IP Multicast", Van Jacobson and Steve Deering, presented at the 30th IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and Dave Thaler have also provided insightful comments on earlier versions of this document.
第30IETF、トロント(カナダ)で紹介された「行政上見られたIPマルチキャスト」、ヴァン・ジェーコブソン、およびスティーブ・デアリングからこのメモの多くを取ります、1994年7月25日。 また、スティーブCasner、マーク・ハンドレー、およびデーヴThalerはこのドキュメントの以前のバージョンの洞察に満ちたコメントを提供しました。
3. Introduction
3. 序論
Most current IP multicast implementations achieve some level of scoping by using the TTL field in the IP header. Typical MBONE (Multicast Backbone) usage has been to engineer TTL thresholds that confine traffic to some administratively defined topological region. The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL is greater than the threshold.
ほとんどの現在のIPマルチキャスト実装が、IPヘッダーのTTL分野を使用することによって、何らかのレベルを見ることを実現します。 典型的なMBONE(マルチキャストBackbone)用法はトラフィックを何らかの行政上定義された位相的な領域に制限するTTL敷居を設計することです。 構成されたTTL敷居とのインタフェースへの基本的な推進規則はTTLのままで残っているのに敷居ほどすばらしくない場合パケットがインタフェースの向こう側に進められないということです。
Meyer Best Current Practice [Page 1] RFC 2365 Administratively Scoped IP Multicast July 1998
IPマルチキャスト1998年7月に行政上見られたマイヤー最も良い現在の習慣[1ページ]RFC2365
TTL scoping has been used to control the distribution of multicast traffic with the objective of easing stress on scarce resources (e.g., bandwidth), or to achieve some kind of improved privacy or scaling properties. In addition, the TTL is also used in its traditional role to limit datagram lifetime. Given these often conflicting roles, TTL scoping has proven difficult to implement reliably, and the resulting schemes have often been complex and difficult to understand.
TTLの見ることは、希少資源(例えば、帯域幅)で緊張を和らげる目的があるマルチキャストトラフィックの分配を制御するか、またはある種の改良されたプライバシーかスケーリング特性を獲得するのに使用されました。 また、さらに、TTLは、データグラム生涯を制限するのに伝統的な役割に使用されます。 結果として起こる体系は、しばしばこれらのしばしば闘争している役割を考えて、TTLの見ることは確かに実装するのが難しいと判明して、複雑であって、理解しているのは難しいです。
A more serious architectural problem concerns the interaction of TTL scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The particular problem is that in many common cases, TTL scoping can prevent pruning from being effective. Consider the case in which a packet has either had its TTL expire or failed a TTL threshold. The router which discards the packet will not be capable of pruning any upstream sources, and thus will sink all multicast traffic (whether or not there are downstream receivers). Note that while it might seem possible to send prunes upstream from the point at which a packet is discarded, this strategy can result in legitimate traffic being discarded, since subsequent packets could take a different path and arrive at the same point with a larger TTL.
より重大な建築問題は放送とプルーンのプロトコル(例えば、DVMRP[DVMRP])で見るTTLの相互作用に関係があります。 特定の問題は多くのよくある例では、TTLの見るのが、有効であるので剪定するのを防ぐことができるということです。 パケットがTTLを期限が切れさせるか、またはTTL敷居に失敗した場合を考えてください。 パケットを捨てるルータは、どんな上流のソースも剪定できないで、その結果、すべてのマルチキャストトラフィックを沈めるでしょう(受信機が川下にあるか否かに関係なく)。 パケットが捨てられるポイントからプルーンを上流へ送るのが可能に思えるかもしれませんが、この戦略が正統のトラフィックをもたらして、捨てることができることに注意してください、その後のパケットが異なった経路を取って、より大きいTTLと共に同じポイントに到着できたので。
On the other hand, administratively scoped IP multicast can provide clear and simple semantics for scoped IP multicast. The key properties of administratively scoped IP multicast are that (i). packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and (ii). administratively scoped multicast addresses are locally assigned, and hence are not required to be unique across administrative boundaries.
他方では、行政上見られたIPマルチキャストは明確で簡単な意味論を見られたIPマルチキャストに提供できます。 行政上見られたIPマルチキャストの基本性質は(i) 行政上見られたマルチキャストアドレスに扱われたパケットが構成された管理境界、および(ii)を越えないということです。行政上見られたマルチキャストアドレスは、局所的に割り当てられて、したがって、管理境界の向こう側に特有になるのに必要ではありません。
4. Definition of the Administratively Scoped IPv4 Multicast Space
4. 行政上見られたIPv4マルチキャストスペースの定義
The administratively scoped IPv4 multicast address space is defined to be the range 239.0.0.0 to 239.255.255.255.
行政上見られたIPv4マルチキャストアドレス空間は、.0〜239.255に範囲239.0.0になるように定義されます。.255 .255。
5. Discussion
5. 議論
In order to support administratively scoped IP multicast, a router should support the configuration of per-interface scoped IP multicast boundaries. Such a router, called a boundary router, does not forward packets matching an interface's boundary definition in either direction (the bi-directional check prevents problems with multi- access networks). In addition, a boundary router always prunes the boundary for dense-mode groups [PIMDM], and doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range.
行政上見られたIPマルチキャストをサポートするために、ルータは1インタフェースあたりの見られたIPマルチキャスト境界の構成をサポートするべきです。 境界ルータと呼ばれるそのようなルータはどちらかの方向とのインタフェースの境界定義に合っているパケットを進めません(双方向のチェックはマルチアクセスネットワークに関する問題を防ぎます)。 境界ルータは、さらに、濃いモードグループ[PIMDM]のためにいつも境界を剪定して、受け入れません。まばらなモードのために、グループ[PIMSM]に行政上見られた範囲で加わります。
Meyer Best Current Practice [Page 2] RFC 2365 Administratively Scoped IP Multicast July 1998
IPマルチキャスト1998年7月に行政上見られたマイヤー最も良い現在の習慣[2ページ]RFC2365
6. The Structure of the Administratively Scoped Multicast Space
6. 行政上見られたマルチキャストスペースの構造
The structure of the IP version 4 administratively scoped multicast space is loosely based on the IP Version 6 Addressing Architecture described in RFC 1884 [RFC1884]. This document defines two important scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These scopes are described below.
IPバージョン4の構造は、マルチキャストスペースが緩くRFC1884[RFC1884]で説明されたIPバージョン6Addressing Architectureに基づいているのを行政上見ました。 このドキュメントは2つの重要な範囲を定義します: IPv4の地方の範囲とIPv4の組織の地方の範囲。 これらの範囲は以下で説明されます。
6.1. The IPv4 Local Scope -- 239.255.0.0/16
6.1. IPv4の地方の範囲--239.255 .0.0/、16
239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary. Further, a Local Scope must be completely contained within or equal to any larger scope. In the event that scope regions overlap in area, the area of overlap must be in its own local scope. This implies that any scope boundary is also a boundary for the Local Scope. The more general topological requirements for administratively scoped regions are discussed below.
239.255.0.0/16は、IPv4 Local Scopeになるように定義されます。 Local Scopeは最小量の同封範囲であり、したがって、さらに分割可能ではありません。 Local Scopeの正確な範囲はサイトですが、依存して、局所的に見られた領域はある位相的な規制に従わなければなりません。 特に、Local Scopeはいかなる他の範囲境界にもかかってはいけません。 さらに、Local Scopeはどんなより大きい範囲とも完全に含まれているか、または等しくなければなりません。 範囲の地域が領域に重なる場合、オーバラップの領域がそれ自身の地方の範囲にあるに違いありません。 これは、また、どんな範囲境界もLocal Scopeのための境界であることを含意します。 以下で行政上見られた領域のための、より一般的な位相的な要件について議論します。
6.1.1. Expansion of the IPv4 Local Scope
6.1.1. IPv4の地方の範囲の拡張
The IPv4 Local Scope space grows "downward". As such, the IPv4 Local Scope may grow downward from 239.255.0.0/16 into the reserved ranges 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not be utilized until the 239.255.0.0/16 space is no longer sufficient.
IPv4 Local Scopeスペースは「下向きに」発展します。 そういうものとして、IPv4 Local Scopeは239.255から下の方に伸びるかもしれません。.0 予約された範囲239.254.0 16と.0/239.253.0 16対.0/16.0/。 しかしながら、.0.0/16スペースがもう239.255に十分にならないまで、これらの範囲を利用するべきではありません。
6.2. The IPv4 Organization Local Scope -- 239.192.0.0/14
6.2. IPv4組織ローカル範囲--239.192 .0.0/、14
239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, and is the space from which an organization should allocate sub- ranges when defining scopes for private use.
239.192.0.0/14はIPv4 Organization Local Scopeになるように定義されて、私的使用目的で範囲を定義するとき組織がサブ範囲を割り当てるべきであるスペースです。
6.2.1. Expansion of the IPv4 Organization Local Scope
6.2.1. IPv4の組織の地方の範囲の拡張
The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are unassigned and available for expansion of this space. These ranges should be left unassigned until the 239.192.0.0/14 space is no longer sufficient. This is to allow for the possibility that future revisions of this document may define additional scopes on a scale larger than organizations.
範囲239.0.0 10、.0/239.64.0 10と.0/239.128.0.0/10は、このスペースの拡張に割り当てられないで利用可能です。 これらの範囲は.0.0/14スペースがもう239.192に十分にならないまで割り当てられないように残されるべきです。 これは、このドキュメントの今後の改正が組織より大きいスケールの追加範囲を定義するかもしれない可能性を考慮するためのものです。
6.3. Other IPv4 Scopes of Interest
6.3. 興味がある他のIPv4範囲
The other two scope classes of interest, statically assigned link- local scope and global scope already exist in IPv4 multicast space.
興味がある他の2つの範囲のクラス、静的に割り当てられたリンク地方の範囲、およびグローバルな範囲はIPv4マルチキャストスペースに既に存在しています。
Meyer Best Current Practice [Page 3] RFC 2365 Administratively Scoped IP Multicast July 1998
IPマルチキャスト1998年7月に行政上見られたマイヤー最も良い現在の習慣[3ページ]RFC2365
The statically assigned link-local scope is 224.0.0.0/24. The existing static global scope allocations are somewhat more granular, and include
静的に割り当てられたリンク地方の範囲はそうです。224.0 .0 .0/24。 既存の静的なグローバルな範囲配分がいくらか粒状である、包含
224.1.0.0-224.1.255.255 ST Multicast Groups
224.2.0.0-224.2.127.253 Multimedia Conference Calls
224.2.127.254 SAPv1 Announcements
224.2.127.255 SAPv0 Announcements (deprecated)
224.2.128.0-224.2.255.255 SAP Dynamic Assignments
224.252.0.0-224.255.255.255 DIS transient groups
232.0.0.0-232.255.255.255 VMTP transient groups
224.1.0.0-224.1 .255.255.255 ST Multicast Groups224.2.0.0-224.2.127.253MultimediaコンファレンスCalls224.2.127.254SAPv1 Announcements224.2.127.255SAPv0 Announcements(推奨しない)224.2.128.0-224.2.255SAP Dynamic Assignments224.252.0.0-224.255.255の.255DIS一時的なグループ232.0.0.0-232.255.255.255のVMTPの一時的なグループ
See [RFC1700] for current multicast address assignments (this list can also be found, possibly in a more current form, on ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
現在のマルチキャストアドレス課題に関して[RFC1700]を見てください(また、このリストを見つけることができます、ことによるとより現在のフォームで、 ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses で)。
7. Topological Requirements for Administrative Boundaries
7. 管理境界のための位相的な要件
An administratively scoped IP multicast region is defined to be a topological region in which there are one or more boundary routers with common boundary definitions. Such a router is said to be a boundary for scoped addresses in the range defined in its configuration.
行政上見られたIPマルチキャスト領域は、共有する境界線定義がある1つ以上の境界ルータがある位相的な領域になるように定義されます。 そのようなルータは構成で定義された範囲の見られたアドレスのための境界であると言われています。
Network administrators may configure a scope region whenever constrained multicast scope is required. In addition, an administrator may configure overlapping scope regions (networks can be in multiple scope regions) where convenient, with the only limitations being that a scope region must be connected (there must be a path between any two nodes within a scope region that doesn't leave that region), and convex (i.e., no path between any two points in the region can cross a region boundary). However, it is important to note that if administratively scoped areas intersect topologically, then the outer scope must consist of its address space minus the address spaces of any intersecting scopes. This requirement prevents the problem that would arise when a path between two points in a convex region crosses the boundary of an intersecting region. For this reason, it is recommended that administrative scopes that intersect topologically should not intersect in address range.
強制的なマルチキャスト範囲が必要であるときはいつも、ネットワーク管理者は範囲の地域を構成するかもしれません。 さらに、管理者は範囲の地域をつなげなければならないという(その領域を出ない範囲の地域の中にどんな2つのノードの間にはも、経路があるに違いありません)ことである唯一の制限で便利であって、凸状であるところで重なっている範囲の地域(ネットワークが複数の範囲の地域にあることができる)を構成するかもしれません(すなわち、その領域の任意な2点の間のどんな経路も領域境界に交差できません)。 しかしながら、行政上見られた領域が位相的に横切られるなら外側の範囲がどんな交差範囲のアドレス空間を引いてアドレス空間から成らなければならないことに注意するのは重要です。 この要件は凸状領域の2ポイントの間の経路が交差領域の境界に交差するとき起こる問題を防ぎます。 この理由で、横切られる管理範囲がアドレスの範囲で位相的に横切られるはずがないのは、お勧めです。
Finally, note that any scope boundary is a boundary for the Local Scope. This implies that packets sent to groups covered by 239.255.0.0/16 must not be forwarded across any link for which a scoped boundary is defined.
最終的に、どんな範囲境界もLocal Scopeのための境界であることに注意してください。 これは、グループに送られたパケットが239.255で見られた境界が定義されるどんなリンクの向こう側にも.0/16を送ってはいけない.0をカバーしたのを含意します。
Meyer Best Current Practice [Page 4] RFC 2365 Administratively Scoped IP Multicast July 1998
IPマルチキャスト1998年7月に行政上見られたマイヤー最も良い現在の習慣[4ページ]RFC2365
8. Partitioning of the Administratively Scoped Multicast Space
8. 行政上見られたマルチキャストスペースの仕切り
The following table outlines the partitioning of the IPv4 multicast space, and gives the mapping from IPv4 multicast prefixes to IPv6 SCOP values:
以下のテーブルは、IPv4マルチキャストスペースの仕切りについて概説して、IPv4マルチキャスト接頭語からIPv6 SCOP値までマッピングを与えます:
IPv6 SCOP RFC 1884 Description IPv4 Prefix
===============================================================
0 reserved
1 node-local scope
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned)
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope 239.192.0.0/14
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope 224.0.1.0-238.255.255.255
F reserved
(unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10
IPv6 SCOP RFC1884記述IPv4接頭語=============================================================== 0が1ノードローカル範囲2のリンク地方の範囲224.0.0.0/24 3(割り当てられない)239.255.0.0/16 4(割り当てられない)5サイト地方の範囲(割り当てられません)7の(割り当てられません)8の組織地方の範囲239.192.0.0/14A(割り当てられない)B(割り当てられない)C(割り当てられない)D(割り当てられない)ユーロの6のグローバルな.255F予約された(割り当てられない)範囲224.0.1.0-238.255.255 239.0.0.0/10(割り当てられない)239.64.0.0/10(割り当てられません)239.128.0.0/を予約した、10
9. Structure and Use of a Scoped Region
9. 見られた領域の構造と使用
The high order /24 in every scoped region is reserved for relative assignments. A relative assignment is an integer offset from highest address in the scope and represents a 32-bit address (for IPv4). For example, in the Local Scope defined above, 239.255.255.0/24 is reserved for relative allocations. The de-facto relative assignment "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for SAP [SAP]. The next relative assignment, "1", corresponds to the address 239.255.255.254 in the Local Scope. The rest of a scoped region below the reserved /24 is available for dynamic assignment (presumably by an address allocation protocol).
あらゆる見られた領域の高位/24は相対的な課題のために予約されます。 相対的な課題は、範囲で最も高いアドレスから相殺された整数であり、32ビットのアドレス(IPv4のための)を表します。 Local Scopeは上に、239.255に.255を定義しました。例えば、コネ、.0/24は相対的な配分のために予約されます。 デファクト親類課題、「0インチ、(すなわち、239.255、.255、地方の範囲の.255)、現在SAP[SAP]のために存在する、」 次の相対的な課題、「1インチ、アドレスに対応している、239.255、.255、.254、地方の範囲、」 予約された/24の下の見られた領域の残りはダイナミックな課題(おそらくアドレス配分プロトコルによる)に利用可能です。
In is important to note that a scope discovery protocol [MZAP] will have to be developed to make practical use of scopes other than the Local Scope. In addition, since any use of any administratively scoped region, including the Local Scope, requires dynamically assigned addressing, an Address Allocation Protocol (AAP) will need to be developed to make administrative scoping generally useful.
コネは、範囲発見プロトコル[MZAP]がLocal Scope以外の範囲の実用を作るために開発されなければならないことに注意するために重要です。 さらに、Local Scopeを含むどんな行政上見られた領域のどんな使用もダイナミックに割り当てられたアドレシングを必要とするので、Address Allocationプロトコル(AAP)は、管理見ることを一般に、役に立つようにするように開発される必要があるでしょう。
Meyer Best Current Practice [Page 5] RFC 2365 Administratively Scoped IP Multicast July 1998
IPマルチキャスト1998年7月に行政上見られたマイヤー最も良い現在の習慣[5ページ]RFC2365
9.1. Relative Assignment Guidelines
9.1. 相対的な課題ガイドライン
Requests for relative assignments should be directed to the IANA. The IANA will be advised by an area expert when making relative address assignments. The area expert will be appointed by the relevant Area Director.
相対的な課題を求める要求はIANAに向けられるべきです。 相対アドレス課題をするとき、IANAは領域の専門家によってアドバイスされるでしょう。 領域の専門家は関連Areaディレクターによって任命されるでしょう。
In general, relative addresses will be used only for bootstrapping to dynamic address assignments from within the scope. As such, relative assignments should only be made to those services that cannot use a dynamic address assignment protocol to find the address used by that service within the desired scope, such as a dynamic address assignment service itself.
一般に、相対アドレスは、中からダイナミックなアドレス課題に範囲を独力で進むのにだけ使用されるでしょう。 そういうものとして、相対的な課題を必要な範囲の中のそのサービスで使用されるアドレスを見つけるのにダイナミックなアドレス課題プロトコルを使用できないそれらのサービスにするだけであるべきです、ダイナミックなアドレス課題サービス自体のように。
10. Security Considerations
10. セキュリティ問題
It is recommended that organizations using the administratively scoped IP Multicast addresses not rely on them to prevent sensitive data from being transmitted outside the organization. Should a multicast router on an administrative boundary be mis-configured, have a bug in the administrative scoping code, or have other problems that would cause that router to forward an administratively scoped IP multicast packet outside of the proper scope, the organizations data would leave its intended transmission region.
行政上見られたIP Multicastアドレスを使用する組織が極秘データが組織の外で伝えられるのを防ぐためにそれらを当てにしないのは、お勧めです。 管理境界のマルチキャストルータ誤構成されるなら、管理見ることにおけるバグには、そのルータが適切な範囲(データが意図しているトランスミッション領域を出る組織)の外に行政上見られたIPマルチキャストパケットを送る他の問題がコード化するか、またはあるのを持ってください。
Organizations using administratively scoped IP Multicasting to transmit sensitive data should use some confidentiality mechanism (e.g. encryption) to protect that data. In the case of many existing video-conferencing applications (e.g. vat), encryption is available as an application feature and merely needs to be enabled (and appropriate cryptographic keys securely distributed). For many other applications, the use of the IP Encapsulating Security Payload (ESP) [RFC-1825, RFC-1827] can provide IP-layer confidentiality though encryption.
極秘データを伝えるのに行政上見られたIP Multicastingを使用する組織は、そのデータを保護するのに、何らかの秘密性メカニズム(例えば、暗号化)を使用するべきです。 多くの既存のビデオ会議アプリケーション(例えば、大タンク)の場合では、暗号化は、アプリケーション機能として利用可能であり、単に可能にされる必要があります(そして、しっかりと分配された適切な暗号化キー)。 他の多くのアプリケーションのために、暗号化ですが、IP Encapsulating Security有効搭載量(超能力)[RFC-1825、RFC-1827]の使用はIP-層の秘密性を提供できます。
Within the context of an administratively scoped IP multicast group, the use of manual key distribution might well be feasible. While dynamic key management for IP Security is a research area at the time this note is written, it is expected that the IETF will be extending the ISAKMP key management protocol to support scalable multicast key distribution in the future.
行政上見られたIPマルチキャストグループの文脈の中では、手動の主要な分配の使用はたぶん可能でしょう。 この注意が書かれているときIP Securityのためのダイナミックなかぎ管理が研究領域である間、IETFが将来スケーラブルなマルチキャスト主要な分配をサポートするためにISAKMPかぎ管理プロトコルを広げると予想されます。
It is important to note that the "boundary router" described in this note is not necessarily providing any kind of firewall capability.
この注意で説明された「境界ルータ」が必ずどんな種類のファイアウォール能力も提供しているというわけではないことに注意するのは重要です。
Meyer Best Current Practice [Page 6] RFC 2365 Administratively Scoped IP Multicast July 1998
IPマルチキャスト1998年7月に行政上見られたマイヤー最も良い現在の習慣[6ページ]RFC2365
11. References
11. 参照
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Multicast", presented at the 30th IETF, Toronto, Canada, 25
July 1994.
[ASMA] ジェーコブソンに対して、「行政上見られたIPマルチキャスト」というS.デアリングは第30IETF、トロント(カナダ)に1994年7月25日を提示しました。
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol",
Work in Progress.
T.、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」という[DVMRP]Pusateriは進行中で働いています。
[MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol
(MZAP)", Work in Progress.
[MZAP] ハンドレー、M.、「マルチキャスト範囲ゾーン発表プロトコル(MZAP)」が進行中で働いています。
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast
Version 2, Dense Mode Specification", Work in Progress.
[PIMDM] etデアリング、S、アル、「独立しているマルチキャストバージョン2、濃いモード仕様を議定書の中で述べてください」、ProgressのWork。
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[PIMSM] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1700] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC1884, December 1995.
[RFC1884]Hinden。 R.、およびS.デアリング、「IPバージョン6アドレッシング体系」、RFC1884、1995年12月。
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in
Progress.
[徐々に破壊します] ハンドレー、M.は「以下を徐々に破壊します」。 「セッション発表プロトコル」、進行中の仕事。
12. Author's Address
12. 作者のアドレス
David Meyer Cisco Systems San Jose, CA
デヴィッド・マイヤー・シスコシステムズサンノゼ(カリフォルニア)
EMail: dmm@cisco.com
メール: dmm@cisco.com
Meyer Best Current Practice [Page 7] RFC 2365 Administratively Scoped IP Multicast July 1998
IPマルチキャスト1998年7月に行政上見られたマイヤー最も良い現在の習慣[7ページ]RFC2365
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Meyer Best Current Practice [Page 8]
マイヤーBest現在の習慣[8ページ]
一覧
スポンサーリンク
