RFC2979 日本語訳

Network Working Group                                           N. Freed
Request for Comments: 2979                                           Sun
Category: Informational                                     October 2000

ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2979年のSunカテゴリ: 情報の2000年10月

                    Behavior of and Requirements for
                           Internet Firewalls

インターネットファイアウォールのための振舞いと要件

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 (2000).  All Rights Reserved.

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

Abstract

要約

   This memo defines behavioral characteristics of and interoperability
   requirements for Internet firewalls.  While most of these things may
   seem obvious, current firewall behavior is often either unspecified
   or underspecified and this lack of specificity often causes problems
   in practice.  This requirement is intended to be a necessary first
   step in making the behavior of firewalls more consistent across
   implementations and in line with accepted IP protocol practices.

このメモはインターネットファイアウォールのための行動の特性と相互運用性要件を定義します。 これらのものの大部分が見えているかもしれない間、明白で、現在のファイアウォールの振舞いは、しばしば不特定であるかunderspecifiedされています、そして、特異性のこの不足は実際にはしばしば問題を起こします。 この要件はファイアウォールの動きを実装と受け入れられたIPプロトコル習慣に沿って、より一貫するようにすることにおける必要な第一歩であることを意図します。

1. Introduction

1. 序論

   The Internet is being used for an increasing number of mission
   critical applications.  Because of this many sites find isolated
   secure intranets insufficient for their needs, even when those
   intranets are based on and use Internet protocols.  Instead they find
   it necessary to provide direct communications paths between the
   sometimes hostile Internet and systems or networks which either deal
   with valuable data, provide vital services, or both.

インターネットは増加する数の不可欠なアプリケーションに使用されています。 これのために、それらのイントラネットはインターネットプロトコルをに基礎づけていて、使用さえするとき、彼らの必要性に、不十分な安全なイントラネットを隔離しました多くのサイトによってわかる。 代わりに、彼らは、貴重な資料に対処する時々敵対的なインターネットとシステムかネットワークの間のダイレクトコミュニケーション経路を提供するのが必要であることがわかって、重大なサービス、または両方を前提としてください。

   The security concerns that inevitably arise from such setups are
   often dealt with by inserting one or more "firewalls" on the path
   between the Internet and the internal network.  A "firewall" is an
   agent which screens network traffic in some way, blocking traffic it
   believes to be inappropriate, dangerous, or both.

インターネットと内部のネットワークの間の経路の1「ファイアウォール」を挿入することによって、そのようなセットアップから必然的に起こる安全上の配慮はしばしば対処されています。 「ファイアウォール」は何らかの方法でそれのスクリーンがトラフィックをネットワークでつなぐエージェントです、それが不適当であると信じている危険なトラフィックか両方を妨げて。

   Note that firewall functions are disjoint from network address
   translation (NAT) functions -- neither implies the other, although
   sometimes both are provided by the same device.  This document only
   discusses firewall functions.

ファイアウォール機能がネットワークアドレス変換(NAT)機能から、ばらばらになってください--どちらももう片方を含意しないということであることに注意してください、時々同じデバイスで両方を提供しますが。 このドキュメントはファイアウォール機能について議論するだけです。

Freed                        Informational                      [Page 1]

RFC 2979                 Firewall Requirements              October 2000

[1ページ]情報のRFC2979ファイアウォール要件2000年10月に、解放されます。

1.1.  Requirements notation

1.1. 要件記法

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY"
   appear capitalized, they are being used to indicate particular
   requirements of this specification.  A discussion of the meanings of
   these terms appears in RFC 2119 [2].

このドキュメントは時折大文字で現れる用語を使用します。 用語“MUST"、“SHOULD"、「必須NOT」である、「」 「5月」は大文字で書かれるように見えて、それらは、この仕様の特定の要件を示すのに使用されるべきです。 これらの用語の意味の議論はRFC2119[2]に現れます。

2.  Characteristics

2. 特性

   Firewalls either act as a protocol end point and relay (e.g., a SMTP
   client/server or a Web proxy agent), as a packet filter, or some
   combination of both.

ファイアウォールはプロトコルエンドポイントとリレー(例えば、SMTPクライアント/サーバかウェブプロキシエージェント)として作動します、パケットフィルタ、または両方の何らかの組み合わせとして。

   When a firewall acts a protocol end point it may

