RFC2588 日本語訳

Network Working Group                                      R. Finlayson
Request for Comments: 2588                                     LIVE.COM
Category: Informational                                        May 1999

コメントを求めるワーキンググループR.フィンリースン要求をネットワークでつないでください: 2588年のLIVE.COMカテゴリ: 情報の1999年5月

                       IP Multicast and Firewalls

IPマルチキャストとファイアウォール

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

1. Abstract

1. 要約

   Many organizations use a firewall computer that acts as a security
   gateway between the public Internet and their private, internal
   'intranet'.  In this document, we discuss the issues surrounding the
   traversal of IP multicast traffic across a firewall, and describe
   possible ways in which a firewall can implement and control this
   traversal.  We also explain why some firewall mechanisms - such as
   SOCKS - that were designed specifically for unicast traffic, are less
   appropriate for multicast.

多くの組織が公共のインターネットと、それらの個人的で、内部の'イントラネット'の間のセキュリティゲートウェイとして作動するファイアウォールコンピュータを使用します。 本書では、私たちは、ファイアウォールの向こう側にIPマルチキャストトラフィックの縦断を囲む問題について議論して、ファイアウォールがこの縦断を実装して、制御できる可能な方法を述べます。 また、私たちは、マルチキャストには、特にユニキャストトラフィックのために設計されたSOCKSなどのいくつかのファイアウォールメカニズムがなぜそれほど適切でないかを説明します。

2. Introduction

2. 序論

   A firewall is a security gateway that controls access between a
   private adminstrative domain (an 'intranet') and the public Internet.
   This document discusses how a firewall handles IP multicast [1]
   traffic.

ファイアウォールは個人的なadminstrativeドメイン('イントラネット')と公共のインターネットの間のアクセスを制御するセキュリティゲートウェイです。 このドキュメントはファイアウォールがどうIPマルチキャスト[1]トラフィックを扱うかについて議論します。

   We assume that the external side of the firewall (on the Internet)
   has access to IP multicast - i.e., is on the public "Multicast
   Internet" (aka. "MBone"), or perhaps some other multicast network.

私たちは、ファイアウォール(インターネットの)の外部の側面がIPマルチキャストに近づく手段を持っていると思います--すなわち、公共の「マルチキャストインターネット」に、あります。(通称。 "MBone"), または、恐らくある他のマルチキャストネットワーク。

   We also assume that the *internal* network (i.e., intranet) supports
   IP multicast routing.  This is practical, because intranets tend to
   be centrally administered.  (Also, many corporate intranets already
   use multicast internally - for training, meetings, or corporate
   announcements.)  In contrast, some previously proposed firewall
   mechanisms for multicast (e.g., [2]) have worked by sending *unicast*
   packets within the intranet.  Such mechanisms are usually
   inappropriate, because they scale poorly and can cause excessive
   network traffic within the intranet.  Instead, it is better to rely

また、私たちは、*内部の*ネットワーク(すなわち、イントラネット)がIPマルチキャストルーティングをサポートすると思います。 イントラネットが、中心で管理される傾向があるので、これは実用的です。 (また、多くの企業イントラネットがトレーニング、ミーティング、または法人の発表に既に内部的にマルチキャストを使用します。) 対照的に、或るものは以前に、マルチキャストのためにファイアウォールメカニズムを提案しました。(例えば、[2])は、イントラネットの中で*ユニキャスト*パケットを送ることによって、働いていました。 不十分に比例して、イントラネットの中で過度のネットワークトラフィックを引き起こす場合があるので、通常、そのようなメカニズムは不適当です。 代わりに、当てにするほうがよいです。

