RFC3235 日本語訳

Network Working Group                                           D. Senie
Request for Comments: 3235                        Amaranth Networks Inc.
Category: Informational                                     January 2002

Senieがコメントのために要求するワーキンググループD.をネットワークでつないでください: 3235年のケイトウは株式会社カテゴリをネットワークでつなぎます: 情報の2002年1月

               Network Address Translator (NAT)-Friendly
                     Application Design Guidelines

ネットワーク・アドレスの翻訳者の(NAT)に優しいアプリケーション設計ガイドライン

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

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

Abstract

要約

   This document discusses those things that application designers might
   wish to consider when designing new protocols.  While many common
   Internet applications will operate cleanly in the presence of Network
   Address Translators, others suffer from a variety of problems when
   crossing these devices.  Guidelines are presented herein to help
   ensure new protocols and applications will, to the extent possible,
   be compatible with NAT (Network Address Translation).

このドキュメントは新しいプロトコルを設計するときアプリケーション設計者が考えたがっているかもしれないそれらのものについて議論します。 これらのデバイスに交差するとき、多くの一般的なインターネットアプリケーションがNetwork Address Translatorsの面前で清潔に作動する間、他のものはさまざまな問題に悩みます。 ガイドラインは、新しいプロトコルとアプリケーションは可能な範囲内でNAT(ネットワークAddress Translation)と互換性があるのを確実にするのを助けるためにここに提示されます。

1. Introduction

1. 序論

   Other documents that describe Network Address Translation (NAT)
   discuss the Terminology and Considerations [RFC2663] and Protocol
   Issues [RFC3022], [RFC3027] or discuss the implications of NAT
   [RFC2993].  All of those relate to various issues with the NAT
   mechanism, effects on protocols and effects upon general Internet
   architecture.

Network Address Translation(NAT)について説明する他のドキュメントが、TerminologyとConsiderations[RFC2663]とプロトコルIssues[RFC3022]、[RFC3027]について議論するか、またはNAT[RFC2993]の含意について議論します。 ものはすべて、NATメカニズムの様々な問題、プロトコルへの効果、および一般的なインターネットアーキテクチャへの効果に関連します。

   It is the focus of this document to provide recommendations to
   authors of new protocols about the effects to consider when designing
   new protocols such that special handling is not required at NAT
   gateway points.

それは特別な取り扱いはNATゲートウェイポイントで必要でないように新しいプロトコルを設計すると考えるという新しいプロトコルの作者への効果に関する推薦を提供するこのドキュメントの焦点です。

   When a protocol is unable to pass cleanly through a NAT, the use of
   an Application Level Gateway (ALG) may still permit operation of the
   protocol.  Depending on the encoding used in a protocol, an ALG may
   be difficult or easy to construct, though in some cases it may not be
   possible at all.  While adjunct to NAT, the formulation of protocols
   that cannot directly operate through NAT should be considered such

プロトコルが清潔にNATを通り抜けることができないとき、Application Levelゲートウェイ(ALG)の使用はまだプロトコルの操作を可能にしているかもしれません。 プロトコルに使用されるコード化であることによって、ALGは組み立てるのが、難しいか、または簡単であるかもしれません、それがいくつかの場合全く可能でないかもしれませんが。 NATへの付属物である間、NATを通して直接作動できないプロトコルの定式化は考えられたそのようなものであるべきです。

Senie                        Informational                      [Page 1]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[1ページ]のRFC3235NAT

   that the ALG design may be simple and automated.  ALGs typically
   operate inside small routers along with the NAT component.  Ideally,
   the ALG should be simple and not require excessive computation or
   state storage.

ALGデザインは、簡単であって、自動化されているかもしれません。 ALGsはNATコンポーネントに伴う小さいルータで通常作動します。 理想的に、ALGは簡単であり、過度の計算か州のストレージを必要とするはずがありません。

   Many of the same issues in application design that create issues for
   NAT (and thus can require ALG support) are also issues for firewalls.
   An application designer would do well to keep this in mind, as any
   protocol that does require special handling by NAT or firewall
   products will be more difficult to deploy than those that require no
   special handling.

また、アプリケーション設計におけるNAT(そして、その結果、ALGサポートを必要とすることができる)のために問題を作成する同じ問題の多くがファイアウォールへの問題です。 アプリケーション設計者はこれを覚えておくために順調でしょう、配布するのがどんな特別な取り扱いも必要としないものよりNATかファイアウォール製品で特別な取り扱いを必要とするどんなプロトコルもさらに難しくなるので。

2. Discussion

2. 議論

   Network Address Translation presents a challenge to some existing
   applications.  In many cases, it should be possible for developers of
   new applications to avoid problems if they understand the issues.
   This document aims to provide the application designer with
   information on what things they can do and what to avoid when trying
   to build applications that are able to function across NAT.

ネットワークAddress Translationはいくつかの既存のアプリケーションへの挑戦を提示します。 多くの場合、彼らが問題を理解しているなら、新しいアプリケーションの開発者が問題を避けるのは、可能であるべきです。 このドキュメントは、どんなことができるか、そして、NATの向こう側に機能できるアプリケーションを組立てようとするとき何を避けたらよいかの情報をアプリケーション設計者に提供することを目指します。

   The proliferation of NAT, especially in homes and small offices
   cannot be dismissed.  The marketing of these technologies to homes
   and small businesses is often focused on a single-computer
   environment, and thus providers only give out a single IP address to
   each user.  NAT has become a popular choice for connecting more than
   a single system per location.

NATの増殖であり、特にホームで小さいところでは、オフィスを棄却できません。 ホームと中小企業へのこれらの技術のマーケティングはしばしばただ一つのコンピュータ環境に焦点を合わせられます、そして、その結果、プロバイダーはただ一つのIPアドレスを各ユーザに配るだけです。 NATは1位置あたり1台のただ一つのシステムより接続するためのポピュラーな選択になりました。

   Clearly the most common problem associated with NAT implementations
   is the passing of addressing data between stations.  Where possible,
   applications should find alternatives to such schemes.  Studying a
   few existing protocols will serve to highlight the different
   approaches possible.