ファイアウォールがそれが機能させるプロトコルエンドポイントを機能させるとき

    (1)   implement a "safe" subset of the protocol,

(1) プロトコルの「安全な」部分集合を実装してください。

    (2)   perform extensive protocol validity checks,

(2) 大規模なプロトコルバリディティチェックを実行してください。

    (3)   use an implementation methodology designed to minimize
          the likelihood of bugs,

(3) バグの見込みを最小にするように設計された実装方法論を使用してください。

    (4)   run in an insulated, "safe" environment, or

または(4) 絶縁されて、「安全な」環境に立候補してください。

    (5)   use some combination of these techniques in tandem.

(5) 2人乗り自転車のこれらのテクニックの何らかの組み合わせを使用してください。

   Firewalls acting as packet filters aren't visible as protocol end
   points.  The firewall examines each packet and then

パケットフィルタとして作動するファイアウォールはプロトコルエンドポイントとして目に見えません。 ファイアウォールは各パケットとその時を調べます。

    (1)   passes the packet through to the other side unchanged,

(1)は変わりがない状態で反対側に終えたパケットを通過します。

    (2)   drops the packet entirely, or

または(2)がパケットを完全に下げる。

    (3)   handles the packet itself in some way.

(3)は何らかの方法でパケット自体を扱います。

   Firewalls typically base some of their decisions on IP source and
   destination addresses and port numbers.  For example, firewalls may

ファイアウォールは彼らの決定のいくつかをIPソース、送付先アドレス、およびポートナンバーに通常基礎づけます。 例えば、ファイアウォールはそうするかもしれません。

   (1)   block packets from the Internet side that claim a source
         address of a system on the internal network,

(1) 内部のネットワークでシステムのソースアドレスを要求するインターネット側からパケットを妨げてください。

   (2)   block TELNET or RLOGIN connections from the Internet to the
         internal network,

(2) インターネットから内部のネットワークまでのTELNETかRLOGIN接続を妨げてください。

   (3)   block SMTP and FTP connections to the Internet from internal
         systems not authorized to send email or move files,

(3) 発信するのは認可されなかった内部のシステムからのインターネットへのブロックSMTPとFTP接続は、ファイルをメールするか、または動かします。

Freed                        Informational                      [Page 2]

RFC 2979                 Firewall Requirements              October 2000

[2ページ]情報のRFC2979ファイアウォール要件2000年10月に、解放されます。

   (4)   act as an intermediate server in handling SMTP and HTTP
         connections in either direction, or

または(4) 取り扱いSMTPとHTTP接続における中間的サーバとしてどちらの方向にも機能してください。

   (5)   require the use of an access negotiation and encapsulation
         protocol such as SOCKS [1] to gain access to the Internet, to
         the internal network, or both.

(5) SOCKS[1]などのアクセス交渉とカプセル化プロトコルの使用を必要として、インターネットへのアクセスを得てください、内部のネットワーク、または両方に。

   (This list of decision criteria is only intended to illustrate the
   sorts of factors firewalls often consider; it is by no means
   exhaustive, nor are all firewall products able to perform all the
   operations on this list.)

(決定基準のこのリストがファイアウォールがしばしば考える要素の種類を例証することを意図するだけです; それは決して徹底的でなく、すべてのファイアウォール製品がこのリストにすべての操作を実行できるというわけではありません。)

3.  Firewall Requirements

3. ファイアウォール要件

   Applications have to continue to work properly in the presence of
   firewalls.  This translates into the following transparency rule:

アプリケーションは、ファイアウォールがあるとき適切に働き続けなければなりません。 これは以下の透明規則に翻訳されます:

      The introduction of a firewall and any associated tunneling or
      access negotiation facilities MUST NOT cause unintended failures
      of legitimate and standards-compliant usage that would work were
      the firewall not present.

どんなファイアウォールの導入と関連トンネリングやアクセス交渉施設もファイアウォールが存在していないなら利く正統の、そして、規格対応することの用法の故意でない失敗を引き起こしてはいけません。

   A necessary corollary to this requirement is that when such failures
   do occur it is incumbent on the firewall and associated software to
   address the problem: Changes to either implementations of existing
   standard protocols or the protocols themselves MUST NOT be necessary.

