この文書はRFC4084の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group J. Klensin
Request for Comments: 4084 May 2005
BCP: 104
Category: Best Current Practice
Terminology for Describing Internet Connectivity
インターネット接続性を記述する用語
Status of This Memo
この文書の状態
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
この文書はインターネットコミュニティーのための現在のインターネットの
最良実践を指定して、そして改良のために議論と提案を求めます。このメモ
の配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Abstract
要約
As the Internet has evolved, many types of arrangements have been
advertised and sold as "Internet connectivity". Because these may
differ significantly in the capabilities they offer, the range of
options, and the lack of any standard terminology, the effort to
distinguish between these services has caused considerable consumer
confusion. This document provides a list of terms and definitions
that may be helpful to providers, consumers, and, potentially,
regulators in clarifying the type and character of services being
offered.
インターネットが進展するにつれて、多くの種類の協定が宣伝され、「イン
ターネット接続性」として売られました。これらが提供する能力やオプショ
ンの範囲がかなり異なるかもしれず、標準的な用語がないので、これらのサー
ビスを区別する努力は相当な消費者の混乱を起こしました。この文書は、提
供されているサービスの型と特徴を明確にする際に、プロバイダと消費者と、
潜在的に、規定者に役立つかもしれない用語と定義のリストを提供します。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. The Problem and the Requirement
1.1. 問題と必要条件
1.2. Adoption and a Non-pejorative Terminology
1.2. 採用と非軽蔑語
2. General Terminology
2. 一般的な専門用語
3. Filtering or Security Issues and Terminology
3. フィルタリングあるいはセキュリティ問題と用語
4. Additional Terminology
4. 追加の用語
5. Security Considerations
5. セキュリティの考察
6. Acknowledgements
6. 謝辞
7. Informative References
7. 有益な参考文献
1. Introduction
1. はじめに
1.1. The Problem and the Requirement
1.1. 問題と必要条件
Different ISPs and other providers offer a wide variety of products
that are identified as "Internet" or "Internet access". These
products offer different types of functionality and, as a result,
some may be appropriate for certain users and uses and not others.
For example, a service that offers only access to the Web (in this
context, the portion of the Internet that is accessible via the HTTP
and HTTPS protocols) may be appropriate for someone who is
exclusively interested in browsing and in Web-based email services.
It will not be appropriate for someone who needs to download files or
use email more frequently. And it is likely to be even less
appropriate for someone who needs to operate servers for other users,
who needs virtual private network (VPN) capabilities or other secured
access to a remote office, or who needs to synchronize mail for
offline use.
様々なＩＳＰと他のプロバイダが多種多様な商品を「インターネット」ある
いは「インターネット・アクセス」として提供します。これらの商品は異な
る種類のの機能を提供し、そして、結果として、ある特定のユーザの使用に
は適切で、他には適切でないかもしれません。例えば、ただウェブ（ここで
は、HTTPとHTTPSプロトコルでアクセス可能なインターネットの部分のこと）
へのアクセスだけを提供するサービスでも、ブラウジングとウェブベースの
電子メールサービスにだけ興味を持っている人には適切かもしれません。こ
れはファイルをダウンロードするか、よりしばしば電子メールを使う必要が
ある誰かには適切ではないでしょう。そしてこれは他のユーザのためにサー
バを操作する必要がある人や、仮想私設網（ＶＰＮ）能力やその他の遠隔オ
フィスへの安全なアクセスを必要とする人や、オフラインでの使用のために
メールを同期させる必要がある人には適切でない可能性が高いです。
Recent and rapidly evolving changes to the Internet's email
environment have led to additional restrictions on sending and
retrieving email. These restrictions, most of them developed as part
of well intentioned attempts to prevent or fight unsolicited mail,
may be imposed independently of the service types described below and
are discussed separately in Section 3.
インターネットの電子メール環境に対する最近の急速に進化する変更が、電
子メールの送信と検索について、追加の制限をもたらしました。これらの制
限は、大部分が望まれないメールを妨げるか戦うための善意で行なわれた試
みとして開発され、るという状態で、サービス種別と無関係に課されるかも
しれず、そして３章で別に論じられます。
This document describes only the functions provided or permitted by
the service provider. It does not and cannot specify the functions
that pass through and are supported by various user-provided
equipment.
この文書はサービスプロバイダによって提供されるか、あるいは認められた
機能だけを述べます。これは通過するあるいは種々なユーザが提供する装置
によってサポートされる機能を指定せず、することもできません。
The terms SHOULD, MUST, or MAY are capitalized in this document, as
defined in [1].
文書で大文字の用語SHOULDとMUSTとMAYは[1]で定義される通りです。
1.2. Adoption and a Non-pejorative Terminology
1.2. 採用と非軽蔑語
The definitions proposed here are of little value if service
providers and vendors are not willing to adopt them. The terms
proposed are intended not to be pejorative, despite the belief of
some members of the IETF community that some of these connectivity
models are simply "broken" or "not really an Internet service". The
mention of a particular service or model in this document does not
imply any endorsement of it, only recognition of something that
exists or might exist in the marketplace. Thus, the Best Current
Practice described in this document is about terminology and
information that should be supplied to the user and not about the
types of service that should be offered.
ここで提案された定義は、もしサービスプロバイダとベンダが採用しなけれ
ば、価値がほとんどありません。ＩＥＴＦの一部のメンバーが接続性モデル
のいくつかは「壊れてる」あるいは「真のインターネットサービスでない」
といっていますが、用語は軽蔑を意図しません.この文書での特定のサービス
やモデルの言及は、その公認を意味するのではなく、ただ市場に存在するか、
存在するかもしれないとの認識を示すだけです。それで、この文書で記述さ
れた現在の最良実践は、提供されるべきサービスの種類を言うのではなく、
ユーザに供給されるべきである用語と情報の事です。
2. General Terminology
2. 一般的な専門用語
This section lists the primary IP service terms. It is hoped that
service providers will adopt these terms, to better define the
services to potential users or customers. The terms refer to the
intent of the provider (ISP), as expressed in either technical
measures or terms and conditions of service. It may be possible to
work around particular implementations of these characteristic
connectivity types, but that freedom is generally not the intent of
the provider and is unlikely to be supported if the workarounds stop
working.
この章は主要なＩＰサービス用語を列挙します。潜在的なユーザや顧客にサー
ビスをより良く伝えるために、サービスプロバイダがこれらの用語を採用す
ることが望まれます。技術基準や、サービスの金額及びその他の条件で表明
されるように、用語はプロバイダ（ＩＳＰ）の意志に関係します。特有の接
続種別の特定の実装に取り組むことは可能かもしれませんが、しかしその自
由は一般にプロバイダの意志ではなく、そして、もし回避策が仕事を止める
なら、サポートされることがなさそうです。
The service terms are listed in order of ascending capability, to
reach "full Internet connectivity".
サービス用語は、「完全インターネット接続」に達する方向に、能力の上昇
順に列挙されます。
o Web connectivity.
o ウェブ接続
This service provides connectivity to the Web, i.e., to services
supported through a "Web browser" (such as Firefox, Internet
Explorer, Mozilla, Netscape, Lynx, or Opera), particularly those
services using the HTTP or HTTPS protocols. Other services are
generally not supported. In particular, there may be no access to
POP3 or IMAP4 email, encrypted tunnels or other VPN mechanisms.
このサービスはウェブへの接続を供給します、すなわち、「ウェブブラウ
ザ」（例えば、FirefoxやInternet ExplorerやMozillaやNetscapeやLynx
やOpera）によるサービスのサポート、特にHTTPやHTTPSを使うサービスを
提供します。他のサービスが一般にサポートされません。特に、POP3や
IMAP4電子メールや、暗号化トンネルや、他のＶＰＮ機構をのアクセスが
ありません。
The addresses used may be private and/or not globally reachable.
They are generally dynamic (see the discussion of dynamic
addresses in Section 3 for further discussion of this terminology
and its implications) and relatively short-lived (hours or days
rather than months or years). These addresses are often announced
as "dynamic" to those who keep lists of dial-up or dynamic
addresses. The provider may impose a filtering Web proxy on the
connections; that proxy may change and redirect URLs to other
sites than the one originally specified by the user or embedded
link.
使われるアドレスはプライベートで、世界的に到達可能でないかもしれま
せん。これらは一般に動的で（この用語とその暗示するものは、３章の動
的アドレスの議論を参照）、そして比較的短命（月や年ではなく、時や日）
です。これらのアドレスはダイアルアップあるいは動的アドレスのリスト
を守る人たちにしばしば「動的」と発表されます。プロバイダは接続にフィ
ルタリングウェブプロクシを課すかもしれません；そのプロクシはユーザ
や埋め込みリンクで指定されたＵＲＬを他のサイトのＵＲＬに変えてて転
送するかもしれません。
o Client connectivity only, without a public address.
o クライアント接続性のみ、公共アドレスなし
This service provides access to the Internet without support for
servers or most peer-to-peer functions. The IP address assigned
to the customer is dynamic and is characteristically assigned from
non-public address space. Servers and peer-to-peer functions are
generally not supported by the network address translation (NAT)
systems that are required by the use of private addresses. (The
more precise categorization of types of NATs given in [2] are
somewhat orthogonal to this document, but they may be provided as
additional terms, as described in Section 4.)
このサービスはサーバのサポートなし、あるいは、ほとんどのピア対ピア
機能のサポートなしで、インターネットへのアクセスを提供します。顧客
に割り当てられたＩＰアドレスは動的で、特徴として非公共アドレス空間
から割り当てられます。サーバとピア対ピア機能が、一般に、私的アドレ
スの使用に必要なネットワークアドレス翻訳（ＮＡＴ）システムによって
サポートされません。（[2]で与えられたＮＡＴ種別のより正確な分類は
この文書にほとんど無関係ですが、４章で記述されるように、追加の条件
として提供されるかもしれません。）
Filtering Web proxies are common with this type of service, and
the provider SHOULD indicate whether or not one is present.
フィルタリングウェブプロクシはこの種類のサービスで一般的で、プロバ
イダは存在しているかどうかを示すべきです(SHOULD)。
o Client only, public address.
o クライアントのみ、公共アドレス
This service provides access to the Internet without support for
servers or most peer-to-peer functions. The IP address assigned
to the customer is in the public address space. It is usually
nominally dynamic or otherwise subject to change, but it may not
change for months at a time. Most VPN and similar connections
will work with this service. The provider may prohibit the use of
server functions by either legal (contractual) restrictions or by
filtering incoming connection attempts.
このサービスはサーバやほとんどのピア対ピア機能のサポートなしでイン
ターネットへのアクセスを提供します。顧客に割り当てられたＩＰアドレ
スは公共アドレス空間にあります。これは通常名目上は動的か変化しえま
すが、何カ月間も変化しないかもしれません。たいていのＶＰＮに類似す
る接続がこのサービスで作動するでしょう。プロバイダは法的（契約）制
限や、入接続のフィルタリングによって、サーバ機能の使用を禁止するか
もしれません。
Filtering Web proxies are uncommon with this type of service, and
the provider SHOULD indicate if one is present.
フィルタリングウェブプロキシはこの種類のサービスで一般的でありませ
ん、そしてプロバイダは存在しているかどうかを示すべきです(SHOULD)。
o Firewalled Internet Connectivity.
o ファイアウォールインターネット接続性
This service provides access to the Internet and supports most
servers and most peer-to-peer functions, with one or (usually)
more static public addresses. It is similar to "Full Internet
Connectivity", below, and all of the qualifications and
restrictions described there apply. However, this service places
a provider-managed "firewall" between the customer and the public
Internet, typically at customer request and at extra cost compared
to non-firewalled services. Typically by contractual arrangements
with the customer, this may result in blocking of some services.
このサービスはインターネットへのアクセスと、そして、１つ以上の静的
公共アドレスにより、たいていのサーバとたいていのピア対ピア機能を提
供します。これは下記の「完全インターネット接続」に類似し、そしてこ
こに記述された資格と制限のすべては適用されます。しかしながら、この
サービスは顧客と公共インターネット間にプロバイダ管理のファイアウォー
ルを置き、一般に非ファイアウォールサービスに比べて、顧客の要求と余
分のコストが必要です。一般に顧客に対する契約協定によって、あるサー
ビスを阻止するかもしれません。
Other services may be intercepted by proxies, content-filtering
arrangements, or application gateways. The provider SHOULD
specify which services are blocked and which are intercepted or
altered in other ways.
他のサービスがプロキシや内容フィルタリング協定やアプリケーションゲー
トウェイによって途中で捕えられるかもしれません。プロバイダはどのサー
ビスが阻止されるか明示するべきです(SHOULD)、そしてこれは途中で捕え
られるか、あるいは他の方法で変えられます。
In most areas, this service arrangement is offered as an add-on,
extra-cost, option with what would otherwise be Full Internet
Connectivity. It is distinguished from the models above by the
fact that any filtering or blocking services are ultimately
performed at customer request, rather than being imposed as
service restrictions.
たいていのエリアで、このサービス協定は完全インターネット接続に対す
る追加、追加コストオプションとして提示されます。これは上記のモデル
と、フィルタやブロッキングサービスが、サービス制限として課されるの
ではなく、究極的に顧客要請で行われるという事実によって区別されます。
o Full Internet Connectivity.
o 完全インターネット接続
This service provides the user full Internet connectivity, with
one or more static public addresses. Dynamic addresses that are
long-lived enough to make operating servers practical without
highly dynamic DNS entries are possible, provided that they are
not characterized as "dynamic" to third parties.
このサービスは、１つ以上の静的公共アドレスで、ユーザに完全インター
ネット接続を提供します。十分長命な動的アドレスは、第三者に「動的」
と言わずに、動的ＤＮＳ項目無しで、運用上実際的なサーバが可能です。
Filtering Web proxies, interception proxies, NAT, and other
provider-imposed restrictions on inbound or outbound ports and
traffic are incompatible with this type of service. Servers on a
connected customer LAN are typically considered normal. The only
compatible restrictions are bandwidth limitations and prohibitions
against network abuse or illegal activities.
フィルタリングウェブプロキシや妨害プロキシやＮＡＴや他の内行きや外
行きのポートやトラフィックのプロバイダによって課された制限はこのタ
イプのサービスと互換性がありません。接続された顧客ＬＡＮ上のサーバ
が一般に正常であると思われます。唯一の共存できる制限はネットワーク
乱用あるいは違法行為に対してのバンド幅限界と禁止令です。
3. Filtering or Security Issues and Terminology
3. フィルタリングあるいはセキュリティ問題と用語
As mentioned in the Introduction, the effort to control or limit
objectionable network traffic has led to additional restrictions on
the behavior and capabilities of internet services. Such
objectionable traffic may include unsolicited mail of various types
(including "spam"), worms, viruses, and their impact, and in some
cases, specific content.
はじめにで述べたように、不快なネットワークトラフィックを制御するか制
限する努力はインターネットサービスの行動と能力に追加の制限をしました。
このような不快なトラフィックは種々な種類の望んでいないメール（「スパ
ム」を含む）や、ワームとウイルスとその影響や、時には特定の内容を含む
かもしれません。
In general, significant restrictions are most likely to be
encountered with Web connectivity and non-public-address services,
but some current recommendations would apply restrictions at all
levels. Some of these mail restrictions may prevent sending outgoing
mail (except through servers operated by the ISP for that purpose),
may prevent use of return addresses of the user's choice, and may
even prevent access to mail repositories (other than those supplied
by the provider) by remote-access protocols such as POP3 or IMAP4.
Because users may have legitimate reasons to access remote file
services, remote mail submission servers (or, at least, to use their
preferred email addresses from multiple locations), and to access
remote mail repositories (again, a near-requirement if a single
address is to be used), it is important that providers disclose the
services they are making available and the filters and conditions
they are imposing.
一般に、意味がある制限はウェブ接続と非公共アドレスのサービスで遭遇す
る可能性が高いですが、しかしある現在の推薦はすべてのレベルで制限を適
用するでしょう。（メール送信の目的でＩＳＰによって運用されているサー
バを使わない場合を除き）これらのメール制限のいくつかの外向メールを送
ることを妨げるかもしれず、ユーザ選択の返送先アドレスの使用を妨げるか
もしれず、ＰＯＰ３やＩＭＡＰ４のような遠隔アクセスプロトコルによる
（プロバイダによって供給された以外の）メール蓄積装置へのアクセスを妨
げさえするかもしれません。ユーザが遠隔ファイルサービスや遠隔メール送
信サーバにアクセスすること（あるいは、少なくとも、多数の場所から優先
電子メールアドレスを使うこと）に合法的な理由を持つかもしれません、そ
して遠隔メール蓄積装置にアクセスするために（単一アドレスを使う場合の
必要条件に近い）、プロバイダが提供しているサービスとフィルタとそれを
実施する条件を明らかにすることは重要です。
Several key issues in email filtering are of particular importance.
電子メールフィルタリングでのいくつかの重要な問題が特に重要です。
o Dynamic Addresses.
o 動的アドレス
A number of systems, including several "blacklist" systems, are
based on the assumption that most undesired email originates from
systems with dynamic addresses, especially dialup and home
broadband systems. Consequently, they attempt to prevent the
addresses from being used to send mail, or perform some other
services, except through provider systems designated for that
purpose.
いくつかの「ブラックリスト」システムを含む多くのシステムが、ほとん
どの迷惑電子メールが動的アドレス、特にダイアルアップと家庭広帯域シ
ステムに起源するという仮定に基づいています。従って、その目的のため
にプロバイダシステムが指定する通信を除き、それらのアドレスからのメー
ル送信や他のサービスを阻止しようと試みます。
Different techniques are used to identify systems with dynamic
addresses, including provider advertising of such addresses to
blacklist operators, heuristics that utilize certain address
ranges, and inspection of reverse-mapping domain names to see if
they contain telltale strings such as "dsl" or "dial". In some
cases, the absence of a reverse-mapping DNS address is taken as an
indication that the address is "dynamic". (Prohibition on
connections based on the absence of a reverse-mapping DNS record
was a technique developed for FTP servers many years ago; it was
found to have fairly high rates of failure, both prohibiting
legitimate connection attempts and failing to prevent illegitimate
ones). Service providers SHOULD describe what they are doing in
this area for both incoming and outgoing message traffic, and
users should be aware that, if an address is advertised as
"dynamic", it may be impossible to use it to send mail to an
arbitrary system even if Full Internet Connectivity is otherwise
provided.
動的アドレスを識別するシステムに、ブラックリストオペレータへのプロ
バイダからの通知、ーをに載せるためのこのようなアドレスのプロバイダ
広告を含めて、ある特定のアドレス範囲やドメイン名の逆引きして"dsl"
や"dial"等の文字列の発見など、他の技術が使われます。 ある場合に、
逆引きＤＮＳアドレスの欠如はアドレスが動的であるという表示であると
思われます。（接続でＤＮＳレコードの逆引きの欠如に基づく禁止は何年
も前にＦＴＰサーバで展開された方法でした；これは正当な接続を妨げ、
不法の接続を妨げ損ねる確率がかなり高いことが判明しました）。サービ
スプロバイダが入りと出のメッセージトラフィックに対しこの分野で何を
しているか記述するべきです(SHOULD)、そして、もしアドレスが「動的」
と宣伝されるなら、ユーザはそれを、たとえこれ以外では完全インターネッ
ト接続性が供給されるとしても、メールを任意のシステムに送るために使
うことが不可能であるかもしれないことを知るべきです。
o Non-public addresses and NATs.
o 非公共アドレスとＮＡＴ
The NAT systems that are used to map between private and public
address spaces may support connections to distant mail systems for
outbound and inbound mail, but terms of service often prohibit the
use of systems not supplied by the connectivity provider and
prohibit the operation of "servers" (typically not precisely
defined) on the client connection.
私的と公共のアドレス空間を対応付けるＮＡＴシステムは外行きと内行き
のメールのために遠隔メールシステムをサポートするかもしれませんが、
サービス条件でしばしば接続性プロバイダによって供給されないシステム
の使用を禁止して、そしてクライアント接続で「サーバ」（一般に正確に
定義されない）のオペレーションを禁止します。
o Outbound port filtering from the provider.
o プロバイダからの外行きのポートフィルタリング
Another common technique involves blocking connections to servers
outside the provider's control by blocking TCP "ports" that are
commonly used for messaging functions. Different providers have
different theories about this. Some prohibit their customers from
accessing external SMTP servers for message submission, but they
permit the use of the mail submission protocol ([3]) with sender
authentication. Others try to block all outgoing messaging-
related protocols, including remote mail retrieval protocols;
however, this is less common with public-address services than
those that are dependent on private addresses and NATs. If this
type of filtering is present, especially with "Client only, public
address" and "Full Internet Connectivity" services, the provider
MUST indicate that fact (see also Section 4).
プロバイダの管理外のサーバへの接続を阻止する他の一般的な方法は、メッ
セージ交換に一般に使われるＴＣＰ「ポート」をふさぐことです。異なる
プロバイダがこれについて異なる理論を持っています。ある者は顧客がメッ
セージ送信のために外部ＳＭＴＰサーバにアクセスすることを禁じます、
しかし送信者認証付きのメール送信プロトコル（[3]）の使用を認めます。
他の者は、遠隔メール検索プロトコルを含めて、すべての外向メッセージ
送信に関連したプロトコルを阻止しようとします；しかしながら、これは
公共アドレスのサービスは、私的アドレスとＮＡＴに依存している場合ほ
ど一般的ではありません。もしこの種類のフィルタリングが存在している
なら、特に「クライアントのみ、公共アドレス」と「完全インターネット
接続」サービスで、プロバイダはその事実を示さなければなりません
(MUST)（４章参照）。
Still others may divert (reroute) outbound email traffic to their
own servers, on the theory that this eliminates the need for
reconfiguring portable machines as they connect from a different
network location. Again, such diversion MUST be disclosed,
especially since it can have significant security and privacy
implications.
また別の者は、異なるネットワーク位置でポータブルマシンを接続する時、
ポータブルマシンの再設を不要にするためという理屈で、外行き電子メー
ルトラフィックを彼らのサーバにそらす（ルート変更）かもしれません。
このような転送は、これがセキュリティとプライバシの点で重大な意味が
あるので、特に、明らかにされなくてはなりません。
More generally, filters that block some or all mail being sent to
(or submitted to) remote systems (other than via provider-
supported servers), or that attempt to divert that traffic to
their own servers, are, as discussed above, becoming common and
SHOULD be disclosed.
より一般に、上記の様な、一部あるいは全部の、（プロバイダのサポート
されたサーバ経由以外で）遠隔システムへ送るメール、あるいはから受取
るメールを阻止するフィルタ、あるいは彼ら自身のサーバにトラフィック
をそらす試みは、共通で、そして公表されるべきです(SHOULD)。
4. Additional Terminology
4. 追加の用語
These additional terms, while not as basic to understanding a service
offering as the ones identified above, are listed as additional
information that a service provider might choose to provide to
complement those general definitions. A potential customer might use
those that are relevant to construct a list of specific questions to
ask, for example.
これらの追加の用語は、人が上に識別したほどサービス提供を理解できなく
ても、サービスプロバイダが一般的な定義を補完するために提供する追加の
情報として列挙します。 顧客がこれらを例えば特定の質問のリストを組み立
てるために使うかもしれません。
o Version support.
o 版サポート
Does the service include IPv4 support only, both IPv4 and IPv6
support, or IPv6 support only?
サービスはＩＰｖ４サポートのみ、ＩＰｖ４とＩＰｖ６両方のサポート、
あるいはＩＰｖ６サポートのみを含みますか？
o Authentication support.
o 認証サポート
Which technical mechanism(s) are used by the service to establish
and possibly authenticate connections? Examples might include
unauthenticated DHCP, PPP, RADIUS, or HTTP interception.
接続の確立と、もしかすると認証のサービスで、どの技術的機構が使われ
ますか？例えば、認証ＤＨＣＰ、ＰＰＰ、ＲＡＤＩＵＳ、ＨＴＴＰ遮断、
かもしれません。
o VPNs and Tunnels.
o ＶＰＮとトンネル
Is IPSec blocked or permitted? Are other tunneling techniques at
the IP layer or below, such as L2TP, permitted? Is there any
attempt to block applications-layer tunnel mechanisms such as SSH?
ＩＰｓｅｃはブロックされるか許可されますか？ＩＰ層、あるいはＬ２Ｔ
Ｐの様なその下の、他のトンネル技術が認められますか？ＳＳＨのような
アプリケーション層トンネルメカニズムを阻止する試みがありますか？
o Multicast support
o マルチキャストサポート
Does the user machine have access to multicast packets and
services?
ユーザマシンはマルチキャストパケットへのアクセスとサービスを持ちま
すか？
o DNS support.
o ＤＮＳサポート
Are users required to utilize DNS servers provided by the service
provider, or are DNS queries permitted to reach arbitrary servers?
ユーザはサービスプロバイダの提供するＤＮＳサーバを利用するように要
求されますか、あるいはＤＮＳ要求は任意のサーバに届くのを許されます
か？
o IP-related services.
o ＩＰ関連サービス
Are ICMP messages to and from end user sites generally blocked or
permitted? Are specific functions such as ping and traceroute
blocked and, if so, at what point in the network?
エンドユーザサイトに/からのＩＣＭＰメッセージが一般に阻止されます
か、許可されますか？pingやtraceroute等の特定の機能は阻止されますか、
もしそうなら、ネットワークのどの点でですか？
o Roaming support.
o ローミングサポート
Does the service intentionally include support for IP roaming and,
if so, how is this defined? For "broadband" connections, is some
dialup arrangement provided for either backup or customer travel?
If present, does that arrangement have full access to mailboxes,
etc.
サービスはＩＰローミングをサポートしますか、、もしそうなら、これは
どのように定義されますか？「広帯域」接続で、バックアップあるいは顧
客の旅行のために、ダイアルアップが提供されますか？もし存在するなら、
その規定はメールボックスなどへの完全アクセスがありますか。
o Applications services provided.
o アプリケーションサービス供給
Are email services and/or Web hosting provided as part of the
service, and on what basis? An email services listing should
identify whether POP3, IMAP4, or Web access are provided and in
what combinations, and what types of authentication and privacy
services are supported or required for each.
電子メールサービスやウェブ・ホスティング機能がサービスの一部として
提供されますか、どんな原則ですか？電子メールサービスはＰＯＰ３やＩ
ＭＡＰ４やウェブアクセスをどの組合せで供給し、それぞれどの種類の認
証とプライバシサービスが供給あるいは要求されるか明らかにするべきで
す。
o Use and Blocking of Outbound Applications Services.
o 外行きアプリケーションサービスの利用と阻止
Does the service block use of SMTP or mail submission to other
than its own servers or intercept such submissions and route them
to its servers? Do its servers restrict the user to use of its
domain names on outbound email? (For email specifically, also see
Section 3 above.) Is the FTP PASV command supported or blocked?
Are blocks or intercepts imposed on other file sharing or file
transfer mechanisms, on conferencing applications, or on private
applications services?
サービスは自信のサーバ以外とのＳＭＴＰやメール転送の使用を阻止しま
すか、このような転送を横取りし自信のサーバに転送しますか？そのサー
バは外行きの電子メールで、ユーザがそのドメイン名を使用する様に限定
しますか？（特に電子メールで、上記の３章を見てください。）FTP PASV
コマンドはサポートされますか、阻止されますか？他のファイル共有や
ファイル転送機構や会議アプリケーションや私的アプリケーションサービ
スに、阻止や横取りが行われますか？
More generally, the provider should identify any actions of the
service to block, restrict, or alter the destination of, the
outbound use (i.e., the use of services not supplied by the
provider or on the provider's network) of applications services.
いっそう一般に、プロバイダはアプリケーションサービス（すなわち、プ
ロバイダやプロバイダのネットワーク以外の供給するサービス）の外行き
使用の阻止や限定や宛先を変えるサービスの行動を認識するべきです。
o Blocking of Inbound Applications Services.
o 内行きアプリケーションサービスの阻止
In addition to issues raised by dynamic or private address space
(when present), does the service take any other measures that
specifically restrict the connections that can be made to
equipment operated by the customer? Specifically, are inbound
SMTP, HTTP or HTTPS, FTP, or various peer-to-peer or other
connections (possibly including applications not specifically
recognized by the provider) prohibited and, if so, which ones?
動的あるいは私的アドレス空間（もしあれば）によって提起された問題の
ほかに、サービスは顧客の操作する装置の作る接続を特に制限する何らか
の処置をしますか？特に、内行きのＳＭＴＰやＨＴＴＰやＨＴＴＰＳやＦ
ＴＰや様々なピア対ピアや他の接続（プロバイダによって認識されないア
プリケーションを含む）は禁止されますか、されるとしたらどれですか？
o Application Content Filtering.
o アプリケーション内容フィルタリング
The service should declare whether it provides filtering or
protection against worms or denial of service attacks against its
customers, virus and spam filtering for its mail services (if
any), non-discretionary or "parental control" filtering of
content, and so on.
サービスは顧客へのワームあるいはサービス妨害攻撃へのフィルタリング
や保護、メールサービス（あれば）ウイルスとスパムフィルタリング、コ
ンテンツンに対する強制あるいは「親のコントロール」フィルタリングを
提供するかどうか意志表示するべきです。
o Wiretapping and interception.
ｏ 盗聴と妨害
The service SHOULD indicate whether traffic passing through it is
subject to lawful intercept, and whether the provider will make a
proactive attempt to inform the user of such an intercept when
such notice is legal. Analogous questions can be asked for
traffic data that is stored for possible use by law enforcement.
サービスは通過トラフィックが合法的な傍受の適用を受けているか、そし
て、このような通知が合法的であるとき、プロバイダがユーザにこのよう
な傍受を前もって知らせるかどうかを示すべきです(SHOULD)。同様の質問
が法の執行によって使用可能なように保管されるトラフィックデータにも
言えます。
5. Security Considerations
5. セキュリティの考察
This document is about terminology, not protocols, so it does not
raise any particular security issues. However, if the type of
terminology that is proposed is widely adopted, it may become easier
to identify security-related expectations of particular hosts, LANs,
and types of connections.
この文書は用語に関するもので、プロトコルではなく、それで特定のセキュ
リティーの問題を提起しません。しかしながら、もし提案される用語が広く
採用されるなら、特定のホストのセキュリティー関連の期待、接続のＬＡＮ
と種類の識別がより容易になるかもしれません。
6. Acknowledgements
6. 謝辞
This document was inspired by an email conversation with Vernon
Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been
proposals to produce such definitions for many years, that
conversation convinced the author that it was finally time to put a
strawman on the table to see if the IETF could actually carry it
forward. Harald Alvestrand, Brian Carpenter, George Michaelson,
Vernon Schryver, and others made several suggestions on the initial
draft that resulted in clarifications to the second one and Stephane
Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, David Kessens,
Pekka Savola, and Vernon Schryver made very useful suggestions that
were incorporated into subsequent versions. Susan Harris also gave
the penultimate version an exceptionally careful reading, which is
greatly appreciated, as are editorial suggestions by the RFC Editor.
この文書はVernon SchryverとPaul VixieとNathaniel Bornsteinの電子メー
ルの会話で起こりました。何年間もこのような定義を作り出す提案がありま
したが、この会話で著者は、もしＩＥＴＦが実際にこれを進展させるなら、
議論のたたき台を出す時期だと確信しました。Harald Alvestrandと
Brian CarpenterとGeorge MichaelsonとVernon Schryverやその他の人が最
初のドラフトに提案を行い、２番目のドラフトを明確にし、そして
Stephane BortzmeyerとBrian CarpenterとTony FinchとSusan Harrisと
David KessensとPekka SavolaとVernon Schryverは次の版に取り入れられた
非常に有用な提案をしました。Susan Harrisは同じく最後から２番目の版を
注意深く読み、とても感謝したい、ＲＦＣ編集者としての編集の提案を与え
ました。
7. Informative References
7. 有益な参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
Author's Address
著者のアドレス
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2005).
著作権（Ｃ）インターネット学会（２００５）。
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。