明確にNAT実装に関連している最も一般的な問題はステーションの間のアドレシングデータの通過です。 可能であるところでは、アプリケーションがそのような体系への代替手段を見つけるべきです。 いくつかの既存のプロトコルを研究するのは、可能な異なるアプローチを強調するのに役立つでしょう。

   Two common forms of Traditional NAT exist.  With Basic NAT, only the
   IP addresses of packets are altered by the NAT implementation.  Many
   applications will operate correctly with Basic NAT.  The other common
   form is Network Address Port Translation.  With NAPT, both the IP
   addresses and the source and destination ports (for TCP and UDP) are
   potentially altered by the gateway.  As such, applications passing
   only port number information will work with Basic NAT, but not with
   NAPT.

2つの一般的なフォームのTraditional NATは存在しています。 NATでありBasicと共に、パケットのIPアドレスだけがNAT実装によって変更されます。 多くのアプリケーションがBasic NATで正しく作動するでしょう。 もう片方の一般的なフォームはNetwork Address Port Translationです。 NAPTと共に、IPアドレスとソースと仕向港の両方(TCPとUDPのための)がゲートウェイによって潜在的に変更されます。 そういうものとして、ポートナンバー情報だけを通過するアプリケーションは、Basic NATで働いていますが、NAPTと共に働くというわけではないでしょう。

   Application designers should strive for compatibility with NAPT, as
   this form of NAT is the most widely deployed.  This is also the form
   of NAT that will likely see the greatest penetration in homes and
   small offices.  Not all applications lend themselves to the
   architectural model imposed by NAPT.

このフォームのNATが最も広く配布されるとき、アプリケーション設計者はNAPTとの互換性を求めて努力するべきです。 また、これはおそらくホームと小さいオフィスで最もすばらしい侵入を見るNATのフォームです。 すべてのアプリケーションがNAPTによって課された建築モデルに自分たちを与えるというわけではありません。

Senie                        Informational                      [Page 2]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[2ページ]のRFC3235NAT

3. Recommendations and Examples

3. 推薦と例

   Application designers who work within the constraints of NAT, and who
   do not rely on the presence of ALGs will generally find the easier
   acceptance in user communities where NAT is common.  When designing a
   new application or service, the requirement for an ALG will limit
   deployment until the required additional code is incorporated into
   the many devices which implement NAT.

NATの規制の中で働いて、一般に、意志がNATが一般的であるユーザーコミュニティで、より簡単な承認を見つけるALGsの存在を当てにしないアプリケーション設計者。 新しいアプリケーションかサービスを設計するとき、必要な追加コードが法人組織であるまで、ALGのための要件は展開をNATを実装する多くのデバイスに制限するでしょう。

   Each of the areas called out below are examples of issues to consider
   when building an application.  This list is likely not comprehensive,
   but does cover a number of important issues and considerations.

それぞれの領域は、アプリケーションを組立てると考えるために問題に関する例が以下にあると大声で叫びました。 このリストは、おそらく包括的ではありませんが、多くの切迫した課題と問題を含んでいます。

3.1 Issues and Recommendations affecting all types of Network Address
    Translators

3.1 Network Address Translatorsのすべてのタイプに影響する問題とRecommendations

3.1.1. Peer-to-Peer Applications Limitations

3.1.1. ピアツーピアアプリケーション制限

   Peer to peer applications are problematic in a NAT world.  Client-
   server applications are more generally workable.  Peer-to-peer
   applications rely on each peer being reachable as a server (i.e.,
   bound to a listening port, and able to accept connections) for the
   other to connect to.  With NAPT, there are likely many machines
   behind one address.  With other types of NAT such as Basic NAT with
   Static Address Assignment (providing one-to-one mappings), there is a
   greater chance of making such applications work.

ピアツーピアアプリケーションはNAT世界で問題が多いです。 一般に、クライアントサーバ・アプリケーションは、より実行可能です。 ピアツーピアアプリケーションはそれぞれのもう片方が接続するサーバ(すなわち、聴取ポートと、接続を受け入れることができるのに、バウンドしている)として届いている同輩に頼ります。 NAPTと共に、1つのアドレスの後ろにおそらく多くのマシンがあります。 他のタイプのStatic Address Assignment(1〜1つのマッピングを提供する)があるBasic NATなどのNATと共に、そのようなアプリケーションを働かせるより大きなチャンスがあります。

   Some implementations of NAT can be made to function for UDP-based
   peer-to-peer applications.  This capability is dependent on the
   methodology used to implement the UDP sessions in the NAT device.  If
   the NAT device tracks the tuple (private address, private port,
   public port) then it is possible for an outbound UDP packet to
   establish a channel by which incoming traffic can flow from a source
   other than that originally contacted by the system.  The source IP
   address is NOT used in this case to match incoming packets to UDP
   sessions, allowing any source address using the UDP port number to be
   translated.

NATのいくつかの実装はUDPベースのピアツーピアアプリケーションのために機能させられることができます。 この能力はNATデバイスでUDPセッションを実装するのに使用される方法論に依存しています。 NATデバイスがtuple(プライベート・アドレス、個人的なポート、公共のポート)を追跡するなら、外国行きのUDPパケットが元々システムによって連絡されるのを除いて、入って来るトラフィックがソースから流れることができるチャンネルを確立するのは、可能です。 ソースIPアドレスはこの場合UDPセッションまで入って来るパケットを合わせるのに使用されません、翻訳されるのにUDPポートナンバーを使用することでどんなソースアドレスも許容して。

   NAT devices which track source and destination IP addresses, in
   addition to port numbers, will not permit third-party packets.  NAT
   is often implemented in conjunction along with stateful-inspection
   firewall functionality.  As such the latter implementation of UDP
   association tracking would be considered more secure.