この要件への必要な推論はそのような失敗が起こるとき、問題と取り組むのがファイアウォールと関連ソフトウェアで現職であるということです: 既存の標準プロトコルの実装かプロトコル自体のどちらかへの変化が必要であるはずがありません。

   Note that this requirement only applies to legitimate protocol usage
   and gratuitous failures -- a firewall is entitled to block any sort
   of access that a site deems illegitimate, regardless of whether or
   not the attempted access is standards-compliant.  This is, after all,
   the primary reason to have a firewall in the first place.

この要件が正統のプロトコル用法と無料の失敗に適用されるだけであることに注意してください--ファイアウォールはサイトが違法であると考えるどんな種類のアクセスも妨げる権利を与えられます、試みられたアクセスが規格対応であるかどうかにかかわらず。 これは結局第一にファイアウォールを持つプライマリ理由です。

   Also note that it is perfectly permissible for a firewall to provide
   additional facilities applications can use to authenticate or
   authorize various sorts of connections, and for the firewall to be
   configurable to require the use of such facilities.  The SOCKS
   protocol [1] is one example of such a facility.  However, the
   firewall MUST also allow configurations where such facilities are not
   required for traversal.

また、ファイアウォールが追加の便宜供与利用を提供するのが、完全に許されているというメモは様々な種類の接続に認証するか、または権限を与えて、ファイアウォールがそのような施設の使用を必要とするのにおいて構成可能であることを使用できます。 SOCKSプロトコル[1]はそのような施設に関する1つの例です。 しかしながら、また、そのような施設は縦断に必要でないところでファイアウォールが構成を許さなければなりません。

Freed                        Informational                      [Page 3]

RFC 2979                 Firewall Requirements              October 2000

[3ページ]情報のRFC2979ファイアウォール要件2000年10月に、解放されます。

3.1.  Examples

3.1. 例

   The following sections provide some examples of how the transparency
   rule actually applies to some specific protocols.

以下のセクションは透明規則が実際にどういくつかの特定のプロトコルに適用されるかに関するいくつかの例を提供します。

3.1.1.  Path MTU Discovery and ICMP

3.1.1. 経路MTU発見とICMP

   ICMP messages are commonly blocked at firewalls because of a
   perception that they are a source of security vulnerabilities.  This
   often creates "black holes" for Path MTU Discovery [3], causing
   legitimate application traffic to be delayed or completely blocked
   when talking to systems connected via links with small MTUs.

知覚のためにファイアウォールで妨げられて、ICMPメッセージは一般的にそうです。それらはセキュリティの脆弱性の源です。 これはPath MTUディスカバリー[3]のためにしばしば「ブラックホール」を作成します、小さいMTUsとのリンクを通して接続されたシステムと話すとき、正統のアプリケーショントラフィックが遅らせられるか、または完全に妨げられることを引き起こして。

   By the transparency rule, a packet-filtering router acting as a
   firewall which permits outgoing IP packets with the Don't Fragment
   (DF) bit set MUST NOT block incoming ICMP Destination Unreachable /
   Fragmentation Needed errors sent in response to the outbound packets
   from reaching hosts inside the firewall, as this would break the
   standards-compliant usage of Path MTU discovery by hosts generating
   legitimate traffic.

透明規則で、外国行きのパケットに対応して送られた入って来るICMP Destination Unreachable/断片化の必要な誤りはホストがどんなFragment(DF)も噛み付かなかったドンと共に出発しているIPパケットを可能にするファイアウォールがセットしながら行動するパケット・フィルタリング・ルータによってファイアウォールの中に届いてはいけないことができません、これが正統のトラフィックを生成するホストによるPath MTU発見の規格対応することの用法を破るだろうというとき。

   On the other hand, it's proper (albeit unfriendly) to block ICMP Echo
   and Echo Reply messages, since these form a different use of the
   network, or to block ICMP Redirect messages entirely, or to block
   ICMP DU/FN messages which were not sent in response to legitimate
   outbound traffic.

他方では、これらがネットワークの異なった使用を形成するのでICMP EchoとEcho Replyメッセージを妨げるか、ICMP Redirectメッセージを完全に妨げるか、または正統のアウトバウンドトラフィックに対応して送られなかったICMP DU/FNメッセージを妨げるのが適切です(無愛想ですが)。

