RFC3424 日本語訳
3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF)Across Network Address Translation. L. Daigle, Ed., IAB. November 2002. (Format: TXT=18165 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Daigle, Ed.
Request for Comments: 3424 Internet Architecture Board
Category: Informational IAB
November 2002
ワーキンググループL.Daigle、エドをネットワークでつないでください。コメントのために以下を要求してください。 3424年のインターネット・アーキテクチャ委員会カテゴリ: 情報のIAB2002年11月
IAB Considerations for UNilateral Self-Address Fixing (UNSAF)
Across Network Address Translation
ネットワークアドレス変換の向こう側に(UNSAF)を修理する一方的な自己アドレスのためのIAB問題
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
要約
As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
Network Address Translation(NAT)Middleboxesの自然の結果、1NATsによって切り離される交信終点は彼らの(現在で将来)の同輩のアドレシング分野で有効なアドレスを使用することで自分たちについて言及する方法を知りません。 「一方的な自己アドレス固定(UNSAF)」の過程のために様々な提案をしました。 これらはいくつかの由来している終点がそれは別の終点に知られています--プロトコル交換にアドレスデータを使用するか、または例えばそれが接続を受ける場内放送の広告を出すことができるようにアドレス(そして、ポート)を決定するか、または修理するのを試みる過程です。
This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal.
このドキュメントは、UNSAF提案を作成する前に慎重に評価されるために、短期間フィックスであるとこれらの提案をせいぜいみなすことができる理由について特定の問題と特定の問題に概説します。
1. Introduction
1. 序論
As a result of the nature of Network Address (and port) Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers - the address translation is locked within the NAT box. For some purposes, endpoints need to know the addresses (and/or ports) by which they are known to their peers. There are two cases: 1) when the client initiates communication, starting the communication has the side effect of creating an address binding in the NAT device and
Network Address(そして、ポート)翻訳(NAT)Middleboxesの自然の結果、1NATsによって切り離される交信終点は彼らの(現在で将来)の同輩のアドレシング分野で有効なアドレスを使用することで自分たちについて言及する方法を知りません--アドレス変換はNAT箱の中にロックされます。 いくつかの目的のために、終点は、それらが彼らの同輩にとって知られているアドレス(そして/または、ポート)を知る必要があります。 2つのケースがあります: そして1) クライアントがコミュニケーションを開始するときコミュニケーションを始めるのにおいてNAT装置でアドレス結合を作成する副作用がある。
Daigle & IAB Informational [Page 1] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[1ページ]のRFC3424IAB問題
allocating an address in the realm that is external to the NAT box; and 2) a server will be accepting connections from outside, but because it does not initiate communication, no NAT binding is created. In such cases, a mechanism is needed to fix such a binding before communication can take place.
分野のアドレスにそれを割り当てるのはNAT箱に外部です。 そして、2) サーバは外部から接続を受け入れるでしょうが、コミュニケーション、いいえを開始しないので、NAT結合は作成されます。 そのような場合、メカニズムが、コミュニケーションが行われることができる前にそのような結合を修理するのに必要です。
"UNilateral Self-Address Fixing (UNSAF)" is a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
「UNilateral Self-アドレスFixing(UNSAF)」は何らかの由来している過程がそれは知られています--プロトコル交換にアドレスデータを使用するか、または例えばそれが接続を受ける場内放送の広告を出すことができるようにアドレス(そして、ポート)を決定するか、または修理するのを試みる過程です。
There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.
この効果を達成するのを試みるために、発見的教授法と次善策しかありません。 100%の解決策が全くありません。 また、NATsがダイナミックに翻訳を開墾するか、または再調整するかもしれないので、「生きている生活費」と周期的な再世論調査が必要であるかもしれません。 IETFプロトコルで過渡的であるとこれらの次善策の使用を考えなければなりません、そして、より良い建築溶液は求められています。 明白な意志は健全な技術的なアプローチが利用可能であるときに、どんなそのような次善策も非難することです。
2. Architectural issues affecting UNSAF Systems
2. UNSAF Systemsに影響する構造的な問題
Generally speaking, the proposed workarounds are for cases where a standard protocol communication is to take place between two endpoints, but in order for this to occur, a separate step of determining (or fixing) the perceived address of an endpoint in the other endpoint's addressing realm is required. Proposals require that an endpoint seeking to "fix" its address contact a participating service (in a different address realm) to determine (reflect) its address. Thus, there is an "UNSAF client" partnering with some form of "UNSAF service" that may or may not be associated with the target endpoint of the actual desired communication session. Throughout this memo, the terms "UNSAF server" and "UNSAF service" should be understood to generically refer to whatever process is participating in the UNSAF address determination for the originating process (the UNSAF client).
概して、提案された次善策はケースのために2つの終点の間の場所を取る標準プロトコルコミュニケーションがことであるところにありますが、これが起こるように、もう片方の終点のアドレシング分野で終点の知覚されたアドレスを決定する(または、修理します)別々のステップが必要です。 提案は、アドレスを「修理しようとする」終点がアドレスを決定する(反射する)ために、参加サービス(異なったアドレス分野の)に連絡するのを必要とします。 したがって、何らかのフォームの実際の必要なコミュニケーションセッションの目標終点に関連するかもしれない「UNSAFサービス」とパートナーを組む「UNSAFクライアント」があります。 このメモ中では、用語「UNSAFサーバ」と「UNSAFサービス」が一般的に由来している過程(UNSAFクライアント)のためのUNSAFアドレス決断に参加しているどんな過程も示すのが理解されるべきです。
Any users of these workarounds should be aware that specific technical issues that impede the creation of a general solution include:
これらの次善策のどんなユーザも一般解の創造を妨害する特定の専門的な問題はである:意識しているべきです。
o there *is* no unique "outside" to a NAT - it may be impossible to
tell where the target endpoint is with respect to the initiator;
how does an UNSAF client find an appropriate UNSAF server to
reflect its address? (See Appendix C).
o *そこでは、*が「外でNATへの」ユニークではありません--創始者に関して目標終点がどこにあるかを言うのが不可能であるかもしれません;。 UNSAFクライアントは、アドレスを反映するためにどのように適切なUNSAFサーバを見つけますか? (付録Cを見ます。)
Daigle & IAB Informational [Page 2] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[2ページ]のRFC3424IAB問題
o specifically because it is impossible to tell where address realms
are bounded ("inside" or "outside", "private" or "public", or
several "private" realms routing traffic), an address can only be
determined relative to one specific point in the network. If the
UNSAF service that reflected an UNSAF client's address is in a
different NAT-masqueraded subnet from some other service X that
the client wishes to use, there is _no_ guarantee that the
client's "perceived" address from the UNSAF partner would be the
same as the address viewed from the perspective of X. (See
Appendix C).
o 特にアドレス分野はどこで境界があるかを(“inside"、「個人的である」か「公共」の「外部」、または交通を発送するいくつかの「個人的な」分野)言うのが不可能であるので、アドレスはネットワークにおける特定の1ポイントに比例して決定できるだけです。 クライアントが利用したがっているある他のサービスXと異なったNATで仮装したサブネットにUNSAFクライアントのアドレスを反映したUNSAFサービスがあるなら、_クライアントが、UNSAFパートナーからのアドレスがX.の見解から見られたアドレスと同じであると(Appendix Cを見てください)「知覚した」という_保証が全くありません。
o absent "middlebox communication (midcom)", there is no usable way
to let incoming communications make their way through a middlebox
(NAT, firewall) under proper supervision. By circumventing the
NAT, UNSAF mechanisms may also (inadvertently) circumvent security
mechanisms. The particular danger is that internal machines are
unwittingly exposed to all the malicious communications from the
external side that the firewall is intended to block. This is
particularly unacceptable if the UNSAF process is running on one
machine which is acting on behalf of several.
o 休んでいる「middleboxコミュニケーション(midcom)」、入って来るコミュニケーションにmiddlebox(NAT、ファイアウォール)を正しい指導の下で、擦りぬけさせるどんな使用可能な方法もありません。 また、NATを回避することによって、UNSAFメカニズムは(うっかり)セキュリティー対策を回避するかもしれません。特定の危険は内部のマシンがファイアウォールが立ち塞がるつもりである外部側からのすべての悪意があるコミュニケーションに知らず知らず露出されるということです。 UNSAFの過程が数個を代表して作動している1台のマシンで動くことであるなら、これは特に容認できません。
o proposed workarounds include the use of "ping"-like address
discovery requests sent from the UNSAF client (initiator) to the
UNSAF server (listener), to which the listener responds with the
transport address of the initiator - in the address realm of the
listener. However, with connection-less transports, e.g. UDP,
IPsec ESP, etc., an UNSAF process must take care to react to
changes in NAT bindings for a given application flow, since it may
change unpredictably.
o 提案された次善策はUNSAFクライアント(創始者)からリスナーがリスナーのアドレス分野で創始者の輸送アドレスで応じるUNSAFサーバ(リスナー)に送られた「ピング」のようなアドレス発見要求の使用を含んでいます。 しかしながら、コネクションレスな輸送、例えば、UDP、反応する超能力、など、過程が取らなければならないUNSAFが、気にかけるIPsecと共に、与えられたアプリケーションのためのNAT結合における変化は流れます、予想外に変化するかもしれないので。
o if the UNSAF client uses periodic retries to refresh/reevaluate
the address translation state, both the UNSAF client and the UNSAF
server are required to maintain information about the presumed
state of the communication in order to manage the address
illusion.
o UNSAFクライアントがアドレス変換状態をリフレッシュするか、または再評価するのに周期的な再試行を使用するなら、UNSAFクライアントとUNSAFサーバの両方が、アドレス幻想を管理するためにコミュニケーションの推定された状態の情報を保守するのに必要です。
o since the UNSAF server is not integrated with the middlebox, it
can only operate on the assumption that past behavior is a
predictor of future behavior. It has no special knowledge of the
address translation heuristic or affecting factors.
o UNSAFサーバがmiddleboxと統合されないので、過去の振舞いが今後の振舞いの予言者であることは前提を作動させることができるだけです。 それには、アドレス変換の発見的であるか感激的な要素に関するどんな特別な知識もありません。
o the communication exchange is made more "brittle" by the
introduction of other servers (UNSAF servers) that need to be
reachable in order for the communication to succeed - more boxes
that are "fate sharing" in the communication.
o コミュニケーションが引き継ぐように届く必要がある他のサーバ(UNSAFサーバ)の導入でコミュニケーション交換をより「もろく」します--コミュニケーションの「運命共有」であるより多くの箱。
Daigle & IAB Informational [Page 3] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[3ページ]のRFC3424IAB問題
Workarounds may mitigate some of these problems through tight scoping of applicability and specific fixes. For example:
次善策は適用性と特定のフィックスをきつい見るのによるこれらの問題のいくつかを緩和するかもしれません。 例えば:
o rather than finding the address from "the" outside of the NAT, the
applicability of the approach may be limited to finding the
"self-address" from a specific service, for use exclusively with
that service.
o NATの外では、排他的なそのサービスで使用に関して特定のサービスから「自己アドレス」であることがわかるのにアプローチの適用性が限られるかもしれない“the"からアドレスを見つけるよりむしろ。
o limiting the scope to outbound requests for service (or service
initiation) in order to prevent unacceptable security exposures.
o 容認できないセキュリティ露出を防ぐために範囲をサービス(または、サービス開始)を求める外国行きの要求に制限します。
3. Practical Issues
3. 実用的な問題
From observations of deployed networks, it is clear that different NAT box implementations vary widely in terms of how they handle different traffic and addressing cases.
配備されたネットワークの観測によって、それらがどう異なった交通とアドレシングケースを扱うかに関して異なったNAT箱の実現がばらつきが大きいのは、明確です。
Some of the specific types of observed behaviors have included:
観測された振舞いの何人かの特定のタイプが含みました:
o NATs may drop fragments in either direction: without complete
TCP/UDP headers, the NAT may not make the address translation
mapping, simply dropping the packet.
o NATsはどちらの方向にも断片を落とすかもしれません: 完全なTCP/UDPヘッダーがなければ、単にパケットを落として、NATはアドレス変換マッピングを作らないかもしれません。
o Shipping NATs often contain Application Layer Gateways (ALGs)
which attempt to be context-sensitive, depending on the source or
destination port number. The behavior of the ALGs can be hard to
anticipate and these behaviors have not always been documented.
o 送料NATsはしばしば文脈依存しているのを試みるApplication Layer Gateways(ALGs)を含んでいます、ソースか目的地ポートナンバーに頼っていて。 ALGsの動きは予期するのが困難である場合があります、そして、これらの振舞いはいつも記録されるというわけではありませんでした。
o Most NAT implementations with ALGs that attempt to translate TCP
application protocols do not perform their functions correctly
when the substrings they must translate span across multiple TCP
segments; some of them are also known to fail on flows that use
TCP option headers, e.g. timestamps.
o それらが翻訳しなければならないサブストリングが複数のTCPセグメントの向こう側にわたる場合、TCPアプリケーション・プロトコルを翻訳するのを試みるALGsとのほとんどのNAT実現は正しくそれらの機能を実行しません。 また、それらのいくつかがTCPオプションヘッダーを使用する流れ、例えば、タイムスタンプで失敗するのが知られています。
o NAT implementations differ markedly in their handling of packets.
Quite a few only really work reliably with TCP packets, not UDP.
Of the ones that do make any attempt to handle UDP packets, the
timers aging out flows can vary widely making it challenging to
predict behavior.
o NAT実現は彼らのパケットの取り扱いにおいて著しく異なります。 多数が本当にUDPではなく、TCPパケットで確かに働いているだけです。 UDPを扱うどんな試みもパケットにするものでは、出ている流れに年をとらせるタイマは、振舞いを予測するのをやりがいがあるようにしながら、ばらつきが大きいことができます。
o Variation in address and port assignments can be quite frequent -
on NATs, port numbers always change, and change unpredictably;
there may be multiple NATs in parallel for load-sharing, making IP
address variations quite likely as well.
o アドレスとポート課題の変化はかなり頻繁である場合があります--NATsでは、ポートナンバーは、いつも変化して、予想外に変化します。 IPアドレス変化をまた、かなりありそうにして、負荷分割法に、平行な複数のNATsがあるかもしれません。
Daigle & IAB Informational [Page 4] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[4ページ]のRFC3424IAB問題
4. Architectural Considerations
4. 建築問題
By distinguishing these approaches as short term fixes, the IAB believes the following considerations must be explicitly addressed in any proposal:
短期間フィックスとしてこれらのアプローチを区別することによって、IABは、どんな提案でも明らかに以下の問題を記述しなければならないと信じています:
1. Precise definition of a specific, limited-scope problem that is
to be solved with the UNSAF proposal. A short term fix should
not be generalized to solve other problems. Such generalizations
lead to the the prolonged dependence on and usage of the supposed
short term fix -- meaning that it is no longer accurate to call
it "short term".
1. UNSAF提案で解決されることになっている特定の、そして、限られた範囲の問題の厳密な定義。 他の問題を解決するために短期間フィックスを一般化するべきではありません。それを「短期間」と呼ぶのがもう正確でないことを意味して、想定された短期間のそのような長引いている依存にオンな一般化リードと用法は修理されます。
2. Description of an exit strategy/transition plan. The better
short term fixes are the ones that will naturally see less and
less use as the appropriate technology is deployed.
2. 撤退戦略/変遷プランの記述。 より良い短期間フィックスは適正技術が配備されるとき自然にますます少ない使用を見るものです。
3. Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition.
3. より「もろく」システムを表すかもしれない特定の問題の議論。 例えば、複数のネットワーク層にデータを使用することを伴うアプローチで、より多くの依存を引き起こして、デバッグ挑戦を増加させて、それは変遷により困難になります。
4. Identify requirements for longer term, sound technical solutions;
contribute to the process of finding the right longer term
solution.
4. より長い期間、健全な技術的解決法のための要件を特定してください。 正しいより長い期間が解決策であることがわかる過程に貢献してください。
5. Discussion of the impact of the noted practical issues with
existing deployed NATs and experience reports.
5. 存在する有名な実用的な問題の影響の議論はNATsと経験レポートを配備しました。
5. Security Considerations
5. セキュリティ問題
As a general class of workarounds, UNSAF proposals may introduce security holes because, in the absence of "middlebox communication (midcom)", there is no feasible way to let incoming communications make their way through a firewall under proper supervision: respecting the firewall policies as opposed to circumventing security mechanisms.
一般的なクラスの次善策として、入って来るコミュニケーションにファイアウォールを正しい指導の下で擦りぬけさせるどんな可能な方法も「middleboxコミュニケーション(midcom)」が不在のときないので、UNSAF提案はセキュリティーホールを紹介するかもしれません: セキュリティー対策を回避することと対照的にファイアウォール方針を尊敬します。
Daigle & IAB Informational [Page 5] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[5ページ]のRFC3424IAB問題
Appendix A. IAB Members at the time of this writing:
この書くこと時点の付録A. IABメンバー:
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
ハラルドAlvestrandはアトキンソンロブAusteinフレッドベイカーレスリーDaigleスティーブデアリングSallyフロイドテッドハーディージェフヒューストンチャーリー・カウフマンジェームスケンフエリックレスコラマイク通りジョーンズを車で送りました。
Appendix B. Acknowledgements
付録B.承認
This document has benefited greatly from detailed comments and suggestions from Thomas Narten, Bernard Aboba, Keith Moore, and James Woodyatt.
このドキュメントは大いにトーマスNarten、バーナードAboba、キース・ムーア、およびジェームスWoodyattから詳細なコメントと提案の利益を得ました。
This document was originally drafted when the following people were part of the IAB: Steve Bellovin, Brian Carpenter, Jon Crowcroft, John Klensin and Henning Schulzrinne; it has benefited considerably from their contributions and review.
元々以下の人々がIABの一部であったときに、このドキュメントは作成されました: ブライアン大工(ジョン・クロウクロフト)のスティーブBellovin、ジョンKlensin、およびヘニングSchulzrinne。 それはかなり彼らの貢献とレビューの利益を得ました。
Daigle & IAB Informational [Page 6] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[6ページ]のRFC3424IAB問題
Appendix C. Example NAT Configuration Scenario
付録C.例のNAT構成シナリオ
C.1 Generic NATed Network Configuration
C.1の一般的なNATedネットワーク・コンフィギュレーション
Here is one sample scenario wherein it is difficult to describe a single "outside" to a given address realm (bridged by NAPTs). This sort of configuration might arise in an enterprise environment where different divisions have their own subnets (each using the same private address space); the divisions are connected so that they can pass traffic on each others' networks, but to access the global Internet, each uses a different NAPT/firewall:
ここに、「外で与えられたアドレス分野(NAPTsによって橋を架けられる)への」シングルについて説明するのが難しい1つのサンプルシナリオがあります。 この種類の構成は異なった部門がそれら自身のサブネットを持っている(それぞれ同じプライベート・アドレススペースを使用して)企業環境で起こるかもしれません。 部門はそれぞれにおける交通に他のもののネットワークを向かわせることができるように、接続されていますが、世界的なインターネットにアクセスするために、それぞれが異なったNAPT/ファイアウォールを使用します:
+---------+
| Box C | (192.168.4.5)
+---+-----+
|
---------------------------------+-------
|
| 192.168.3.0/24
+----+----+
| NAT 2 |
+----+----+
| 10.1.0.0/32
|
-----+-------------------------+------------+----
| |
| +----+----+
| | Box B | (10.1.1.100)
| +---------+
|
+----+----+
| NAPT 1 | (10.1.2.27)
+----+----+
| 10.1.0.0/32
|
----+-----+--
|
|
+----+----+
| Box A | (10.1.1.100)
+---------+
+---------+ | 箱C| (192.168.4.5) +---+-----+ | ---------------------------------+------- | | 192.168.3.0/24 +----+----+ | NAT2| +----+----+ | 10.1.0.0/32 | -----+-------------------------+------------+---- | | | +----+----+ | | 箱B| (10.1.1.100) | +---------+ | +----+----+ | NAPT1| (10.1.2.27) +----+----+ | 10.1.0.0/32 | ----+-----+-- | | +----+----+ | 箱A| (10.1.1.100) +---------+
From the perspective of Box B, Box A's address is (some port on) 10.1.2.27. From the perspective of Box C, however, Box A's address is some address in the space 192.168.3.0/24.
Box AのアドレスがBox Bの見解からの、そうである、(或るものが移植する、オンである、)、10.1 .2 .27。 しかしながら、Box Cの見解から、Box Aのアドレスはスペース192.168.3で.0/24に何らかのアドレスです。
Daigle & IAB Informational [Page 7] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[7ページ]のRFC3424IAB問題
C.2 Real World Home Network Example
C.2の本当の世界ホームネットワークの例
James Woodyatt provided the following scenario, based on current examples of home networking products:
ジェームスWoodyattは家のネットワーク製品の現在の例に基づいて以下のシナリオを提供しました:
o the customer has existing Internet service from some broadband
service provider, using e.g. a DSL line connected to an appliance
that integrates a DSL modem with a NAT router/firewall.
o 顧客には、何らかの広帯域サービスプロバイダーからの既存のインターネットのサービスがあります、例えばNATルータ/ファイアウォールとDSLモデムを統合する器具につなげられたDSL回線を使用して。
o these devices are sometimes packaged with automated provisioning
firmware, so the customer may view them as part of what their ISP
provides them.
o これらの装置が時々自動化された食糧を供給するファームウェアでパッケージされるので、顧客はそれらのISPがそれらを提供することに関する部分であるとそれらをみなすかもしれません。
o later, the customer wants to use a host with only a wireless LAN
interface, so they install a wireless access point that ships in
its default configuration with NAT and a DHCP server enabled.
o その後顧客が無線LANインタフェースだけと共にホストを使用したがっているので、彼らはNATがあるデフォルト設定とDHCPサーバの船が可能にしたワイヤレス・アクセスポイントをインストールします。
o after this, the customer has a wired LAN in one private address
realm and a wireless LAN in another private address realm.
o この後、顧客には、1つのプライベート・アドレス分野のワイヤードなLANと別のプライベート・アドレス分野の無線LANがあります。
Furthermore, most customers probably have no idea what the phrase "address realm" means and shouldn't have to learn it. All they often know is that the printer server is inaccessible to the wireless laptop computer. (Why? Because the discovery protocol uses UDP multicast with TTL=1, but that's okay because any response would just be dropped by the NAT anyway, because there's no ALG.)
その上、ほとんどの顧客は、「アドレス分野」という句が意味することがたぶん、分からなく、それを学ぶ必要はないはずです。 彼らがしばしば知っているすべてはプリンタサーバが無線のラップトップコンピュータに近づきがたいということです。 (なぜですか? どんな応答もNATによってただとにかく落とされるでしょう、発見プロトコルがUDPマルチキャストを使用して、したがって、TTL=1と共に、それだけがオーケーです、ALGが全くないので。)
Authors' Addresses
作者のアドレス
Leslie Daigle Editor
レスリーDaigleエディタ
Internet Architecture Board IAB EMail: iab@iab.org
インターネット・アーキテクチャ委員会IABはメールします: iab@iab.org
Daigle & IAB Informational [Page 8] RFC 3424 IAB Considerations for UNSAP Across NAT November 2002
NAT2002年11月の向こう側のUNSAPのためのDaigle&IABの情報[8ページ]のRFC3424IAB問題
Full Copyright Statement
完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Daigle & IAB Informational [Page 9]
Daigle&IAB情報です。[9ページ]
一覧
スポンサーリンク