IPがポートナンバーに加えてそれの道のソースと目的地に演説するNATデバイスはパケットを第三者に可能にしないでしょう。 NATはステートフルインスペクションファイアウォールの機能性に伴う接続詞でしばしば実装されます。 そういうものとして、UDP協会追跡の後者の実装は、より安全であると考えられるでしょう。

   NAT/Firewall device implementations could be constructed to have a
   software switch within them, permitting the consumer the ability to
   select whether they want the greater security, or greater ability to
   run peer-to-peer applications.

それらの中にソフトウェア・スイッチを持つためにNAT/ファイアウォールデバイス実装を構成できました、彼らが、よりすばらしいセキュリティが欲しいかどうかを選択する能力、またはピアツーピアアプリケーションを実行するより大きい能力を消費者に可能にして。

Senie                        Informational                      [Page 3]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[3ページ]のRFC3235NAT

3.1.2. Applications Requiring End-to-End IPSec Will Fail

3.1.2. 終わりから終わりへのIPSecを必要とするアプリケーションが失敗するでしょう。

   Use of IPSec for end-to-end security will not function in the
   presence of a NAT implementation.  Application designers may want to
   explore the use of Transport Layer Security (TLS) [RFC2246] as a
   transport mode that will traverse NAT cleanly.  See [RFC2709] for
   additional discussion on combining NAT with Tunnel-mode IPSec
   security on the same device.

IPSecの終わりから終わりへのセキュリティの使用はNAT実装があるとき機能しないでしょう。 アプリケーション設計者は清潔にNATを横断する交通機関としてTransport Layer Security(TLS)[RFC2246]の使用について調査したがっているかもしれません。 同じデバイスの上のTunnel-モードIPSecセキュリティにNATを結合するのと追加議論に関して[RFC2709]を見てください。

3.1.3. Use DNS Names, Not IP Addresses In Payload

3.1.3. 有効搭載量にIPアドレスではなく、DNS名を使用してください。

   Applications should, where possible, use fully qualified domain names
   rather than IP addresses when referring to IP endpoints.  When
   endpoints are across a NAT gateway, private addresses must not be
   allowed to leak to the other endpoint.  An example of where this can
   happen today is with the HTTP and HTML protocols.  It is possible for
   web pages to be specified with numeric IP addresses, rather than with
   names, for example http://192.168.1.10/index.html could be used as a
   URL, but would likely create a problem if this address is on a server
   located behind a NAT gateway.  Users outside the gateway would not be
   able to reach the address 192.168.1.10, and so would not see the
   page.

IP終点について言及するとき、アプリケーションは可能であるところでIPアドレスよりむしろ完全修飾ドメイン名を使用するべきです。 終点がNATゲートウェイのむこうにあるとき、プライベート・アドレスはもう片方の終点に漏れてはいけません。 これが今日起こることができるところに関する例がHTTPとHTMLプロトコルと共にあります。 ウェブページが名前でというよりむしろ数値IPアドレスで指定されるのが、可能である、例えば、 http://192.168.1.10/index.html はURLとして使用できましたが、このアドレスがNATゲートウェイの後ろに位置するサーバにあるなら、問題をおそらく生じさせるでしょう。 ゲートウェイの外のユーザがアドレスに達することができないだろう、192.168、.1、.10、したがって、ページを参照しないでしょう。

   Further exacerbating the problem is the possibility of duplicate
   addresses between realms.  If a server offers a link with a private
   address space IP address embedded within it, such as 192.168.1.10,
   the page referenced may resolve to a system on the local network the
   browser is on, but would be a completely different server.  The
   resulting confusion to end-users would be significant.  Sessions
   involving multiple NAT implementations would be exceptionally
   vulnerable to address reuse issues of this sort.

さらに、問題を悪化させるのは、分野の間の写しアドレスの可能性です。サーバがそれの中で埋め込まれているプライベート・アドレス宇宙IPアドレスとの192.168などのリンクに.1を提供するなら、.10、参照をつけられるページは重要であるかもしれません。完全に異なったサーバであるだろうというのを除いて、ブラウザがオンであると企業内情報通信網のシステムに決議してください。エンドユーザへの結果として起こる混乱は重要でしょう。 複数のNAT実装にかかわるセッションは、再利用がこの種類の問題であると扱うために例外的に被害を受け易いでしょう。

3.1.4. Multicast Considerations

3.1.4. マルチキャスト問題

   Not all NAT devices implement multicast routing protocols.
   Application designers should verify whether the devices in the
   networks where their applications will be deployed are able to
   process multicast traffic if their applications rely on that
   capability.

すべてのNATデバイスが、マルチキャストルーティングがプロトコルであると実装するというわけではありません。 アプリケーション設計者は、彼らのアプリケーションがその能力を当てにするなら彼らのアプリケーションが配布されるネットワークにおけるデバイスがマルチキャストトラフィックを処理できるかどうか確かめるべきです。

3.1.5. Retention Of Address Mapping

3.1.5. アドレス・マッピングの保有

   With the exception of statically configured NAT bindings,
   applications should not assume address mapping will be maintained
   from one session (association between machines, for whatever protocol
   for a period of time) to another.  An example of this is RSVP, which
   forms one connection to reserve the resources, then the actual
   session for which resources were reserved is started.  The sessions

静的に構成されたNAT結合以外に、アプリケーションは、アドレス・マッピングが1つのセッション(しばらく議定書を作ることなら何でものためのマシンの間の協会)から別のものに維持されると仮定するべきではありません。 この例がRSVPである、そして、リソースが予約された実際のセッションは始められます。(RSVPは、リソースを予約するために1つの接続を形成します)。 セッション

Senie                        Informational                      [Page 4]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[4ページ]のRFC3235NAT

   do not necessarily overlap.  There is no guarantee that the NAT
   implementation will keep the binding association.  As such,
   applications that rely on subsequent sessions being mapped to the
   same host IP address may not function without an ALG.

必ず重ならないでください。 NAT実装が拘束力がある協会を維持するという保証が全くありません。 そういうものとして、同じホストIPアドレスに写像されるその後のセッションのときに当てにされるアプリケーションはALGなしで機能しないかもしれません。

   Another consideration is the number of addressing realms.  It is
   entirely possible to have multiple levels of NAT implementations
   between the two end points involved.  As such, one must think about
   the lifetime of such mappings at all such levels.