3.1.2.  SMTP Extensions

3.1.2. SMTP拡張子

   The original SMTP protocol [4] didn't provide a mechanism for
   negotiating protocol extensions.  When this was added [5], some
   firewall implementations reacted by simply adding the EHLO command to
   the list of accepted commands.  Unfortunately, this is not
   sufficient: What is necessary is for the firewall to scan the list of
   EHLO responses and only allow the ones the firewalls understands
   through.  If this isn't done the client and server can end up
   agreeing to use an extension the firewalls doesn't understand, which
   can then lead to unnecessary protocol failures.

オリジナルのSMTPプロトコル[4]はプロトコル拡大を交渉するのにメカニズムを提供しませんでした。 [5] これが加えられたとき、いくつかのファイアウォール実装が、単に受け入れられたコマンドのリストにEHLOコマンドを追加することによって、反応しました。 残念ながら、これは十分ではありません: EHLO応答のリストをスキャンして、ファイアウォールが理解しているものの通ることを許すだけであるために、ファイアウォールには必要なものがあります。 クライアントにこれをしないで、サーバが、結局ファイアウォールが使用しない拡張子を使用するのに同意できるなら、次に、どれが不要なプロトコル失敗に通じることができるかを理解してください。

4.  Application Requirements

4. アプリケーション要件

   Firewalls are a fact of life that application protocols must face.
   As such, application protocols SHOULD be designed to facilitate
   operation across firewalls, as long as such design choices don't
   adversely impact the application in other ways.  In addition,
   application protocol specifications MAY include material defining
   requirements firewalls must meet to properly handle a given
   application protocol.

ファイアウォールはアプリケーション・プロトコルが直面しなければならない現実です。 アプリケーション・プロトコルSHOULDがファイアウォールの向こう側に操作を容易にするように設計されていて、そのようなデザイン選択が逆にそうしない限り、そういうものとして、他の方法でアプリケーションに影響を与えてください。 追加、仕様が含むかもしれないアプリケーション・プロトコルでは、要件ファイアウォールを定義する材料は、適切に与えられたアプリケーション・プロトコルを扱うために満たされなければなりません。

Freed                        Informational                      [Page 4]

RFC 2979                 Firewall Requirements              October 2000

[4ページ]情報のRFC2979ファイアウォール要件2000年10月に、解放されます。

   Examples of proper and improper application protocol design include:

適切で不適当なアプリケーション・プロトコルデザインに関する例は:

   (1)   Wrapping a new protocol around HTTP and using port 80 because
         it is likely to be open isn't a good idea, since it will
         eventually result in added complexity in firewall handling of
         port 80.

(1) HTTPと開くのは、名案ではありません、以来ありそうであるのでポート80を使用するのに新しいプロトコルをそれが結局もたらす巻きつけると、ポート80のファイアウォール取り扱いにおける複雑さは加えました。

   (2)   Defining a secure subset of a protocol is a good idea since it
         simplifies the firewall design process.

(2) ファイアウォールデザイン過程を簡素化するので、プロトコルの安全な部分集合を定義するのは、名案です。

   (3)   Specificating an appropriate firewall traversal mechanism if
         one exists is a good idea.

(3) 1つが存在しているなら適切なファイアウォール縦断メカニズムをSpecificatingするのは、名案です。

   (4)   Registering a separate port for new protocols is a good idea.

(4) 新しいプロトコルのために別々のポートを登録するのは、名案です。

5.  Security Considerations

5. セキュリティ問題

   Good security may occasionally result in interoperability failures
   between components.  This is understood.  However, this doesn't mean
   that gratuitous interoperability failures caused by security
   components are acceptable.

優れた警備体制は時折コンポーネントの間の相互運用性失敗をもたらすかもしれません。 これは理解されています。 しかしながら、これは、セキュリティコンポーネントによって引き起こされた無料の相互運用性失敗が許容できることを意味しません。

   The transparency rule impacts security to the extent that it
   precludes certain simpleminded firewall implementation techniques.
   Firewall implementors must therefore work a little harder to achieve
   a given level of security.  However, the transparency rule in no way
   prevents an implementor from achieving whatever level of security is
   necessary.  Moreover, a little more work up front results in better
   security in the long run.  Techniques that do not interfere with
   existing services will almost certainly be more widely deployed than
   ones that do interfere and prevent people from performing useful
   work.