Finlayson                    Informational                      [Page 1]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[1ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

   upon the existing IP multicast routing/delivery mechanism, rather
   than trying to replace it with unicast.

そうしようとするよりむしろ既存のIPマルチキャストルーティング/排紙機構では、それをユニキャストに取り替えてください。

   This document addresses scenarios where a multicast session is
   carried - via multicast - on both sides of the firewall.  For
   instance, (i) a particular public MBone session may be relayed onto
   the intranet (e.g., for the benefit of employees), or (ii) a special
   internal communication (e.g., announcing a new product) may be
   relayed onto the public MBone.  In contrast, we do not address the
   case of a roaming user - outside the firewall - who wishes to access
   a private internal multicast session, using a virtual private
   network.  (Such "road warrior" scenarios are outside the scope of
   this document.)

このドキュメントはマルチキャストセッションがファイアウォールの両側でマルチキャストで運ばれるシナリオを扱います。 (i) 例えば、特定の公共のMBoneセッションがイントラネット(例えば、従業員の利益のための)にリレーされるかもしれませんか、または(ii)特別な内部のコミュニケーション(例えば、新製品を発表する)は公共のMBoneにリレーされるかもしれません。 対照的に、私たちはファイアウォールの外(個人的な内部のマルチキャストセッションにアクセスすることを願っている)でローミングユーザのケースを扱いません、仮想私設網を使用して。 (このドキュメントの範囲の外にそのような「道行く戦士」シナリオがあります。)

   As noted by Freed and Carosso [3], a firewall can act in two
   different ways:

フリードとCarosso[3]によって注意されるように、ファイアウォールは2つの異なった方法で作動できます:

      1/ As a "protocol end point".  In this case, no internal node
         (other than the firewall) is directly accessible from the
         external Internet, and no external node (other than the
         firewall) is directly accessible from within the intranet.
         Such firewalls are also known as "application-level gateways".
      2/ As a "packet filter".  In this case, internal and external
         nodes are visible to each other at the IP level, but the
         firewall filters out (i.e., blocks passage of) certain packets,
         based on their header or contents.

1 「プロトコルエンドポイント」としての/。 この場合、どんな内部のノード(ファイアウォールを除いた)も外部のインターネットから直接アクセス可能ではありません、そして、どんな外部ノード(ファイアウォールを除いた)もイントラネットから直接アクセス可能ではありません。 また、そのようなファイアウォールは「アプリケーションレベルゲートウェイ」として知られています。 2 「パケットフィルタ」としての/。 すなわち、互いにおいて、この場合、内部の、そして、外部のノードがIPレベルで目に見えますが、ファイアウォールがだんだん知られる、(通路を妨げる、)、それらのヘッダーかコンテンツに基づいたあるパケット。

   In the remainder of this document, we assume the first type of
   firewall, as it is the most restrictive, and generally provides the
   most security.  For multicast, this means that:

このドキュメントの残りでは、私たちは最初のタイプのファイアウォールを仮定します、最も制限していて、一般に最も多くのセキュリティを提供するとき。 マルチキャストのために、これは、以下のことを意味します。

      (i)  A multicast packet that's sent over the Internet will never
           be seen on the intranet (and vice versa), unless such packets
           are explicitly relayed by the firewall, and
      (ii) The IP source address of a relayed multicast packet will be
           that of the firewall, not that of the packet's original
           sender.  To work correctly, the applications and protocols
           being used must take this into account.  (Fortunately, most
           modern multicast-based protocols - for instance, RTP [4] -
           are designed with such relaying in mind.)

(i) インターネットを移動したマルチキャストパケットはイントラネット(逆もまた同様である)で決して見られないでしょう、そのようなパケットがファイアウォールによって明らかにリレーされて、リレーされたマルチキャストパケットの(ii)IPソースアドレスがパケットの元の送り主のものではなく、ファイアウォールのものでなくなる場合。 正しく働くために、使用されるアプリケーションとプロトコルはこれを考慮に入れなければなりません。 (幸い、そのようなリレーが念頭にある状態で、ほとんどの現代のマルチキャストベースのプロトコル(例えば、RTP[4])が設計されています。)

3. Why Multicast is Different

3. MulticastがDifferentである理由

   When considering the security implications of IP multicast, it is
   important to note the fundamental way in which multicast
   communication differs from unicast.

セキュリティがIPマルチキャストの含意であると考えるとき、マルチキャストコミュニケーションがユニキャストと異なっている基本的な方法に注意するのは重要です。

Finlayson                    Informational                      [Page 2]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[2ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

   Unicast communication consists of a 'conversation' between an
   explicit pair of participants.  It therefore makes sense for the
   security of unicast communication to be based upon these participants
   (e.g., by authenticating each participant).  Furthermore, 'trust'
   within unicast communication can be based upon trust in each
   participant, as well as upon trust in the data.

ユニキャストコミュニケーションは明白な組の関係者の間の'会話'から成ります。 したがって、ユニキャストコミュニケーションのセキュリティのために、これらの関係者(例えば、各関係者を認証するのによる)に基づくのは理解できます。 その上、ユニキャストコミュニケーションの中の'信頼'は各関係者の信頼と、データの信頼に基づくことができます。

   Multicast communication, on the other hand, involves a arbitrary
   sized, potentially varying set of participants, whose membership
   might never be fully known.  (This is a feature, not a bug!)  Because
   of this, the security of multicast communication is based not upon
   its participants, but instead, upon its *data*.  In particular,
   multicast communication is authenticated by authenticating packet
   data - e.g., using digital signatures - and privacy is obtained by
   encrypting this data.  And 'trust' within multicast communication is
   based solely upon trust in the data.

他方では、マルチキャストコミュニケーションは会員資格が完全に決して知られているかもしれないというわけではない任意の大きさで分けられて、潜在的に異なったセットの関係者にかかわります。 (これはバグではなく、特徴です!) これのために、関係者に基づいているのではなく、マルチキャストコミュニケーションのセキュリティは代わりに基づいています、*データ*で。特に、例えば、デジタル署名を使用するというパケットデータを認証することによって、マルチキャストコミュニケーションを認証します、そして、このデータを暗号化することによって、プライバシーを得ます。 そして、マルチキャストコミュニケーションの中の'信頼'は唯一データの信頼に基づいています。

4. Multicast-Related Threats and Countermeasures

4. マルチキャスト関連の脅威と対策

   The primary threat arising from relaying multicast across a firewall
   is therefore "bad data" - in particular:

したがって、ファイアウォールの向こう側にマルチキャストをリレーしながら起こるプライマリ脅威は特定の「悪いデータ」です:

      (i)  damaging data flowing from the Internet onto the intranet, or
      (ii) sensitive data inadvertently flowing from the intranet onto
           the external Internet.

インターネットからイントラネットに流れる(i)のダメージが大きいデータ、またはイントラネットから外部のインターネットにうっかり流れる(ii)極秘データ。

   To avert this threat, the intranet's security administrator must
   establish, in advance, a security policy that decides:

この脅威を逸らすために、イントラネットのセキュリティ管理者はあらかじめ、決める安全保障政策を確立しなければなりません:

      (i)  Which multicast groups (and corresponding UDP ports) contain
           data that can safely be relayed from the Internet onto the
           intranet.  For example, the security administrator might
           choose to permit the relaying of an MBone lecture, knowing
           that the data consists only of audio/video (& to safe ports).
      (ii) Which multicast groups (and corresponding UDP ports) will not
           contain sensitive internal information (that should therefore
           not be relayed from the intranet onto the Internet).  This,
           of course, requires placing trust in the applications that
           internal users will use to participate in these groups.  For
           example, if users use an audio/video 'viewer' program to
           participate in an MBone session, then this program must be
           trusted not to be a "Trojan Horse".  (This requirement for
           "trusted applications" is by no means specific to multicast,
           of course.)

(i) それのマルチキャストグループ(そして、対応するUDPポート)はインターネットからイントラネットに安全にリレーできるデータを含みます。 例えば、セキュリティ管理者は、MBone講演のリレーを可能にするのを選ぶかもしれません、データがオーディオ/ビデオだけから成るのを知っていて(安全なポート、) (ii) どのマルチキャストが分類されるかが(そして、対応するUDPポート)機密の内部の情報を含まないでしょう(したがって、イントラネットからインターネットにそれをリレーするべきではありません)。 これは、もちろん内部利用者がこれらのグループに参加するのに使用するアプリケーションで信頼するのを必要とします。 例えば、ユーザがMBoneセッションのときに参加するのにビデオオーディオ/'ビューアー'プログラムを使用するなら、「トロイの木馬」でないとこのプログラムを信じなければなりません。 (「信じられたアプリケーション」のためのこの要件がマルチキャストに決して特定でない、もちろん。)

   Once such a security policy has been established, it is then the job
   of the firewall to implement this policy.

かつて、そのような安全保障政策は確立されました、そして、この政策を実施するのが、ファイアウォールの仕事です。

Finlayson                    Informational                      [Page 3]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[3ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

5. What Firewalls Need to Do

5. ファイアウォールがする必要があること

   In short, a firewall must do three things in order to handle
   multicast:

要するに、ファイアウォールはマルチキャストを扱うために3つのことをしなければなりません:

      1/ Support the chosen multicast security policy (which establishes
         particular multicast groups as being candidates to be relayed),
      2/ Determine (dynamically) when each candidate group should be
         relayed, and
      3/ Relay each candidate group's data across the firewall (and then
         re-multicast it at the far end).

/が選ばれたマルチキャスト安全保障政策(リレーされるために候補であるのと特定のマルチキャストグループを書き立てる)をサポートする1、2/がファイアウォールの向こう側に(ダイナミックに)それぞれの候補グループがいつリレーされるべきであるか、そして、3/リレー各候補者グループのデータを決定する、(当時の再マルチキャスト、それ、遠端)

   These three tasks are described in more detail in the next three
   sections.

これらの3つのタスクがさらに詳細に次の3つのセクションで説明されます。

   Note that because a firewall is often a convenient place to
   centralize the administration of the intranet, some firewalls might
   also perform additional administrative functions - for example,
   auditing, accounting, and resource monitoring.  These additional
   functions, however, are outside the scope of this document, because
   they are not specifically *firewall*-related.  They are equally
   applicable to an administrative domain that is not firewalled.

しばしばファイアウォールがイントラネットの管理を集結する便利な場所であるので、また、いくつかのファイアウォールが追加行政機能を実行するかもしれません--例えば、監査、会計、およびリソースモニターに注意してください。 それらが明確に*ファイアウォール*関連でないので、このドキュメントの範囲の外にしかしながら、これらの追加機能があります。 それらは等しくfirewalledされない管理ドメインに適切です。

6. Supporting a Multicast Security Policy

6. マルチキャスト安全保障政策をサポートします。

   As noted above, a multicast security policy consists of specifying
   the set of allowed multicast groups (& corresponding UDP ports) that
   are candidates to be relayed across the firewall.  There are three
   basic ways in which a firewall can support such a policy:

上で述べたように、マルチキャスト安全保障政策はファイアウォールの向こう側にリレーされるために候補である許容マルチキャストグループ(対応するUDPポート)のセットを指定するのから成ります。 ファイアウォールがそのような方針をサポートすることができる3つの基本的な方法があります:

      1/ Static configuration.  The firewall could be configured, in
         advance, with the set of candidate groups/ports - for example,
         in a configuration file.
      2/ Explicit dynamic configuration.  The set of candidate
         groups/ports could be set (and updated) dynamically, based upon
         an explicit request from one or more trusted clients
         (presumably internal).  For example, the firewall could contain
         a 'remote control' mechanism that allows these trusted clients
         - upon authentication - to update the set of candidate
         groups/ports.
      3/ Implicit dynamic configuration.  The set of candidate
         groups/ports could be determined implicitly, based upon the
         contents of some pre-authorized multicast group/port, such as a
         "session directory".  Suppose, for example, that the security
         policy decides that the default MBone SAP/SDP session directory
         [5] may be relayed, as well as any sessions that are announced
         in this directory.  A 'watcher' process, associated with the
         firewall, would watch this directory, and use its contents to

1/静的な構成。 候補グループ/ポートのセットはあらかじめ、例えば構成ファイルでファイアウォールを構成できました。 2/明白な動的設定。 候補グループ/ポートのセットはダイナミックに設定されたか(そして、アップデートします)、1からの明白な要求に基づいているか、またはさらに信じられたクライアント(おそらく内部の)であるかもしれない。 例えば、ファイアウォールは認証でのこれらの信じられたクライアントが候補グループ/ポートのセットをアップデートできる'遠隔操作'メカニズムを含むかもしれません。 3/暗黙の動的設定。 候補グループ/ポートのセットはそれとなく決定できました、あるプレ認可されたマルチキャストグループ/ポートのコンテンツに基づきます、「セッションディレクトリ」のように。 例えば、安全保障政策が、デフォルトMBone SAP/SDPセッションディレクトリ[5]がリレーされるかもしれないと決めると仮定してください、このディレクトリで発表されるどんなセッションと同様に。 ファイアウォールに関連づけられたプロセスがこのディレクトリを見て、コンテンツを使用する'ウォッチャー'

Finlayson                    Informational                      [Page 4]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[4ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

         dynamically update the set of candidates.

ダイナミックに候補のセットをアップデートしてください。

   Notes:

注意:

      (i)   Certain ranges of multicast addresses are defined to be
            "administratively scoped" [6].  Even though the firewall
            does not act as a true multicast router, the multicast
            security policy should set up and respect administrative
            scope boundaries.
      (ii)  As noted in [2], certain privileged UDP ports may be
            considered dangerous, even with multicast.  The multicast
            security policy should check that such ports do not become
            candidates for relaying.
      (iii) Even if sessions announced in a session directory are
            considered automatic candidates for relaying (i.e., case 3/
            above), the firewall's 'watcher' process should still
            perform some checks on incoming announcements.  In
            particular, it should ensure that each session's 'group'
            address really is a multicast address, and (as noted above)
            it should also check that the port number is within a safe
            range.  Depending on the security policy, it may also wish
            to prevent any *locally* created session announcements from
            becoming candidates (or being relayed).

(i) ある一定の範囲のマルチキャストアドレスは、「行政上見られて」[6]になるように定義されます。 ファイアウォールは本当のマルチキャストルータとして作動しませんが、マルチキャスト安全保障政策は、管理範囲境界をセットアップして、尊敬するべきです。 (ii) [2]で有名であることで、ある一定の特権があるUDPポートはマルチキャストがあっても危険であると考えられるかもしれません。 マルチキャスト安全保障政策は、そのようなポートがリレーの候補にならないのをチェックするべきです。 (iii) セッションがリレーの考えられた自動候補が(すなわち、3/上のケース)、ファイアウォールの'ウォッチャー'であるというセッションディレクトリで発表したとしても、プロセスはまだ入って来る発表にいくつかのチェックを実行しているでしょうに。 特に、各セッションの'グループ'アドレスが本当にマルチキャストアドレスであることを確実にするべきです、そして、また、(上で述べたように)それは安全な範囲の中にポートナンバーがあるのをチェックするべきです。 安全保障政策によって、また、それは、局所的にどんな*も防ぐために、*が候補になるのからのセッション発表を作成することを(または、リレーされます)願うかもしれません。

7. Determining When to Relay Candidate Groups

7. いつ候補グループをリレーするかを決定します。

   If a multicast group becomes a candidate to be relayed across the
   firewall, the actual relaying should *not* be done continually, but
   instead should be done only when there is actual interest in having
   this group relayed.  The reason for this is two-fold.  First,
   relaying a multicast group requires that one or both sides of the
   firewall join the group; this establishes multicast routing state
   within the network.  This is inefficient if there is no current
   interest in having the group relayed (especially for
   Internet->intranet relaying).  Second, the act of relaying an
   unwanted multicast group consumes unnecessary resources in the
   firewall itself.

マルチキャストグループがファイアウォールの向こう側にリレーされるべき候補になるなら、実際のリレーは絶えずしますが、このグループをリレーさせることへの実際の関心があるときだけ代わりに*でないのをするべきである*がなるべきです。 この理由は二面です。 まず最初に、マルチキャストグループをリレーするのは、ファイアウォールのものか両側がグループに加わるのを必要とします。 これはネットワークの中でマルチキャストルーティング状態を設置します。 グループをリレーさせることへのどんな現在の関心もなければこれが効率が悪い、(特に、インターネット->、イントラネット、リレー) 2番目に、求められていないマルチキャストグループをリレーする行為はファイアウォール自体で不要なリソースを消費します。

   The best way for the firewall to determine when a candidate group
   should be relayed is for it to use actual multicast routing
   information, thereby acting much as if it were a real 'inter-domain'
   multicast router.  If the intranet consists of a single subnet only,
   then the firewall could listen to IGMP requests to learn when a
   candidate group has been joined by a node on this subnet.  If,
   however, the intranet consists of more than one subnet, then the
   firewall can learn about candidate group memberships by listening to
   "Domain Wide Multicast Group Membership Reports" [7].  Unfortunately,
   this mechanism has only recently been defined, and is not yet used by

ファイアウォールが、候補グループがいつリレーされるべきであるかを決定する最も良い方法は実際のマルチキャストルーティング情報を使用することです、その結果、まるで非常にそれが本当の'相互ドメイン'マルチキャストルータであるかのように、行動します。 イントラネットがただ一つのサブネットだけから成るなら、ファイアウォールは候補グループがいつこのサブネットのノードによって加わられたかを学ぶというIGMP要求を聴くかもしれません。 しかしながら、イントラネットが1つ以上のサブネットから成るなら、ファイアウォールは、候補グループ会員資格に関して「ドメインの広いマルチキャストグループ会員資格レポート」[7]を聞くことによって、学ぶことができます。 残念ながら、このメカニズムによって最近定義されるだけであり、ありませんが、使用されています。

Finlayson                    Informational                      [Page 5]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[5ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

   most routers.

ほとんどのルータ。

   Another, albeit less desirable, way for the firewall to learn when
   candidate multicast groups have been joined is for the firewall to
   periodically 'probe' each of these groups.  Such a probe can be
   performed by sending an ICMP ECHO request packet to the group, and
   listening for a response (with some timeout interval).  This probing
   scheme is practical provided that the set of candidate groups is
   reasonably small, but it should be used only on the intranet, not on
   the external Internet.  One significant drawback of this approach is
   that some operating systems - most notably Windows 95 - do not
   respond to multicast ICMP ECHOs.  However, this approach has been
   shown to work on a large, all-Unix network.

'別のもの、それほど望ましくはありませんが、ファイアウォールが候補マルチキャストグループがいつ加わられたかを学ぶ方法はファイアウォールが定期的にそれぞれのこれらのグループを調べる'ことです。 ICMP ECHOリクエスト・パケットをグループに送って、応答(いくつかのタイムアウト間隔がある)を聞こうとすることによって、そのような探測装置を実行できます。 候補グループのセットが合理的に小さければ、この調べ体系は実用的ですが、それは外部のインターネットで使用されるのではなく、イントラネットだけで使用されるべきです。 このアプローチの1つの重要な欠点はいくつかのオペレーティングシステム(最も著しくWindows95)がマルチキャストICMP ECHOsに応じないということです。 しかしながら、このアプローチは、大きいオールUnixネットワークに取り組むために示されました。

   Another possibility - less desirable still - is for each node to
   explicitly notify the firewall whenever it joins, or leaves, a
   multicast group.  This requires changes to the node's operating
   system or libraries, or cooperation from the application.  Therefore
   this technique, like the previous one, is applicable only within the
   intranet, not the external Internet.  Note that if multicast
   applications are always launched from a special "session directory"
   or "channel guide" application, then this application may be the only
   one that need be aware of having to contact the firewall.

別の可能性(それほどまだ望ましくない)は接合するか、またはいなくなるときはいつも、各ノードが明らかにファイアウォールに通知することです、マルチキャストグループ。 これはノードのオペレーティングシステムかライブラリへの変化、またはアプリケーションからの協力を必要とします。 したがって、前のもののように、このテクニックは外部のインターネットではなく、イントラネットだけの中で適切です。 マルチキャストアプリケーションが特別な「セッションディレクトリ」か「チャンネルガイド」アプリケーションからいつも実行されるならこのアプリケーションがファイアウォールに連絡しなければならないのを意識しなければならない唯一無二であるかもしれないことに注意してください。

   What makes the latter two approaches ("probing" and "explicit
   notification") undesirable is that they duplicate some of the
   existing functionality of multicast routing, and in a way that scales
   poorly for large networks.  Therefore, if possible, firewalls should
   attempt to make use of existing multicast routing information: either
   IGMP (for a single-subnet intranet), or "Domain Wide Multicast Group
   Membership Reports".

後者の2つのアプローチ(「調べ」と「明白な通知」)を望ましくなくすることはマルチキャストルーティングの既存の機能性のいくつかをコピーして、ある意味で、それが大きいネットワークのために不十分に比例するということです。 したがって、できれば、ファイアウォールは、既存のマルチキャストルーティング情報を利用するのを試みるはずです: IGMP(ただ一つのサブネットイントラネットのための)か「ドメインの広いマルチキャストグループ会員資格レポート。」のどちらか

   In some circumstances, however, the client cannot avoid contacting
   the firewall prior to joining a multicast session.  In this case, it
   may make sense for this contact to also act as a 'notification'
   operation.  Consider, for example, an RTSP [8] proxy associated with
   the firewall.  When the proxy receives a request - from an internal
   user - to open a remote RTSP session, the proxy might examine the
   response from the remote site, to check whether a multicast session
   is being launched, and if so, check whether the multicast group(s)
   are candidates to be relayed.

しかしながら、いくつかの事情では、クライアントは、マルチキャストセッションに参加する前にファイアウォールに連絡するのを避けることができません。 この場合、また、'通知'操作として機能するのはこの接触に理解できるかもしれません。 例えば、RTSP[8]プロキシがファイアウォールと交際したと考えてください。 プロキシが内部のユーザからのリモートRTSPセッションを開くという要求を受け取るとき、プロキシはマルチキャストセッションが着手されているかどうかチェックするためにリモートサイトから応答を調べるかもしれません、そして、そうだとすれば、マルチキャストグループが候補であるかどうかチェックして、リレーされてください。

Finlayson                    Informational                      [Page 6]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[6ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

8. Relaying Candidate Groups

8. 候補グループをリレーします。

   The actual mechanism that's used to relay multicast packets will
   depend upon the nature of the firewall.  One common firewall
   configuration is to use two nodes: one part of the intranet; the
   other part of the external Internet.  In this case, multicast packets
   would be relayed between these two nodes (and then re-multicast on
   the other side) using a tunneling protocol.

マルチキャストパケットをリレーするのに使用した実際のメカニズムはファイアウォールの本質によるでしょう。 1つの一般的なファイアウォール構成は2つのノードを使用することです: イントラネットの一部。 外部のインターネットのもう片方の地域。 この場合、マルチキャストパケットは、これらの2つのノード(そして、次に、反対側の上の再マルチキャスト)の間でトンネリングプロトコルを使用することでリレーされるでしょう。

   A tunneling protocol for multicast should *not* run on top of TCP,
   because the reliability and ordering guarantees that TCP provides are
   unnecessary for multicast communication (where any reliability is
   provided at a higher level), yet would add latency.  Instead, a UDP-
   based tunneling protocol is a better fit for relaying multicast
   packets.  (If congestion avoidance is a concern, then the tunnel
   traffic could be rate-limited, perhaps on a per-group basis.)

**TCPの上で実行されないで、マルチキャストのためのトンネリングプロトコルはそうするべきです、信頼性とTCPが提供するという保証を注文するのは、マルチキャストコミュニケーション(どんな信頼性もより高いレベルで提供されるところ)に不要ですが、潜在を加えるでしょう、したがって。 代わりに、UDPのベースのトンネリングプロトコルは、マルチキャストパケットをリレーするための、より良いフィットです。 (輻輳回避が関心であるなら、トンネルトラフィックは恐らく1グループあたり1個のベースでレートによって限られるかもしれません。)

   One possible tunneling protocol is the "UDP Multicast Tunneling
   Protocol" (UMTP) [9].  Although this protocol was originally designed
   as a mechanism for connecting individual client machines to the
   MBone, it is also a natural fit for for use across firewalls.  UMTP
   uses only a single UDP port, in each direction, for its tunneleling,
   so an existing firewall can easily be configured to support multicast
   relaying, by adding a UMTP implementation at each end, and enabling
   the UDP port for tunneling.

1つの可能なトンネリングプロトコルが「UDPマルチキャストトンネリングプロトコル」(UMTP)[9]です。 このプロトコルは元々接続の個々のクライアントマシンのためのメカニズムとしてMBoneに設計されましたが、また、それは使用にファイアウォールの向こう側に適していた生まれつきの名手です。 UMTPは単一のUDPポートだけを使用します、各方向に、マルチキャストリレーをサポートするために容易に既存のファイアウォールを構成できてtunnelelingするように、各端のときにUMTP実装を加えて、トンネリングのためにUDPポートを可能にすることによって。

   Notes:

注意:

      (i)  When multicast packets are relayed from the intranet onto the
           external Internet, they should be given the same TTL that
           they had when they arrived on the firewall's internal
           interface (except decremented by 1).  Therefore, the internal
           end of the multicast relay mechanism needs to be able to read
           the TTL of incoming packets.  (This may require special
           privileges.)  In contrast, the TTL of packets being relayed
           in the other direction - from the external Internet onto the
           intranet - is usually less important; some default value
           (sufficient to reach the whole intranet) will usually
           suffice.  Thus, the Internet end of the multicast relay
           mechanism - which might be less trusted than the intranet end
           - need not run with special privileges.
      (ii) One end of the multicast tunnel - usually the intranet end -
           will typically act as the controller (i.e., "master") of the
           tunnel, with the other end - usually the Internet end -
           acting as a "slave".  For security, the "master" end of the
           tunnel should be configured not to accept any commands from
           the "slave" (which will often be less trusted).

(i) イントラネットから外部のインターネットにマルチキャストパケットをリレーするとき、ファイアウォールの内部のインタフェース(1つ減少するのを除いた)で到着したとき、それらが持っていたのと同じTTLをそれらに与えるべきです。 したがって、マルチキャストリレーメカニズムの内部の端は、入って来るパケットのTTLを読むことができる必要があります。 (これは特権を必要とするかもしれません。) 対照的に、通常、イントラネットへの外部のインターネットからのもう片方の方向にリレーされるパケットのTTLはそれほど重要ではありません。 通常、何らかのデフォルト値(全体のイントラネットに達することができるくらいの)が十分でしょう。 したがって、マルチキャストリレーメカニズムのインターネット端は特権と共に稼働する必要はありません。(メカニズムはイントラネット終わりほど信じられません)。 (ii) マルチキャストトンネルの片端(通常イントラネット終わり)はもう一方の端があるトンネルのコントローラ(すなわち、「マスター」)--通常インターネット終わり--「奴隷」として機能するとして通常機能するでしょう。 セキュリティ、トンネルの端がそうするべきである「マスター」に関しては、「奴隷」(それほどしばしば信じられない)から少しのコマンドも受け入れないように、構成されてください。

Finlayson                    Informational                      [Page 7]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[7ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

9. Networks With More Than One Firewall

9. 1個以上のファイアウォールがあるネットワーク

   So far we have assumed that there is only one firewall between the
   intranet and the external Internet.  If, however, the intranet has
   more than one firewall, then it's important that no single multicast
   group be relayed by more than one firewall.  Otherwise (because
   firewalls are assumed to be application-level gateways - not proper
   multicast routers), packets sent to any such group would become
   replicated on the other side of the firewalls.  The set of candidate
   groups must therefore be partitioned among the firewalls (so that
   exactly one firewall has responsibility for relaying each candidate
   group).  Clearly, this will require coordination between the
   administrators of the respective firewalls.

今までのところ、私たちは、イントラネットと外部のインターネットの間には、1個のファイアウォールしかないと思いました。 しかしながら、イントラネットに1個以上のファイアウォールがあるなら、どんなただ一つのマルチキャストグループも1個以上のファイアウォールによってリレーされないのが重要です。 さもなければ、(ファイアウォールが想定されるので、アプリケーションレベルゲートウェイになってください--適切なマルチキャストルータでない)、どんなそのようなグループにも送られたパケット。ファイアウォールの反対側で模写されるようになるでしょう。 したがって、ファイアウォールの中で候補グループのセットを仕切らなければなりません(まさに1個のファイアウォールにはそれぞれの候補グループをリレーすることへの責任があるように)。 明確に、これはそれぞれのファイアウォールの管理者の間のコーディネートを必要とするでしょう。

   As a general rule, candidate groups should be assigned - if possible
   - to the firewall that is topologically closest to most of the group
   members (on both the intranet and the external Internet).  For
   example, if a company's intranet spans the Atlantic, with firewalls
   in New York and London, then groups with mostly North American
   members should be assigned to the New York firewall, and groups with
   mostly European members should be assigned to the London firewall.
   (Unfortunately, even if a group has many internal and external
   members on both sides of the Atlantic, only one firewall will be
   allowed to relay it.  Some inefficiencies in the data delivery tree
   are unavoidable in this case.)

できれば、概して、候補グループはグループのメンバー(イントラネットと外部のインターネットの両方の)の大部分の最も近くでファイアウォールに位相的に割り当てられるべきです。 例えば、ファイアウォールがニューヨークとロンドンにある状態で会社のイントラネットが大西洋にかかっているなら、ほとんど北米のメンバーがいるグループはニューヨークファイアウォールに割り当てられるべきです、そして、ほとんどヨーロッパ人のメンバーがいるグループはロンドンファイアウォールに割り当てられるべきです。 (残念ながら、グループに多くの内部の、そして、外部のメンバーが米と欧州にいても、1個のファイアウォールだけがそれをリレーできるでしょう。 データ配送木のいくつかの非能率がこの場合避けられません。)

10. Why SOCKS is Less Appropriate for Multicast

10. SOCKSがMulticastのためのLess Appropriateである理由

   SOCKS [10] is a mechanism for transparently performing unicast
   communication across a firewall.  A special client library -
   simulating the regular 'sockets' library - sits between applications
   and the transport level.  A conversation between a pair of nodes is
   implemented (transparently) as a pair of conversations: one between
   the first node and a firewall; the other between the firewall and the
   second node.

SOCKS[10]は、ファイアウォールの向こう側に透過的にユニキャストコミュニケーションを実行するためのメカニズムです。 特別なクライアントライブラリ(通常の'ソケット'ライブラリをシミュレートする)はアプリケーションと輸送レベルの間に座っています。 1組のノードでの会話は1組の会話として実装されます(透過的に): 最初のノードとファイアウォールの間の1。 ファイアウォールと2番目のノードの間のもう片方。

   In contrast, because multicast communication does not involve a
   conversation between a pair of nodes, the SOCKS model is less
   appropriate.  Although multicast communication across a firewall is
   implemented as two separate multicast communications (one inside the
   firewall; the other outside), the *same* multicast address(es) and
   port(s) are used on both sides of the firewall.  Thus, multicast
   applications running inside the firewall see the same environment as
   those running outside, so there is no need for them to use a special
   library.

対照的に、マルチキャストコミュニケーションが1組のノードでの会話にかかわらないので、SOCKSモデルはそれほど適切ではありません。 2がマルチキャストコミュニケーション(ファイアウォールの中の1; もう片方の外部)を切り離すとき、ファイアウォールの向こう側のマルチキャストコミュニケーションは実装されますが、*同じ*マルチキャストアドレス(es)とポートはファイアウォールの両側で使用されます。 したがって、ファイアウォールの中に稼働するマルチキャストアプリケーションが外に稼働するものであると同じ環境をみなすので、専門図書館を使用する必要は全くありません。

Finlayson                    Informational                      [Page 8]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[8ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

   Nonetheless, there has been a proposal [11] to extend SOCKS V5 to
   support multicast.  This proposal includes two possible modes of
   communication:

それにもかかわらず、マルチキャストをサポートするためにSOCKS V5を広げるという提案[11]がありました。 この提案はコミュニケーションの2つの可能なモードを含んでいます:

      (i)  "MU-mode", uses only *unicast* communication within the
           intranet (between the firewall and each internal group
           member), and
      (ii) "MM-mode", which uses unicast for client-to-firewall relay
           control, but uses *multicast* for other communication within
           the intranet.

(i) イントラネット(ファイアウォールとそれぞれの内部のグループのメンバーの間の)の中で*ユニキャスト*コミュニケーションだけを使用して、「μモード」はイントラネットの中で(ii)「mmモード」を使用します。(クライアントからファイアウォールへのリレーコントロールにユニキャストを使用しますが、それは、他のコミュニケーションに*マルチキャスト*を使用します)。

   As noted in section 2 above, "MU-mode" would be a poor choice
   (unless, for some reason, the intranet does not support multicast
   routing at all).  If multicast routing is available, there should
   rarely be a compelling reason to replace multicast with 'multiple-
   unicast'.  Not only does this scale badly, but it also requires
   (otherwise unnecessary) changes to each application node, because the
   multicast service model is different from that of unicast.

上のセクション2で注意されるように、「μモード」は不十分な選択(イントラネットがある理由で全くマルチキャストルーティングをサポートする場合)でしょう。 マルチキャストルーティングが利用可能であるなら、マルチキャストを'複数のユニキャスト'に取り替えるやむにやまれない理由がめったにあるべきです。 ひどくこのスケールをするだけではなく、マルチキャストサービスモデルがユニキャストのものと異なっているので、それぞれのアプリケーションノードに変化しますまた、それが、必要である(そうでなければ、不要な)。

   On the other hand, "MM-mode" (or some variant thereof) *might* be
   useful in environments where a firewall can learn about group
   membership only via "explicit notification".  In this case each node
   might use SOCKS to notify the firewall whenever it joins and leaves a
   group.  However, as we explained above, this should only be
   considered as a last resort - a far better solution is to leverage
   off the existing multicast routing mechanism.

他方では、「mmモード」(または、それのある異形)*は*役に立つコネがファイアウォールが「明白な通知」を通してだけグループ会員資格に関して学ぶことができる環境であるならそうするでしょうに。 この場合、各ノードは、グループに加わって、出るときはいつも、ファイアウォールに通知するのにSOCKSを使用するかもしれません。 しかしながら、私たちが上で説明したように、これは切り札であるとみなされるだけであるべきです--はるかに良いソリューションは既存のマルチキャストルーティングメカニズムで力を入れることです。

   It has been suggested [11] that a benefit of using multicast SOCKS
   (or an "explicit notification" scheme in general) is that it allows
   the firewall to authenticate a client's multicast "join" and "leave"
   operations.  This, however, does not provide any security, because it
   does not prevent other clients within the intranet from joining the
   multicast session (and receiving packets), nor from sending packets
   to the multicast session.  As we noted in section 3 above,
   authentication and privacy in multicast sessions is usually obtained
   by signing and encrypting the multicast data, not by attempting to
   impose low-level restrictions on group membership.  We note also that
   even if group membership inside the intranet could be restricted, it
   would not be possible, in general, to impose any such membership
   restrictions on the external Internet.

[11] マルチキャストSOCKS(または、一般に、「明白な通知」体系)を使用する利益がクライアントのマルチキャストを認証するためには、「接合してください」と「いなくなってください」という操作をファイアウォールに許すということであると示唆されました。 しかしながら、これは少しのセキュリティも提供しません、イントラネットの中でマルチキャストセッション(パケットを受けて)に参加して、送付パケットからマルチキャストセッションまで他のクライアントを防がないので。 私たちがセクション3で注意したように、上では、通常、低レベルである制限をグループ会員資格に課すのを試みることによって得るのではなく、マルチキャストデータに署名して、暗号化することによって、マルチキャストセッションにおける認証とプライバシーを得ます。 また、私たちは、イントラネットにおけるグループ会員資格が制限された場合があるとしても、一般に、どんなそのような会員資格制限も外部のインターネットに課すのが可能でないことに注意します。

11. Security Considerations

11. セキュリティ問題

   Once a security policy has been established, the techniques described
   in this document can be used to implement this policy.  No security
   mechanism, however, can overcome a badly designed security policy.
   Specifically, network administrators must be confident that the
   multicast groups/ports that they designate as being 'safe' really are

安全保障政策がいったん確立されると、この政策を実施するのに本書では説明されたテクニックは使用できます。 しかしながら、どんなセキュリティー対策もひどく設計された安全保障政策に打ち勝つことができません。 明確に、ネットワーク管理者は彼らが任じる'安全な'マルチキャストグループ/ポートが本当にそうであると確信していなければなりません。

Finlayson                    Informational                      [Page 9]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[9ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

   free from harmful data.  In particular, administrators must be
   familiar with the applications that will receive and process
   multicast data, and (as with unicast applications) be confident that
   they cannot cause harm (e.g., by executing unsafe code received over
   the network).

有害なデータから、自由です。 管理者は、特に、マルチキャストデータを受け取って、処理するアプリケーションになじみ深く、害(例えば、ネットワークの上に受け取られた危険なコードを実行するのによる)を引き起こさない場合があると確信していなければなりません(ユニキャストアプリケーションのように)。

   Because it is possible for an adversary to initiate a "denial of
   service" attack by flooding an otherwise-legitimate multicast group
   with garbage, administrators may also wish to guard against this by
   placing bandwidth limits on cross-firewall relaying.

敵がゴミでそうでなければ、正統のマルチキャストグループをあふれさせることによって「サービスの否定」攻撃を開始するのが、可能であるので、また、交差しているファイアウォールリレーであることに帯域幅限界を置くことによって、管理者はこれに用心したがっているかもしれません。

12. Summary

12. 概要

   Bringing IP multicast across a firewall requires that the intranet
   first establish a multicast security policy that defines which
   multicast groups (& corresponding UDP ports) are candidates to be
   relayed across the firewall.  The firewall implements this policy by
   dynamically determining when each candidate group/port needs to be
   relayed, and then by doing the actual relaying.  This document has
   outlined how a firewall can perform these tasks.

ファイアウォールの向こう側にIPマルチキャストをもたらすのは、イントラネットが最初にファイアウォールの向こう側にリレーされるためにどのマルチキャストグループ(対応するUDPポート)が候補であるかを定義するマルチキャスト安全保障政策を確立するのを必要とします。 ファイアウォールは、各候補者グループ/ポートが、いつリレーされる必要であるかをダイナミックに決定して、そして、実際のリレーをすることによって、この政策を実施します。 このドキュメントはファイアウォールがどうこれらのタスクを実行できるかを概説しました。

13. References

13. 参照

   [1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
       1112, August 1989.

[1] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。

   [2] Djahandari, K., Sterne, D. F., "An MBone Proxy for an Application
       Gateway Firewall" IEEE Symposium on Security and Privacy, 1997.

[2]Djahandari、K.、スターン、D.F.、セキュリティとプライバシーに関する「アプリケーションゲートウェイファイアウォールへのMBoneプロキシ」IEEEシンポジウム、1997。

   [3] Freed, N. and K. Carosso, "An Internet Firewall Transparency
       Requirement", Work in Progress.

「インターネットファイアウォール透明要件」という解放された[3]、N.、およびK.Carossoは進行中で働いています。

   [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for Real-Time Applications", RFC 1889,
       January 1996.

[4]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。

   [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, April 1998.

[5] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

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

[6] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365 1998年7月。

   [7] Fenner, B., "Domain Wide Multicast Group Membership Reports",
       Work in Progress.

[7] フェナー、B.が進行中で働くと「ドメインの広いマルチキャストグループ会員資格は報告します」。

   [8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
       Protocol (RTSP)", RFC 2326, April 1998.

[8]SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。

Finlayson                    Informational                     [Page 10]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[10ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

   [9] Finlayson, R., "The UDP Multicast Tunneling Protocol", Work in
       Progress.

[9] フィンリースン、R.、「UDPマルチキャストトンネリングプロトコル」が進行中で働いています。

   [10] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L.
        Joned, SOCKS Protocol Version 5", RFC 1928, April 1996.

[10]ヒル、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.Joned、ソックスはバージョン5インチについて議定書の中で述べます、RFC1928、1996年4月。

   [11] Chouinard, D., "SOCKS V5 UDP and Multicast Extensions", Work in
        Progress.

[11] シャナードと、D.と、「ソックスV5 UDPとマルチキャスト拡大」は進行中で働いています。

14. Author's Address

14. 作者のアドレス

   Ross Finlayson,
   Live Networks, Inc. (LIVE.COM)

ロスフィンリースン、ライブネットワークInc.(LIVE.COM)

   EMail: finlayson@live.com
   WWW: http://www.live.com/

メール: finlayson@live.com WWW: http://www.live.com/

Finlayson                    Informational                     [Page 11]

RFC 2588               IP Multicast and Firewalls               May 1999

フィンリースンの情報[11ページ]のRFC2588IPマルチキャストとファイアウォール1999年5月

15.  Full Copyright Statement

15. 完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Finlayson                    Informational                     [Page 12]

フィンリースン情報です。[12ページ]