別の考慮はアドレシング分野の数です。2つのエンドポイントの間の複数のレベルのNAT実装をかかわらせるのは、完全に可能です。 およそ生涯、そういうものとして、そのようなすべてのレベルでそのようなマッピングを考えなければなりません。

   Load balancers and other devices may use a single IP address and port
   to map to multiple actual end points.  Many products implement
   variations on this theme, sometimes using NAT, sometimes using other
   technologies.  The lack of guarantee of mapping is important to
   understand, since the mapping to one actual system to another may not
   survive across such intermediate boxes.

負荷分散装置と対向機器は複数の実際のエンドポイントに写像するただ一つのIPアドレスとポートを使用するかもしれません。 時々他の技術を使用して、時々NATを使用して、多くの製品がこのテーマの変化を実装します。 マッピングの保証の不足は分かるために重要です、別のものへの1台の実際のシステムへのマッピングがそのような中間的箱の向こう側に存続しないかもしれないので。

   Don't assume systems know their own IP addresses.  A system behind a
   NAT may be reachable via a particular IP address, but that address
   may not be recognized by the system itself.  Consider the case of
   Static, one-to-one mapping using Basic NAT.  A server in this context
   will have an IP address from the private realm, and may not know the
   public address which maps to it.  Similarly, some such systems may
   not know their own DNS names, while others may.  This is largely
   dependent on the configuration of the servers and the network within
   the private realm.

システムがそれら自身のIPアドレスを知っていると仮定しないでください。 NATの後ろのシステムは特定のIPアドレスで届くかもしれませんが、そのアドレスはシステム自体によって認識されないかもしれません。 Basic NATを使用して、Static、1〜1のケースが写像していると考えてください。 サーバは、このような関係においては私設の分野からのIPアドレスを持って、公衆がどの地図をそれに扱うかを知らないかもしれません。 同様に、そのようないくつかのシステムはそれら自身のDNS名を知らないかもしれませんが、他のものはそうするかもしれません。 これは私設の分野の中でサーバとネットワークの構成に主に依存しています。

3.2 Recommendations for NAPT

3.2 NAPTのための推薦

   As many of the issues specifically address NAPT issues, this section
   will group these issues.  NAPT is the most common form of NAT in
   actual deployment in routers, especially in smaller offices and home
   offices.

問題の多くが明確にNAPTに問題を扱うとき、このセクションはこれらの問題から構成されるでしょう。 NAPTは特にルータにおける実際の展開、より小さいオフィス、およびホームオフィスで、最も一般的なフォームのNATです。

3.2.1 IP Addresses Specific To A Realm

3.2.1 分野に特定のIPアドレス

   Avoid the use of IP address and port number information within the
   payload of packets.  While in some cases ALGs will permit such
   protocols to function, this presupposes every NAT device can be
   updated in a timely fashion to support a new protocol.  Since this is
   unlikely, application writers are urged to avoid placing addressing
   information in payloads all together.

パケットのペイロードの中にIPアドレスとポートナンバー情報の使用を避けてください。 いくつかの場合、ALGsが機能するそのようなプロトコルを可能にするのでこれがあらゆるNATを予想している間、新しいプロトコルをサポートするために直ちにデバイスをアップデートできます。 これがありそうもないので、アプリケーション作家が、一斉にアドレス指定情報をペイロードに置くのを避けるよう促されます。

   In addition to avoiding addresses and port numbers within packet
   payloads, it is important to avoid assumptions of (address, port)
   tuples are unique beyond the scope of the present session.  Load
   balancing devices implementing NAT may, for example, map subsequent
   sessions to other systems in the private realm.

パケットペイロードの中にアドレスとポートナンバーを避けることに加えて、(アドレス、ポート)の仮定を避けるために、tuplesが現在のセッションの範囲を超えてユニークであることは、重要です。 例えば、NATを実装するロードバランシングデバイスは私設の分野でその後のセッションを他のシステムに写像するかもしれません。

Senie                        Informational                      [Page 5]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[5ページ]のRFC3235NAT

3.2.2 Avoid Session Bundles

3.2.2 セッションバンドルを避けてください。

   Independent sessions, such as used by POP or SMTP, are preferred to
   protocols that attempt to manage a bundle of related sessions, such
   as FTP.  The term "session" here is used to refer to any association
   between end systems, and may be using any transport protocol or
   combination of protocols (UDP, TCP, SCTP).

POPかSMTPによって使用されるように独立しているセッションは関連するセッションのバンドルを管理するのを試みるプロトコルより好まれます、FTPなどのように。 ここの「セッション」という用語は、プロトコル(UDP、TCP、SCTP)のエンドシステムの間のどんな協会についても言及するのに使用されて、どんなトランスポート・プロトコルも使用するか、組み合わせであるかもしれません。

   In the FTP protocol, port information is passed over one TCP
   connection and is used to construct a second TCP connection for
   passing the actual data.  Use of a separate connection to transfer
   the file data makes determination of file end quite simple, however
   other schemes could be envisioned which could use a single
   connection.

ポート情報は、FTPプロトコルが、1つ以上のTCP接続に渡されて、実際のデータを通過するための2番目のTCP接続を構成するのにおいて使用されています。 ファイルデータを移す別々の接続の使用でファイルエンドの決断はかなり簡単になって、しかしながら、単独結合を使用できた他の体系は思い描くことができました。

   The HTTP protocol, for example, uses a header and content length
   approach to passing data.  In this model, all data is transferred
   over the single TCP connection, with the header portion indicating
   the length of the data to follow.  HTTP has evolved to allow multiple
   objects to be passed on a single connection (thereby cutting the
   connection establishment overhead).  Clearly a new file transfer
   function could be built that would perform most of the functions of
   FTP without the need for additional TCP connections.