透明規則はある純真なファイアウォール実装のテクニックを排除するという範囲にセキュリティに影響を与えます。 したがって、ファイアウォール作成者は、与えられたレベルのセキュリティを達成するために少し一生懸命働かなければなりません。 しかしながら、セキュリティのいかなるレベルも必要であっても、透明規則は達成からの作成者を決して防ぎません。 そのうえ、仕事は結局、前払いでより良いセキュリティをもう少しもたらします。 既存のサービスを妨げないテクニックは干渉して、人々が実質的な仕事を実行できないものよりほぼ確実に広く配布されるでしょう。

   Some firewall implementors may claim that the burden of total
   transparency is overly onerous and that adequate security cannot be
   achieved in the face of such a requirement.  And there is no question
   that meeting the transparency requirement is more difficult than not
   doing so.

ファイアウォール作成者の中には総透明の負担がひどく煩わしく、そのような要件に直面して十分な安全性は達成できないと主張する人もいるかもしれません。 そして、透明必要条件を満たすのがそうしないより難しいという疑問が全くありません。

   Nevertheless, it is important to remember that the only perfectly
   secure network is one that doesn't allow any data through at all and
   that the only problem with such a network is that it is unusable.
   Anything less is necessarily a tradeoff between usability and
   security.  At present firewalls are being circumvented in ad hoc ways
   because they don't meet this transparency requirement and this
   necessarily weakens security dramatically.  In other words, the only

それにもかかわらず、唯一の完全に安全なネットワークが全く少しのデータも通ることを許さないものであり、そのようなネットワークに関する唯一の問題がそれが使用不可能であるということであることを覚えているのは重要です。 何かより少ないものは必ずユーザビリティとセキュリティの間の見返りです。 彼らがこの透明必要条件を満たさないで、これが必ずセキュリティを劇的に弱めるので、現在のところ、ファイアウォールは臨時の方法で回避されています。 言い換えれば、唯一

Freed                        Informational                      [Page 5]

RFC 2979                 Firewall Requirements              October 2000

[5ページ]情報のRFC2979ファイアウォール要件2000年10月に、解放されます。

   reason that some firewalls remain in use is because they have
   essentially been disabled.  As such, one reason to have a
   transparency requirement is to IMPROVE security.

いくつかのファイアウォールが使用中であり残っている理由はそれらが本質的には障害があるからです。 そういうものとして、IMPROVEセキュリティには透明要件を持つ1つの理由があります。

6.  Acknowlegements

6. Acknowlegements

   Bill Sommerfeld provided the text for the Path MTU Discovery example.
   This document has benefited from discussions with a number of people,
   including but not limited to: Brian Carpenter, Leslie Daigle, John
   Klensin, Elliot Lear, and Keith Moore.

ビル・ゾンマーフェルトはPath MTUディスカバリーの例にテキストを提供しました。 他を含んでいて、このドキュメントは多くの人々との議論の利益を得ました: ブライアン大工(レスリーDaigle)のジョンKlensin、エリオットリア、およびキース・ムーア。

7.  References

7. 参照

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

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

   [2]  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

   [3]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
        November 1990.

[3] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。

   [4]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
        August 1982.

[4] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。

   [5]  Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
        "SMTP Service Extensions", STD 10, RFC 1869, November 1995.

Klensin(J.)が解放した[5]、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは拡大を修理します」、STD10、RFC1869、1995年11月。

8.  Author's Address

8. 作者のアドレス

   Ned Freed
   Sun Microsystems
   1050 Lakes Drive
   West Covina, CA 91790
   USA

ネッド解放されたサン・マイクロシステムズ1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。

   Phone: +1 626 919 3600
   Fax: +1 626 919 3614
   EMail: ned.freed@innosoft.com

以下に電話をしてください。 +1 626 919、3600Fax: +1 3614年の626 919メール: ned.freed@innosoft.com

Freed                        Informational                      [Page 6]

RFC 2979                 Firewall Requirements              October 2000

[6ページ]情報のRFC2979ファイアウォール要件2000年10月に、解放されます。

9.  Full Copyright Statement

9. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。

Freed                        Informational                      [Page 7]

フリードInformationalです。[7ページ]