例えば、HTTPプロトコルはデータを通過することへのヘッダーとコンテンツの長さアプローチを使用します。 このモデルでは、単独のTCP接続の上にすべてのデータを移します、ヘッダー部分が続くようにデータの長さを示していて。 HTTPは、複数のオブジェクトが単独結合(その結果、コネクション確立オーバーヘッドを削減する)で渡されるのを許容するために発展しました。 明確に追加TCP接続の必要性なしでFTPの機能の大部分を実行する新しいファイル転送機能は築き上げられるかもしれません。

   The goal is to keep to single connections where possible.  This keeps
   us from needing to pass addressing information of any sort across the
   network.  However, multiplexing traffic over a single connection can
   create problems as well.

目標は可能であるところで単独結合に保つことです。 これによって、私たちは、ネットワークの向こう側にどんな種類に関するアドレス指定情報も通過する必要があることができません。 しかしながら、単独結合の上にトラフィックを多重送信するのはまた、問題を生じさせることができます。

3.2.3. Session Bundles Originate From Same End

3.2.3. セッションバンドルは同じ終わりから発します。

   Origination of connections is an important consideration.  Where
   possible, the client should originate all connections.  The FTP
   protocol is the most obvious example, where by default the server
   opens the data connection to a port on the client (the client having
   specified the port number via a PORT command over the control TCP
   session).

接続の創作は重要な考慮すべき事柄です。 可能であるところでは、クライアントがすべての接続を溯源するべきです。 FTPプロトコルは最も明白な例です。(デフォルトで、そこでは、サーバがクライアントの上のポートにデータ接続を開きます(クライアントがコントロールTCPセッションの間のPORTコマンドでポートナンバーを指定して))。

   As pointed out in [RFC1579], the use of the passive open option in
   FTP (PASV) remedies this situation as the client is responsible for
   opening the connection in this case.  With client-opened connections,
   the standard functions of NAPT will process the request as it would
   any other simple TCP connection, and so an ALG is not required.

[RFC1579]で指摘されるように、クライアントはこの場合接続を開くのに責任があるので、FTP(PASV)における受け身の可能な選択肢の使用はこの事態を改善します。 NAPTの標準関数がそれとしての要求がそうするプロセスにいかなる他の純真なTCP接続も望むので、クライアントによって開かれた接続と共に、ALGは必要ではありません。

   In cases where session bundles are unavoidable, each session in the
   bundle should originate from the same end station.

セッションバンドルが避けられない場合では、バンドルにおける各セッションは同じ端のステーションから発するべきです。

Senie                        Informational                      [Page 6]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[6ページ]のRFC3235NAT

3.2.4. Choice of Transport Protocol

3.2.4. トランスポート・プロトコルの選択

   NAPT gateways must track which sessions are alive, and flush old
   sessions.  TCP has clear advantages in this area, since there are
   specific beginning and end of session indicators in the packets (SYN
   and FIN packets).  While UDP works for some types of applications
   with NAT, there can be issues when that data is infrequent.  Since
   there is no clean way to know when an end station has finished using
   a UDP session, NAT implementations use timeouts to guess when a UDP
   session completes.  If an application doesn't send data for a long
   period of time, the NAT translation may time out.

NAPTゲートウェイは、どのセッションが生きているかを追跡して、古いセッションを洗い流さなければなりません。 TCPはこの領域に明らかに有利な立場を持っています、セッションインディケータの特定の始めと終わりがパケット(SYNとFINパケット)にあるので。 そのデータが珍しいときに、UDPがNATとの何人かのタイプのアプリケーションのために働いている間、問題があることができます。 端のステーションが、いつUDPセッションを使用し終えたかを知るどんな清潔な方法もないので、NAT実装はいつかを推測するのにタイムアウトを使用します。UDPセッションは終了します。 アプリケーションが長い年月の間データを送らないなら、NAT翻訳はタイムアウトを送ります。

   NAT implementations also use timers to guess when TCP sessions have
   disappeared.  While TCP sessions should disappear only after FIN
   packets are exchanged, it is possible that such packets may never
   come, for example if both end stations die.  As such, the NAT
   implementation must use a timer for cleaning up its resources.

また、NAT実装は、TCPセッションがいつ見えなくなったかを推測するのにタイマを使用します。 FINパケットを交換した後にだけTCPセッションは見えなくなるべきですが、そのようなパケットが決して来ないのは、可能です、例えば、両方の端のステーションが死ぬなら。 そういうものとして、NAT実装は、リソースをきれいにするのにタイマを使用しなければなりません。

   NAT implementers in many cases provide several timeouts, one for live
   TCP sessions, one for TCP sessions on which a FIN has been seen, and
   one for UDP sessions.  It is best when such flexibility is provided,
   but some implementations appear to apply a single timer to all
   traffic.

多くの場合、NAT implementersは数回のタイムアウト、ライブTCPセッションのためのもの、FINが見られたTCPセッションのためのもの、およびUDPセッションのための1つを供給します。 そのような柔軟性を提供するとき、それは最も良いのですが、いくつかの実装が単一のタイマをすべてのトラフィックに適用するように見えます。

   Protocols other than TCP and UDP can work with Traditional NAT in
   many cases, provided they are not carrying addressing information.
   For NAPT implementations use of any protocols other than TCP and UDP
   will be problematic unless or until such protocols are programmed
   into the implementations.

多くの場合、TCPとUDP以外のプロトコルはTraditional NATで働くことができます、アドレス指定情報を運ばないなら。 または、TCPとUDP以外のどんなプロトコルのNAPT実装使用も問題が多くなる、そのようなプロトコルが実装にプログラムされるまで。

   It's important to note that NAPT deployments are based on the
   assumption of a client-server application model, with the clients in
   the private realm.

NAPT展開がクライアント/サーバアプリケーションモデルの仮定に基づいていることに注意するのは重要です、私設の分野のクライアントと共に。

3.2.5. IP Fragmentation

3.2.5. IP断片化

   Applications should attempt to avoid fragmentation when packets pass
   over NAPT devices.  While not always practical or possible, there are
   failures that can occur with NAPT.  Specifically, if two stations in
   the private realm pick matching fragmentation identifiers, and talk
   to the same remote host, it may be impossible to determine which
   fragments belong to which session.  A clever NAPT implementation
   could track fragmentation identifiers and map those into a unique
   space, though it is not clear how many do so.

パケットがNAPTデバイスを通り過ぎると、アプリケーションは、断片化を避けるのを試みるべきです。 いつも実用的でないか、または可能ではありませんが、NAPTと共に起こることができる失敗があります。 明確に、私設の分野の2つのステーションが合っている断片化に識別子を選んで、同じリモートホストと話すなら、どの断片がどのセッションに属すかを決定するのは不可能であるかもしれません。 賢明なNAPT実装は、断片化識別子を追跡して、ユニークなスペースにそれらを写像するかもしれません、いくつがそうするかが、明確ではありませんが。

Senie                        Informational                      [Page 7]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[7ページ]のRFC3235NAT

   Ideally, applications should limit packet size, use Path MTU
   Discovery or both.  Unfortunately, at least some firewall/NAT devices
   block Path MTU Discovery, apparently believing all ICMP packets are
   evil.

理想的に、アプリケーションがパケットサイズを制限するべきであり、使用は、Path MTUディスカバリーか両方です。 残念ながら、すべてのICMPパケットが不吉であると明らかに信じていて、少なくともいくつかのファイアウォール/NATデバイスがPath MTUディスカバリーを妨げます。

   Some implementations of NAT may implement fragment reassembly prior
   to Forwarding, however many do not.  Application designers are
   advised to design assuming the devices do not reassemble fragments.

多くがどのようにそうしないでも、NATのいくつかの実装がForwardingの前で断片再アセンブリを実装するかもしれません。 デバイスが組み立て直されないと仮定する設計するデザイナーがアドバイスされるアプリケーションが断片化します。

3.3 Issues and recommendations for Basic NAT

3.3 Basic NATのための問題と推薦

   If only Basic NAT implementations are involved, not NAPT, then many
   of the issues above do not apply.  This is not to say that this form
   of NAT is better or worse than NAPT.  Application designers may think
   they could just specify users must use Basic NAT, and many
   application issues would go away.  This is unrealistic, however, as
   many users have no real alternative to NAPT due to the way their
   providers sell service.

Basic NAT実装だけがNAPTではなくかかわるなら、上の問題の多くが適用されません。 これは、このフォームのNATがNAPTよりさらに良いか、または悪いと言わないためのものです。 アプリケーション設計者は、彼らがただ遠くで許可していた状態でBasic NAT、および多くのアプリケーション問題が指定するユーザ必須使用を指定するかもしれないと考えるかもしれません。 しかしながら、多くのユーザが彼らのプロバイダーがサービスを販売する方法のためどんな本当の代替手段もNAPTに持っていないとき、これは非現実的です。

   Many of the issues raised earlier still apply to Basic NAT, and many
   protocols will not function correctly without assistance.

より早く提起された問題の多くがまだBasic NATに適用されています、そして、多くのプロトコルは支援なしで正しく機能しないでしょう。

3.3.1. Use IP and TCP/UDP Headers Alone

3.3.1. 単独でIPとTCP/UDPヘッダーを使用してください。

   Applications that use only the information in the IP and TCP or UDP
   headers for communication (in other words, do not pass any additional
   addressing information in the payload of the packets), are clearly
   easier to support in a NAT environment.  Where possible, applications
   designers should try to limit themselves in this area.

コミュニケーション(言い換えれば、パケットのペイロードの少しの追加アドレス指定情報も通過しない)にIPとTCPかUDPヘッダーで情報だけを使用するアプリケーションはNAT環境で明確にサポートしやすいです。 可能であるところでは、アプリケーションデザイナーがこの領域で自分たちを制限しようとするべきです。

   This comes back to the same recommendation made for NAPT, that being
   to use a single connection whenever possible.

これはNAPTのためにされた同じ推薦状に戻って、可能であるときはいつも、それは単独結合を使用することになっています。

   The X windowing system, for example, uses fixed port numbers to
   address X servers.  With X, the server (display) is addressed via
   ports 6000 through 6000 + n.  These map to hostname:0 through
   hostname:n server displays.  Since only the address and port are
   used, the NAT administrator could map these ports to one or more
   private addresses, yielding a functioning solution.

例えば、Xウインドーシステムは、Xがサーバであると扱うのに固定ポートナンバーを使用します。 Xと共に、サーバ(ディスプレイ)はポートを通して6000年から6000+nに扱われます。 これらはホスト名: ホスト名を通した0に以下を写像して、nサーバは表示します。 アドレスとポートだけが使用されているので、NAT管理者はこれらのポートを1つ以上のプライベート・アドレスに写像できました、機能しているソリューションをもたらして。

   The X example, in the case of NAPT, requires configuration of the NAT
   implementation.  This results in the ability for no more than one
   station inside the NAT gateway to use such a protocol.  This approach
   to the problem is thus OK for NAT but not recommended for NAPT
   environments.

NAPTの場合では、Xの例はNAT実装の構成を必要とします。 これはNATゲートウェイの中の1つ未満のステーションがそのようなプロトコルを使用する能力をもたらします。 問題へのこのアプローチは、NAPT環境のためにこのようにしてNATのために承認しますが、推薦されません。

Senie                        Informational                      [Page 8]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[8ページ]のRFC3235NAT

3.3.2. Avoid Addressing In Payload

3.3.2. 有効搭載量で扱うのを避けてください。

   As with NAPT, transporting IP address and/or port number information
   in the payload is likely to cause trouble.  As stated earlier, load
   balancers and similar platforms may well map the same IP address and
   port number to a completely different system.  Thus it is problematic
   to assume an address or port number which is valid in the realm on
   one side of a NAT is valid on the other side.

NAPTのように、ペイロードのIPアドレス、そして/または、ポートナンバー情報を輸送するのは問題を起こしそうです。 より早く述べられるように、負荷分散装置と同様のプラットホームはたぶん同じIPアドレスとポートナンバーを完全に異なったシステムに写像するでしょう。 したがって、NATの半面の分野で有効なアドレスかポートナンバーが反対側で有効であると仮定するのは問題が多いです。

3.4 Bi-directional NAT

3.4 双方向のNAT

   Bi-directional NAT makes use of DNS mapping of names to point
   sessions originating outside the private realm to servers in the
   private realm.  Through use of a DNS-ALG [RFC2694], lookups are
   performed to find the proper host and packets are sent to that host.

双方向のNATは、私設の分野で私設の分野の外で起因するセッションをサーバに向けるのに名前に関するDNSマッピングを利用します。 DNS-ALG[RFC2694]の使用で、適切なホストを見つけるためにルックアップを実行します、そして、そのホストにパケットを送ります。

   Requirements for applications are the same as for Basic NAT.
   Addresses are mapped one-to-one to servers.  Unlike Traditional NAT
   devices, Bi-directional NAT devices (in conjunction with DNS-ALG) are
   amenable to peer-to-peer applications.

アプリケーションのための要件はBasic NATのように同じです。 アドレスは1〜1にサーバに写像されます。 Traditional NATデバイスと異なって、Bi方向のNATデバイス(DNS-ALGに関連した)はピアツーピアアプリケーションに従順です。

3.5 Twice NAT

3.5 2倍NAT

   Twice NAT is address translation where both source and destination IP
   addresses are modified due to addressing conflicts between two
   private realms.  Two bi-directional NAT boxes connected together
   would essentially perform the same task, though a common address
   space that is not otherwise used by either private realm would be
   required.

二度、NATは2つの私設の分野の間の闘争を扱うためソースと送付先IPアドレスの両方が変更されるアドレス変換です。一緒に接続された2個の双方向のNAT箱が本質的には同じタスクを実行するでしょう、別の方法でどちらの私設の分野によっても使用されない一般的なアドレス空間が必要でしょうが。

   Requirements for applications to work in the Twice NAT environment
   are the same as for Basic NAT.  Addresses are mapped one to one.

アプリケーションがTwice NAT環境で動作するという要件はBasic NATのように同じです。 アドレスは1〜1に写像されます。

3.6 Multi-homed NAT

3.6、マルチ、家へ帰り、NAT

   Multi-homed NAT is the use of multiple NAT implementations to provide
   redundancy.  The multiple implementations share configuration
   information so that sessions might continue in the event of a fail-
   over.  Unless the multiple implementations share the same external
   addresses, sessions will have to restart regardless.

マルチ、家へ帰り、NATは冗長を提供する複数のNAT実装の使用です。 複数の実装が、セッションがやり損ないの場合、続くことができるように、設定情報を共有します。終わっている、複数の実装が同じ外部アドレスを共有しないと、セッションは不注意に再開しなければならないでしょう。

   Requirements for multi-homed NAT are the same as for Basic NAT or
   NAPT, depending on how the multi-homed NAT is implemented and
   configured.

要件、マルチ、家へ帰り、NATがBasic NATのように同じであるか、またはNAPT、依存がオンである、どのように、マルチ、家へ帰り、NATは、実装されて、構成されるか。

Senie                        Informational                      [Page 9]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[9ページ]のRFC3235NAT

3.7 Realm Specific IP (RSIP)

3.7 分野の特定のIP(RSIP)

   Realm Specific IP is described in [RFC2663] and defined in [RSIP] and
   related documents.  Clients within a private realm using RSIP are
   aware of the delineation between private and public, and access a
   server to allocate address (and optionally port) information for use
   in conversing with hosts in the public realm.  By doing this, clients
   create packets that need not be altered by the RSIP server on their
   way to the remote host.  This technique can permit IPSec to function,
   and potentially makes any application function as if there were no
   special processing involved at all.

分野Specific IPは[RFC2663]で説明されて、[RSIP]と関連するドキュメントで定義されます。 RSIPを使用する私設の分野の中のクライアントが個人的で公共であることの間の輪郭描写を意識していて、アドレスを割り当てるためにサーバにアクセスする、(任意に、ポート) 公共部門でホストと話すことにおける使用のための情報。 そうすれば、クライアントはリモートホストへの途中でRSIPサーバによって変更される必要はないパケットを作成します。 このテクニックは、IPSecが機能することを許可できて、まるで全くかかわらない特別な処理があるかのように潜在的にどんなアプリケーションの機能も作ります。

   RSIP uses a view of the world in which there are only two realms, the
   private and public.  This isn't always the case.  Situations with
   multiple levels of NAT implementations are growing.  For example,
   some ISPs are handing out [RFC1918] addresses to their dialup users,
   rather than obtaining real addresses.  Any user of such an ISP who
   also uses a NAT implementation will see two levels of NAT, and the
   advantages of RSIP will have been wasted.

RSIPは2つの分野だけ、個人的であるのと公共がある世界観を使用します。 これはいつもそうであるというわけではありません。 複数のレベルのNAT実装がある状況は成長しています。 例えば、いくつかのISPが本当のアドレスを得るよりむしろ[RFC1918]アドレスを彼らのダイアルアップユーザに与えています。 また、NAT実装を使用するそのようなISPのどんなユーザも2つのレベルのNATを見るでしょう、そして、RSIPの利点は浪費されてしまうでしょう。

3.8 Performance Implications of Address Translation Implementations

3.8 アドレス変換実装のパフォーマンス含意

   Resource utilization on the NAT gateway should be considered.  An
   application that opens and closes many TCP connections, for example,
   will use up more resources on the NAT router than an application
   performing all transfers over a single TCP connection.  HTTP 1.0
   opened a connection for each object on a web page, whereas HTTP 1.1
   permits the TCP session to be held open for additional objects that
   may need to be transferred.  Clearly the latter imposes a lower
   overhead on the NAT gateway, as it is only maintaining state on a
   single connection instead of multiple connections.

NATゲートウェイにおけるリソース利用は考えられるべきです。 例えば、多くのTCP接続を開いて、終えるアプリケーションは単独のTCP接続の上ですべての転送を実行するアプリケーションよりNATルータに関するリソースを使いきるでしょう。 HTTP1.0はウェブページの各オブジェクトのための接続を開きましたが、HTTP1.1は、TCPセッションが移される必要があるかもしれない追加オブジェクトにおいて開くと行われることを許可します。 明確に、後者は低いオーバーヘッドをNATゲートウェイに課します、複数の接続の代わりに単独結合の状態を維持しているだけであるとき。

   New session establishment will typically remain a software function
   even in implementations where the packet-by-packet translation work
   is handled by hardware forwarding engines.  While high-performance
   NAT boxes may be built, protocols that open many sessions instead of
   multiplexing will be slower than those that do not.

新しいセッション設立は、エンジンを進めながら、実装さえにおけるパケットごとの翻訳業務がハードウェア的に扱われるソフトウェア機能のままで通常残るでしょう。 高性能NAT箱が造られるかもしれない間、マルチプレクシングの代わりに多くのセッションに開くプロトコルはそうしないそれらよりさらに遅くなるでしょう。

   Applications with different types of data, such as interactive
   conferencing, require separate streams for the different types of
   data.  In such cases the protocol needs of each stream must be
   optimized.  While the goal of multiplexing over a single session is
   preferred, clearly there are cases where this is impractical.

異なったタイプに関する対話的な会議などのデータがあるアプリケーションは異なったタイプに関するデータのために別々のストリームを必要とします。 そのような場合それぞれのストリームのプロトコルの必要性を最適化しなければなりません。 ただ一つのセッションの間、多重送信するという目標は好まれますが、ケースがこれが非実用的であるところに明確にあります。

   The latency of NAT translation overhead is implementation dependent.
   On a per-packet basis, for established sessions only the source or
   destination IP address is replaced, the source or destination port
   (for NAPT) and the checksums for IP, and TCP or UDP are recalculated.

NAT翻訳オーバーヘッドの潜在は実装に依存しています。 1パケットあたり1個のベースでは、確立したセッションだけのために、ソースか送付先IPアドレスを取り替えます、ソースか目的地はポート(NAPTのための)とIPのためのチェックサムをソースです、そして、TCPかUDPが再計算されます。

Senie                        Informational                     [Page 10]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[10ページ]のRFC3235NAT

   The functionality can be efficiently implemented in hardware or
   software.

ハードウェアかソフトウェアで効率的に機能性を実装することができます。

4. Security Considerations

4. セキュリティ問題

   Network Address Translators have implications for IPSec, as noted
   above.  When application developers are considering whether their
   applications function with NAT implementations, care should be given
   to selection of security methodology.  Transport Layer Security (TLS)
   [RFC2246] operates across translation boundaries.  End-to-end IPSec
   will prove problematic in many cases.

ネットワークAddress Translatorsには、IPSecのための意味が上に述べられるようにあります。 アプリケーション開発者が、彼らのアプリケーションがNAT実装で機能するかどうか考えているとき、セキュリティ方法論の選択に注意を与えるべきです。 輸送Layer Security(TLS)[RFC2246]は翻訳限界の向こう側に作動します。 多くの場合、終わりから終わりへのIPSecは、問題が多いと判明するでしょう。

5. References

5. 参照

   [RFC1579]   Bellovin, S., "Firewall Friendly FTP", RFC 1579, February
               1994.

[RFC1579] Bellovin、S.、「ファイアウォールの好意的なFTP」、RFC1579、1994年2月。

   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [RFC2993]   Hain, T., "Architectural Implications of NAT", RFC 2993,
               November 2000.

[RFC2993] ハイン、T.、「NATの建築含意」、RFC2993、2000年11月。

   [RFC3027]   Holdrege, M. and P. Srisuresh, "Protocol Complications
               with the IP Network Address Translator (NAT)", RFC 3027,
               January 2001.

[RFC3027]HoldregeとM.とP.Srisuresh、「IPネットワークアドレス変換機構(NAT)とのプロトコル複雑さ」、RFC3027、2001年1月。

   [RFC2663]   Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

[RFC2663] SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。

   [RFC2709]   Srisuresh, P., "Security Model with Tunnel-mode IPsec for
               NAT Domains", RFC 2709, October 1999.

[RFC2709]Srisuresh、P.、「NATドメインへのトンネルモードIPsecの機密保護モデル」、RFC2709、1999年10月。

   [RFC3102]   Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
               "Realm Specific IP: Framework", RFC 3102, October 2001.

[RFC3102] Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「フレームワーク」、RFC3102、2001年10月。

   [RFC3022]   Srisuresh, P. and K. Egevang, "Traditional IP Network
               Address Translator (Traditional NAT)", RFC 3022, January
               2001.

[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。

   [RFC2694]   Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
               Heffernan, "DNS extensions to Network Address Translators
               (DNS_ALG)", RFC 2694, September 1999.

[RFC2694]SrisureshとP.とTsirtsisとG.、AkkirajuとP.とA.ヘファーナン、「Network Address Translators(DNS_ALG)へのDNS拡張子」RFC2694(1999年9月)。

Senie                        Informational                     [Page 11]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[11ページ]のRFC3235NAT

6. Acknowledgements

6. 承認

   I'd like to thank Pyda Srisuresh for his invaluable input and
   feedback, and Keith Moore for his extensive comments.

彼の非常に貴重な入力とフィードバックについてPyda Srisureshに感謝します、そして、私は、彼の大規模なコメントのためにキース・ムーアに感謝したいです。

7. Author's Address

7. 作者のアドレス

   Daniel Senie
   Amaranth Networks Inc.
   324 Still River Road
   Bolton, MA 01740

それでも、川のRoadボルトン、ダニエルSenieケイトウネットワーク株式会社324MA 01740

   Phone: (978) 779-6813
   EMail: dts@senie.com

以下に電話をしてください。 (978) 779-6813 メールしてください: dts@senie.com

Senie                        Informational                     [Page 12]

RFC 3235       NAT Friendly Application Design Guidelines   January 2002

アプリケーション設計ガイドライン2002年1月に好意的なSenieの情報[12ページ]のRFC3235NAT

8.  Full Copyright Statement

8. 完全な著作権宣言文

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

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

Senie                        Informational                     [Page 13]

Senie情報です。[13ページ]