RFC1347 日本語訳
1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal forInternet Addressing and Routing. R. Callon. June 1992. (Format: TXT=26563, PS=42398, PDF=22398 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Ross Callon Request for Comments: 1347 DEC June 1992
ネットワークワーキンググループロスCallonはコメントのために以下を要求します。 1347 1992年12月の6月
TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing
より大きいアドレス(tuba)、インターネットアドレシングとルート設定のための簡単な提案があるTCPとUDP
Status of the Memo
メモの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
1 Summary
1つの概要
The Internet is approaching a situation in which the current IP address space is no longer adequate for global addressing and routing. This is causing problems including: (i) Internet backbones and regionals are suffering from the need to maintain large amounts of routing information which is growing rapidly in size (approximately doubling each year); (ii) The Internet is running out of IP network numbers to assign. There is an urgent need to develop and deploy an approach to addressing and routing which solves these problems and allows scaling to several orders of magnitude larger than the existing Internet. However, it is necessary for any change to be deployed in an incremental manner, allowing graceful transition from the current Internet without disruption of service. [1]
インターネットはグローバルなアドレシングとルーティングには、現在のIPアドレス空間がもう適切でない状況にアプローチしています。 問題を起こして、:これは問題を起こしています。 (i) インターネットの基幹と地方版はサイズに急速に生えている多量のルーティング情報を保守する必要性に苦しんでいます(毎年周囲で倍増して)。 (ii) インターネットは割り当てるIPネットワーク・ナンバーを使い果たしています。 既存のインターネットより大きい数num#nil個の桁までこれらの問題を解決して、比例するのを許容するアドレシングとルーティングへのアプローチを開発して、配布する緊急の必要があります。 しかしながら、どんな変化も増加の方法で配布されるのが必要です、現在のインターネットからサービスの分裂なしで優雅な変遷を許容して。 [1]
This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This involves a gradual migration from the current Internet Suite (which is based on Internet applications, running over TCP or UDP, running over IP) to an updated suite (based on the same Internet applications, running over TCP or UDP, running over CLNP [2]). This approach is known as "TUBA" (TCP & UDP with Bigger Addresses).
この論文はインターネットアドレシング、ルーティング、およびスケーリングの長期的な解決法を提供する簡単な提案について説明します。 これは現在のインターネットSuite(IPをひいて、TCPかUDPをひいて、インターネットアプリケーションに基づいている)からアップデートされたスイートまでゆるやかな移行にかかわります。(CLNP[2])をひいて、TCPかUDPをひいて、同じインターネットアプリケーションに基づいています。 このアプローチは「チューバ」(より大きいアドレスがあるTCP&UDP)として知られています。
This paper describes a proposal for how transition may be accomplished. Description of the manner in which use of CLNP, NSAP addresses, and related network/Internet layer protocols (ES-IS, IS-IS, and IDRP) allow scaling to a very large ubiquitous worldwide Internet is outside of the scope of this paper.
この論文はどう変遷を実行できるように提案について説明するか。 CLNPの使用、NSAPアドレス、および関連するネットワーク/インターネットがプロトコルを層にする方法の記述、(ES存在、-、IDRP) 遍在している世界的なインターネットがあるこの紙の範囲のまさしくその多くに比例するのを許容してください。
Originally, it was thought that any practical proposal needed to address the immediate short-term problem of routing information explosion (in addition to the long-term problem of scaling to a worldwide Internet). Given the current problems caused by excessive routing information in IP backbones, this could require older IP-based systems to talk to other older IP-based systems over intervening Internet backbones which did not support IP. This in turn would require either translation of IP packets into
元々、どんな実用的な提案も、ルーティング情力化(世界的なインターネットに比例するという長期の問題に加えた)のその即座の短期的な問題を訴える必要だったと思われました。 IPバックボーンにおける過度のルーティング情報によって引き起こされた現在の問題を考えて、これは、IPをサポートしなかった介入しているインターネットの基幹の上で他の、より古いIPベースのシステムと話すために、より古いIPベースのシステムを必要とするかもしれません。 これは順番にIPパケットに関する翻訳を必要とするでしょう。
Callon [Page 1]
Callon[1ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
CLNP packets and vice versa, or encapsulation of IP packets inside CLNP packets. However, other shorter-term techniques (for example [3]) have been proposed which will allow the Internet to operate successfully for several years using the current IP address space. This in turn allows more time for IP-to-CLNP migration, which in turn allows for a much simpler migration technique.
CLNPパケット、逆もまた同様です、または、CLNPパケットの中のIPパケットのカプセル化。 しかしながら、他の、より短い期間のテクニック、(例えば、数年に現在のIPアドレス空間を使用することで操作するインターネットを首尾よく考慮する[3])が提案されました。 これは順番にIPからCLNPへの移行のための、より多くの時間を許容します。(順番に、移行ははるかに簡単な移行のテクニックを考慮します)。
The TUBA proposal therefore makes use of a simple long-term migration proposal based on a gradual update of Internet Hosts (to run Internet applications over CLNP) and DNS servers (to return larger addresses). This proposal requires routers to be updated to support forwarding of CLNP (in addition to IP). However, this proposal does not require encapsulation nor translation of packets nor address mapping. IP addresses and NSAP addresses may be assigned and used independently during the migration period. Routing and forwarding of IP and CLNP packets may be done independently.
したがって、TUBA提案はインターネットHosts(CLNPのインターネットアプリケーションを実行する)とDNSサーバ(より大きいアドレスを返す)のゆるやかなアップデートに基づく簡単な長期の移行提案を利用します。 この提案は、CLNP(IPに加えた)の推進をサポートするためにルータをアップデートするのを必要とします。 または、しかしながら、この提案はカプセル化が必要でない、パケットに関する翻訳、または、アドレス・マッピング。 IPアドレスとNSAPアドレスは、移行の期間、独自に割り当てられて、使用されるかもしれません。 IPとCLNPパケットのルート設定と推進は独自に完了しているかもしれません。
This paper provides a draft overview of TUBA. The detailed operation of TUBA has been left for further study.
この紙はTUBAの草稿概要を提供します。 TUBAの詳細な操作はさらなる研究に発たれました。
2 Long-Term Goal of TUBA
2 チューバの長期目標
This proposal seeks to take advantage of the success of the Internet Suite, the greatest part of which is probably the use of IP itself. IP offers a ubiquitous network service, based on datagram (connectionless) operation, and on globally significant IP addresses which are structured to aid routing. Unfortunately, the limited 32-bit IP address is gradually becoming inadequate for routing and addressing in a global Internet. Scaling to the anticipated future size of the worldwide Internet requires much larger addresses allowing a multi-level hierarchical address assignment.
この提案はインターネットSuiteの成功を利用しようとします。その最大級の部分はたぶんIP自身の使用です。 IPはデータグラムの(コネクションレス)の操作に基づいたルーティングを支援するために構造化されるグローバルに重要なIPアドレスに対してはユビキタスネットワークサービスを提供します。 残念ながら、限られた32ビットのIPアドレスは徐々に世界的なインターネットでルーティングとアドレシングに不十分になっています。 世界的なインターネットの予期された将来のサイズに比例するのはマルチレベルの階層的なアドレス課題を許容するはるかに大きいアドレスを必要とします。
If we had the luxury of starting over from scratch, most likely we would base the Internet on a new datagram internet protocol with much larger multi-level addresses. In principle, there are many choices available for a new datagram internet protocol. For example, the current IP could be augmented by addition of larger addresses, or a new protocol could be developed. However, the development, standardization, implementation, testing, debugging and deployment of a new protocol (as well as associated routing and host-to-router protocols) would take a very large amount of time and energy, and is not guaranteed to lead to success. In addition, there is already such a protocol available. In particular, the ConnectionLess Network Protocol (CLNP [1]) is very similar to IP, and offers the required datagram service and address flexibility. CLNP is currently being deployed in the Internet backbones and regionals, and is available in vendor products. This proposal does not actually require use of CLNP (the main content of this proposal is a graceful migration path from the current IP to a new IP offering a larger address space),
私たちに最初からやり直すぜいたくがあるなら、たぶん、私たちのインターネットははるかに大きいマルチレベルアドレスがある新しいデータグラムインターネットプロトコルに基づいているでしょうに。 原則として、新しいデータグラムインターネットプロトコルに利用可能な多くの選択があります。 例えば、より大きいアドレスの追加で現在のIPを増大させることができましたか、または新しいプロトコルを開発できました。 しかしながら、新しいプロトコル(関連ルーティングとホストからルータへのプロトコルと同様に)の開発、標準化、実装、テスト、デバッグ、および展開は、非常に大きい時間とエネルギーがかかって、成功につながるために保証されません。 さらに、利用可能なそのようなプロトコルが既にあります。 特にConnectionLess Networkプロトコル、(CLNP[1])はIPと非常に同様であり、必要なデータグラムサービスとアドレスの柔軟性を提供します。 CLNPは現在インターネットの基幹と地方版で配布されていて、メーカー製品の中で利用可能です。 この提案は実際にCLNPの使用を必要としません(現在のIPから新しいより大きいアドレス空間を提供するIPまでこの提案の主な内容は優雅な移行パスです)。
Callon [Page 2]
Callon[2ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
but use of CLNP will be assumed.
しかし、CLNPの使用は想定されるでしょう。
This proposal seeks to minimize the risk associated with migration to a new IP address space. In addition, this proposal is motivated by the requirement to allow the Internet to scale, which implies use of Internet applications in a very large ubiquitous worldwide Internet. It is therefore proposed that existing Internet transport and application protocols continue to operate unchanged, except for the replacement of 32-bit IP addresses with larger addresses. The use of larger addresses will have some effect on applications, particularly on the Domain Name Service. TUBA does not mean having to move over to OSI completely. It would mean only replacing IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would run on top of CLNP.
この提案は移行に関連している危険を新しいIPアドレス空間に最小にしようとします。 さらに、インターネットが比例するのを許容するという要件によってこの提案は動機づけられています。(それは、非常に大きい遍在している世界的なインターネットでのインターネットアプリケーションの使用を含意します)。 したがって、既存のインターネット輸送とアプリケーション・プロトコルが、変わりがない状態で作動し続けているよう提案されます、より大きいアドレスとの32ビットのIPアドレスの交換を除いて。 より大きいアドレスの使用はアプリケーションの上と、そして、特にDomain Name Serviceの上にいくつかの影響を与えるでしょう。 TUBAは、OSIに完全に譲らなければならないことを意味しません。 それは、IPをCLNPに取り替えるだけであることを意味するでしょう。 TCP、UDP、および伝統的なTCP/IPアプリケーションはCLNPの上で稼働しているでしょう。
The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses. Operation of this updated protocol suite will be very similar to the current operation. For example, in order to initiate communication with another host, a host will obtain a internet address in the same manner that it normally does, except that the address would be larger. In many or most cases, this implies that the host would contact the DNS server, obtain a mapping from the known DNS name to an internet address, and send application packets encapsulated in TCP or UDP, which are in turn encapsulated in CLNP. This long term goal requires a specification for how TCP and UDP are run over CLNP. Similarly, DNS servers need to be updated to deal with NSAP addresses, and routers need to be updated to forward CLNP packets. This proposal does not involve any wider-spread migration to OSI protocols.
TUBA提案の長期目標は、現在のインターネットとして非常に作動する世界的なインターネットへの変遷にかかわりますが、CLNPがIPに取って代わっていてNSAPアドレスがIPアドレスを置き換えていて、かかわります。 このアップデートされたプロトコル群の操作は現在の操作と非常に同様になるでしょう。 例えば、ホストは別のホストとのコミュニケーションを開始するために通常、それがするのと同じ方法でインターネットアドレスを得るでしょう、アドレスが、より大きいだろうというのを除いて。 多くかほとんどの場合では、これは、ホストがDNSサーバに連絡して、知られているDNS名からインターネットアドレスまでマッピングを得て、CLNPで順番にカプセル化されるTCPかUDPでカプセルに入れられたアプリケーションパケットを送るのを含意します。 この長期目標はTCPとUDPがどうCLNPの上に実行されるか仕様を必要とします。 同様に、DNSサーバは、NSAPアドレスに対処するためにアップデートする必要があります、そして、ルータはパケットをCLNPに送るためにアップデートする必要があります。 この提案はどんなより広い普及の移行にもOSIプロトコルにかかわりません。
TUBA does not actually depend upon DNS for its operation. Any method that is used for obtaining Internet addresses may be updated to be able to return larger (NSAP) addresses, and then can be used with TUBA.
TUBAは操作のために実際にDNSによりません。 インターネット・アドレスを得るのに使用されるどんなメソッドも、より大きい(NSAP)アドレスを返すことができるようにアップデートするかもしれなくて、次に、TUBAと共に使用できます。
3 Migration
3移行
Figure 1 illustrates the basic operation of TUBA. Illustrated is a single Internet Routing Domain, which is also interconnected with Internet backbones and/or regionals. Illustrated are two "updated" Internet Hosts N1 and N2, as well as two older hosts H1 and H2, plus a DNS server and two border routers. It is assumed that the routers internal to the routing domain are capable of forwarding both IP and CLNP traffic (this could be done either by using multi-protocol routers which can forward both protocol suites, or by using a different set of routers for each suite).
図1はTUBAの基本的な操作を例証します。 例証されているのは、独身のインターネットルート設定Domain(また、インターネットの基幹、そして/または、地方版でインタコネクトされる)です。 例証されているのが、2人のより年取ったホストと同じくらい良い2の「アップデートされた」インターネットHosts N1と、N2と、H1と、H2と、DNSサーバであり、2はルータに接しています。 経路ドメインへの内部のルータがIPとCLNPの両方にトラフィックを送ることができると(両方のプロトコル群を進めることができるマルチプロトコルルータを使用するか、または各スイートに異なったセットのルータを使用することによって、これができるでしょう)思われます。
Callon [Page 3]
Callon[3ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
................ ................ . H1 . . Internet . . .-R1-. . . H2 . . Backbones . . DNS . . . . . . and . . N1 . . . . . . Regionals . . N2 .-R2-. . ................ ................
................ ................ . H1インターネット…-R1、-、…H2バックボーンDNS…、N1地方版(N2 .-R2)…… ................
Key
キー
DNS DNS server H IP host N Updated Internet host R Border Router
DNS DNSサーバH IPホストN Updatedインターネット・ホストR Border Router
Figure 1 - Overview of TUBA
図1--チューバの概要
Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup.
アップデートされたインターネット・ホストは、変わりがない状態で現在のインターネットスイートを使用することで年取ったインターネット・ホストと話します。 他のアップデートされたインターネットへのアップデートされたインターネット・ホスト話が使用を接待する、(TCPかUDP、より多くの)、CLNP。 これは、アップデートされたインターネット・ホストが古いスタイルパケット(IPを使用する)か新式パケットのどちらかを送ることができなければならないのを含意します(CLNPを使用して)。 どれ、発信するのは名前からアドレスへの正常なルックアップで決定しているか。
Thus, suppose that host N1 wants to communicate with host H1. In this case, N1 asks its local DNS server for the address associated with H1. In this case, since H1 is a older (not-updated) host, the address available for H1 is an IP address, and thus the DNS response returned to N1 specifies an IP address. This allows N1 to know that it needs to send a normal old-style Internet suite packet (encapsulated in IP) to H1.
したがって、ホストN1がホストH1とコミュニケートしたがっていると仮定してください。 この場合、N1はローカルのDNSサーバにH1に関連しているアドレスを求めます。 H1が、より年取った(アップデートしない)ホストであるので、この場合H1に利用可能なアドレスはIPアドレスです、そして、その結果、N1に返されたDNS応答はIPアドレスを指定します。 これで、N1は、正常な古いスタイルインターネットスイートパケット(IPでは、要約する)をH1に送るのが必要であることを知ることができます。
Suppose that host N1 wants to communicate with host N2. In this case, again N1 contacts the DNS server. If the routers in the domain have not been updated (to forward CLNP), or if the DNS resource record for N2 has not been updated, then the DNS server will respond with a normal IP address, and the communication between N1 and N2 will use IP (updated hosts in environments where the local routers do not handle CLNP are discussed in section 6.3). However, assuming that the routers in the domain have been updated (to forward CLNP), that the DNS server has been updated (to be able to return NSAP addresses), and that the appropriate resource records for NSAP addresses have been configured into the DNS server, then the DNS server will respond to N1 with the NSAP address for N2, allowing N1 to know to use
ホストN1がホストN2とコミュニケートしたがっていると仮定してください。 一方、この場合、N1はDNSサーバに連絡します。そのドメインのルータをアップデートしていないか(CLNPを進める)、またはN2のためのDNSリソース記録をアップデートしていないと、DNSサーバは正常なIPアドレスで反応するでしょう、そして、N1とN2とのコミュニケーションはIPを使用するでしょう(セクション6.3でローカルルータがCLNPを扱わない環境におけるアップデートされたホストについて議論します)。 しかしながら、そのドメインのルータをアップデートして(CLNPを進める)、DNSサーバをアップデートして(アドレスをNSAPに返すことができるように)、NSAPアドレスのための適切なリソース記録をDNSサーバに構成したと仮定すると、DNSサーバはN2のためのNSAPアドレスでN1に反応するでしょう、N1が使用に知るのを許容して
Callon [Page 4]
Callon[4ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
CLNP (instead of IP) for communication with N2.
N2とのコミュニケーションのためのCLNP(IPの代わりに)。
A new resource record type will be defined for NSAP addresses. New hosts ask for both the new and old (IP address) resource records. Older DNS servers will not have the new resource record type, and will therefore respond with only IP address information. Updated DNS servers will have the new resource record information for the requested DNS name only if the associated host has been updated (otherwise the updated DNS server again will respond with an IP address).
新しいリソースレコード種類はNSAPアドレスのために定義されるでしょう。 新しいホストは両方の新しくて古い(IPアドレス)リソース記録を求めます。 より古いDNSサーバは、新しいリソースレコード種類を持たないで、したがって、IPアドレス情報だけで反応するでしょう。 アップデートされたDNSサーバで、関連ホストをアップデートした場合にだけ(さもなければ、アップデートされたDNSサーバは再びIPアドレスで反応するでしょう)、新しいリソースは要求されたDNS名のための情報を記録するでしょう。
Hosts and/or applications which do not use DNS operate in a similar method. For example, suppose that local name to address records are maintained in host table entries on each local workstation. When a workstation is updated to be able to run Internet applications over CLNP, then the host table on the host may also be updated to contain updated NSAP addresses for other hosts which have also been updated. The associated entries for non-updated hosts would continue to contain IP addresses. Thus, again when an updated host wants to initiate communication with another host, it would look up the associated Internet address in the normal manner. If the address returned is a normal 32-bit IP address, then the host would initiate a request using an Internet application over TCP (or UDP) over IP (as at present). If the returned address is a longer NSAP address, then the host would initiate a request using an Internet application over TCP (or UDP) over CLNP.
DNSを使用しないホスト、そして/または、アプリケーションが同様のメソッドで作動します。 例えば、アドレス記録がその地方名が各ローカルワークステーションでホストでエントリーをテーブルの上に置くのが保守されると仮定してください。 また、CLNPのインターネットアプリケーションを実行できるようにワークステーションをアップデートすると、他のホストのためのまた、アップデートされたアップデートされたNSAPアドレスを含むようにホストの上のホストテーブルをアップデートするかもしれません。 非アップデートされたホストのための関連エントリーはずっとIPアドレスを含んでいるでしょう。 アップデートされたホストが別のホストとのコミュニケーションを開始したがっているとき、したがって、一方、それは正常な方法で関連インターネット・アドレスを調べるでしょう。 返されたアドレスが正常な32ビットのIPアドレスであるなら、IPの上のTCP(または、UDP)の上のインターネットアプリケーションを使用することで(プレゼントのように)ホストは要求を開始するでしょう。 返されたアドレスが、より長いNSAPアドレスであるなら、ホストは、CLNPの上のTCP(または、UDP)の上のインターネットアプリケーションを使用することで要求を開始するでしょう。
4 Running TCP and UDP Over CLNP
4 CLNPの上の実行しているTCPとUDP
TCP is run directly on top of CLNP (i.e., the TCP packet is encapsulated directly inside a CLNP packet - the TCP header occurs directly following the CLNP header). Use of TCP over CLNP is straightforward, with the only non-trivial issue being how to generate the TCP pseudo-header (for use in generating the TCP checksum).
TCPは直接CLNPの上で実行されます(すなわち、TCPパケットはCLNPパケットの直接中でカプセルに入れられます--直接CLNPヘッダーに続いて、TCPヘッダーは起こります)。 CLNPの上のTCPの使用は簡単です、TCPが疑似ヘッダー(TCPチェックサムを生成することにおける使用のための)であるとどう生成するかということである唯一の重要な問題で。
Note that TUBA runs TCP over CLNP on an end-to-end basis (for example, there is no intention to translate CLNP packets into IP packets). This implies that only "consenting updated systems" will be running TCP over CLNP; which in turn implies that, for purposes of generating the TCP pseudoheader from the CLNP header, backward compatibility with existing systems is not an issue. There are therefore several options available for how to generate the pseudoheader. The pseudoheader could be set to all zeros (implying that the TCP header checksum would only be covering the TCP header). Alternatively, the pseudoheader could be calculated from the CLNP header. For example, the "source address" in the TCP pseudoheader could be replaced with two bytes of zero plus a two byte checksum run on the source NSAP address length and address (and similarly for the destination address); the "protocol" could be replaced by the destination address selector value; and the "TCP Length" could be calculated from the CLNP
TUBAが終わりから終わりへのベースでCLNPの上にTCPを実行することに注意してください(例えば、CLNPパケットをIPパケットに翻訳するという意志が全くありません)。 これは、唯一の「同意はシステムをアップデートしたこと」がCLNPの上で実行しているTCPになるのを含意します。 順番に、既存のシステムとの後方の互換性がCLNPヘッダーからTCP pseudoheaderを生成する目的のための問題でないことを含意します。 したがって、どうpseudoheaderを生成するかに利用可能ないくつかのオプションがあります。 pseudoheaderはすべてのゼロに用意ができることができました(TCPヘッダーチェックサムがTCPヘッダーをカバーしているだけであるのを含意して)。 あるいはまた、CLNPヘッダーでpseudoheaderについて計算できました。 例えば、TCP pseudoheaderの「ソースアドレス」を2バイトのゼロとソースNSAPアドレスの長さとアドレスで実行された2バイトのチェックサムに取り替えることができた、(同様である、送付先アドレス)、。 「プロトコル」を目的地アドレスセレクタ価値に取り替えることができました。 そして、CLNPから「TCPの長さ」について計算できました。
Callon [Page 5]
Callon[5ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
packet in the same manner that it is currently calculated from the IP packet. The details of how the pseudoheader is composed is for further study.
IPパケットで計算されて、現在それがそうである同じ方法によるパケット。 さらなる研究にはpseudoheaderがどう落ち着いているかに関する詳細があります。
UDP is transmitted over CLNP in the same manner. In particular, the UDP packet is encapsulated directly inside a CLNP packet. Similarly, the same options are available for the UDP pseudo- header as for the TCP pseudoheader.
UDPは同じ方法でCLNPの上に伝えられます。 特に、UDPパケットはCLNPパケットの直接中でカプセルに入れられます。 同様に、同じオプションはTCP pseudoheaderのようにUDP疑似ヘッダーに利用可能です。
5 Updates to the Domain Name Service
ドメイン名サービスへの5つのアップデート
TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses. This resource record allows mapping from DNS names to NSAP addresses, and will contain entries for systems which are able to run Internet applications, over TCP or UDP, over CLNP.
TUBAは、リソースの新しいDNS記録エントリータイプ(「長いアドレス」)が、より長いインターネット(すなわち、NSAP)アドレスを保存するために定義されるのを必要とします。 このリソース記録は、DNS名からNSAPまでアドレスを写像するのを許容して、インターネットアプリケーションを実行できるシステムのためのエントリーを含むでしょう、TCPかUDPの上で、CLNPの上で。
The presence of a "long-address" resource record for mapping a particular DNS name to a particular NSAP address can be used to imply that the associated system is an updated Internet host. This specifically does not imply that the system is capable of running OSI protocols for any other purpose. Also, the NSAP address used for running Internet applications (over TCP or UDP over CLNP) does not need to have any relationship with other NSAP addresses which may be assigned to the same host. For example, a "dual stack" host may be able to run Internet applications over TCP over CLNP, and may also be able to run OSI applications over TP4 over CLNP. Such a host may have a single NSAP address assigned (which is used for both purposes), or may have separate NSAP addresses assigned for the two protocol stacks. The "long-address" resource record, if present, may be assumed to contain the correct NSAP address for running Internet applications over CLNP, but may not be assumed to contain the correct NSAP address for any other purpose.
関連システムがアップデートされたインターネット・ホストであることを含意するのに特定のDNS名を特定のNSAPアドレスに写像するための「長いアドレス」リソース記録の存在を使用できます。 これは、システムがいかなる他の目的のためにもOSIプロトコルを実行できるのを明確に含意しません。 また、インターネットアプリケーション(CLNPの上のTCPかUDPの上の)を実行するのに使用されるNSAPアドレスは同じホストに割り当てられるかもしれない他のNSAPアドレスとの少しの関係も必要としません。 例えば、「デュアルスタック」ホストは、CLNPのTCPのインターネットアプリケーションを実行できるかもしれなくて、また、CLNPのTP4のOSIアプリケーションを実行できるかもしれません。 そのようなホストは、NSAPアドレスが割り当てたシングル(両方の目的に使用される)を持っているか、または2個のプロトコル・スタックのために別々のNSAPアドレスを割り当てさせるかもしれません。 「長いアドレス」リソース記録は、存在しているならCLNPのインターネットアプリケーションを実行するための正しいNSAPアドレスを含むと思われますが、いかなる他の目的のための正しいNSAPアドレスも含むと思われないかもしれません。
The backward translation (from NSAP address to DNS name) is facilitated by definition of an associated resource record. This resource record is known as "long-in-addr.arpa", and is used in a manner analogous to the existing "in-addr.arpa".
後方の翻訳(NSAPアドレスからDNS名までの)は定義上関連リソース記録について容易にされます。 このリソース記録は、「addr.arpaで長い」として知られていて、既存「addr.arpa」での類似の方法で使用されます。
Updated Internet hosts, when initiating communication with another host, need to know whether that host has been updated. The host will request the address-class "internet address", entry-type "long-address" from its local DNS server. If the local DNS server has not yet been updated, then the long address resource record will not be available, and an error response will be returned. In this case, the updated hosts must then ask for the regular Internet address. This allows updated hosts to be deployed in environments in which the DNS servers have not yet been updated.
別のホストとのコミュニケーションを開始するとき、アップデートされたインターネット・ホストは、そのホストをアップデートしたかどうかを知る必要があります。 ホストはアドレスクラス「インターネットアドレス」を要求するでしょう、ローカルのDNSサーバからの「長いアドレス」のエントリータイプ。まだローカルのDNSサーバをアップデートしていないなら、長いアドレスリソース記録は利用可能にならないでしょう、そして、誤り応答を返すでしょう。 そして、この場合、アップデートされたホストは通常のインターネット・アドレスを求めなければなりません。 これで、アップデートされたホストはDNSサーバがまだアップデートされていない環境で配布します。
An updated DNS server, if asked for the long-address
サーバであって、長いアドレスのために尋ねられたアップデートされたDNS
Callon [Page 6]
Callon[6ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
corresponding to a particular DNS name, does a normal DNS search to obtain the information. If the long-address corresponding to that name is not available, then the updated DNS server will return the resource record type containing the normal 32-bit IP address (if available). This allows more efficient operation between updated hosts and old hosts in an environment in which the DNS servers have been updated.
特定のDNS名に対応している、正常なDNSは、情報を得るために探しますか? その名前に対応する長いアドレスが利用可能でないなら、アップデートされたDNSサーバは正常な32ビットのIPアドレスを含むリソースレコード種類を返すでしょう(利用可能であるなら)。 これはDNSサーバをアップデートしてある環境でアップデートされたホストと年取ったホストの間の、より効率的な操作を許します。
Interactions between DNS servers can be done over either IP or CLNP, in a manner analogous to interactions between hosts. DNS servers currently maintain entries in their databases which allow them to find IP addresses of other DNS servers. These can be updated to include a combination of IP addresses and NSAP addresses of other servers. If an NSAP address is available, then the communication with the other DNS server can use CLNP, otherwise the interaction between DNS servers uses IP. Initially, it is likely that all communication between DNS servers will use IP (as at present). During the migration process, the DNS servers can be updated to communicate with each other using CLNP.
DNSサーバの間に相互作用へのホストの間の類似の方法でIPかCLNPのどちらかの上に相互作用できます。 DNSサーバは現在、彼らが他のDNSサーバのIPアドレスを見つけることができる自分達のデータベースにおけるエントリーを維持します。 他のサーバのIPアドレスとNSAPアドレスの組み合わせを含むようにこれらをアップデートできます。 NSAPアドレスが利用可能であるなら、もう片方のDNSサーバとのコミュニケーションはCLNPを使用できます。さもなければ、DNSサーバの間の相互作用はIPを使用します。 初めは、DNSサーバのすべてのコミュニケーションがIPを使用しそうでしょう(プレゼントのように)。 移行プロセスの間、CLNPを使用することで互いにコミュニケートするためにDNSサーバをアップデートできます。
6 Other Technical Details
6 他の技術面の詳細
6.1 When 32-Bit IP Addresses Fail
6.1 32ビットであるときに、IPアドレスは失敗します。
Eventually, the IP address space will become inadequate for global routing and addressing. At this point, the remaining older (not yet updated) IP hosts will not be able to interoperate directly over the global Internet. This time can be postponed by careful allocation of IP addresses and use of "Classless Inter-Domain Routing" (CIDR [3]), and if necessary by encapsulation (either of IP in IP, or IP in CLNP). In addition, the number of hosts affected by this can be minimized by aggressive deployment of updated software based on TUBA.
結局、IPアドレス空間はグローバルなルーティングとアドレシングに不十分になるでしょう。 ここに、残っているより年取った(まだアップデートされなかった)IPホストは世界的なインターネットの直接上に共同利用できないでしょう。 IPアドレスの慎重な配分と「階級のない相互ドメインルート設定」の使用で今回を延期できる、(CIDR[3])、必要ならカプセル化(IPにおけるIP、またはCLNPのIPの) さらに、TUBAに基づくアップデートされたソフトウェアの攻撃的な展開でこれで影響を受けるホストの数を最小にすることができます。
When the IP address space becomes inadequate for global routing and addressing, for purposes of IP addressing the Internet will need to be split into "IP address domains". 32-bit IP addresses will be meaningful only within an address domain, allowing the old IP hosts to continue to be used locally. For communications between domains, there are two possibilities: (i) The user at an old system can use application layer relays (such as mail relays for 822 mail, or by Telnetting to an updated system in order to allow Telnet or FTP to a remote system in another domain); or (ii) Network Address Translation can be used [4].
IPアドレス空間がグローバルなルーティングとアドレシング、IPの目的に不十分になると、インターネットを扱うのは、「IPアドレスドメイン」に分けられる必要があるでしょう。 32ビットのIPアドレスはアドレスドメインだけの中で重要になるでしょう、年取ったIPホストが、局所的に使用され続けているのを許容して。 ドメインのコミュニケーションのために、2つの可能性があります: (i) 古いシステムのユーザは応用層リレー(別のドメインのリモートシステムにTelnetかFTPを許容するために822メール、またはTelnettingによるリレーをアップデートされたシステムに郵送する)を使用できます。 または、(ii)ネットワークAddress Translationは中古の[4]であることができます。
6.2 Applications which use IP Addresses Internally
6.2 IP Addresses Internallyを使用するアプリケーション
There are some application protocols (such as FTP and NFS) which pass around and use IP addresses internally. Migration to a larger address space (whether based on CLNP or other protocol) will require either that these applications be limited to local use (within an "IP address domain" in which 32-bit IP addresses are meaningful) or be updated to either: (i) Use larger network
内部的にIPアドレスを回して、使用するいくつかのアプリケーション・プロトコル(FTPやNFSなどの)があります。 より大きいアドレス空間(CLNPか他のプロトコルに基づいているか否かに関係なく)への移行は、これらのアプリケーションを地方の使用(「IPアドレスドメイン」の中32ビットのIPアドレスが重要である)に制限するか、またはどちらかにアップデートするのを必要とするでしょう: (i) より大きいネットワークを使用してください。
Callon [Page 7]
Callon[7ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
addresses instead of 32-bit IP addresses; or (ii) Use some other globally-significant identifiers, such as DNS names.
32ビットのIPアドレスの代わりにアドレス。 または、(ii)はDNS名などのある他のグローバルに重要な識別子を使用します。
6.3 Updated Hosts in IP-Only Environments
6.3はIPだけ環境でホストをアップデートしました。
There may be some updated Internet hosts which are deployed in networks that do not yet have CLNP service, or where CLNP service is available locally, but not to the global Internet. In these cases, it will be necessary for the updated Internet hosts to know to initially send all Internet traffic (or all non-local traffic) using IP, even when the remote system also has been updated. There are several ways that this can be accomplished, such as: (i) The host could contains a manual configuration parameter controlling whether to always use IP, or to use IP or CLNP depending upon remote address; (ii) The DNS resolver on the host could be "lied to" to believe that all remote requests are supposed to go to some particular server, and that server could intervene and change all remote requests for long-addresses into requests for normal IP addresses.
アップデートされたそうする何人かのインターネット・ホストがまだCLNPサービスを持っていないネットワークで配布されるか、またはCLNPサービスが利用可能であるところに局所的にいるかもしれませんが、世界的なインターネットにはあるというわけではありません。 これらの場合では、アップデートされたインターネット・ホストが、初めはすべてのインターネットトラフィックを送るのを知るのにそれがIPを使用することで必要でしょう(または、すべての非地方のトラフィック)、リモートシステムもアップデートさえしたとき。 以下のようにこれを達成できるいくつかの方法があります。 (i) ホストがそうすることができた、いつもIPを使用するか、またはリモートアドレスによるIPかCLNPを使用するかを制御する手動の設定パラメータを含んでいます。 (ii) すべてのリモート要求が何らかの特定のサーバに行くべきであると信じるためにホストの上のDNSレゾルバに「嘘をつかれることができ」て、そのサーバは、長いアドレスを求めるすべてのリモート要求に正常なIPアドレスを求める要求に介入して、変えるかもしれません。
6.4 Local Network Address Translation
6.4 企業内情報通信網アドレス変換
Network Address Translation (NAT [4]) has been proposed as a means to allow global communication between hosts which use locally-significant IP addresses. NAT requires that IP addresses be mapped at address domain boundaries, either to globally significant addresses, or to local addresses meaningful in the next address domain along the packet's path. It is possible to define a version of NAT which is "local" to an addressing domain, in the sense that (locally significant) IP packets are mapped to globally significant CLNP packets before exiting a domain, in a manner which is transparent to systems outside of the domain.
Address Translationをネットワークでつないでください。(NAT[4])は局所的に重要なIPアドレスを使用するものをホストの間のグローバルコミュニケーションに許容する手段として提案されました。 NATは、IPアドレスがアドレスドメイン境界において、または、グローバルに重要なアドレス、または、パケットの経路に沿った次のアドレスドメインで重要なローカルのアドレスに写像されるのを必要とします。 アドレス指定領域に「地方であること」のNATのバージョンを定義するのは可能です、ドメインの外でシステムに見え透いた方法によるドメインを出る前に(局所的に重要)のIPパケットがグローバルに重要なCLNPパケットに写像されるという意味で。
NAT allows old systems to continue to be used globally without application gateways, at the cost of significant additional complexity and possibly performance costs (associated with translation or encapsulation of network packets at IP address domain boundaries). NAT does not address the problem of applications which pass around and use IP addresses internally.
NATで、古いシステムは、アプリケーションゲートウェイなしで重要な追加複雑さとことによると性能コスト(ネットワークパケットの翻訳かカプセル化にIPアドレスドメイン境界で関連している)の費用にグローバルに使用され続けることができます。 NATは内部的にIPアドレスを回して、使用するアプリケーションのその問題を訴えません。
The details of Network Address Translation is outside of the scope of this document.
Network Address Translationの細部がこのドキュメントの範囲の外にあります。
6.5 Streamlining Operation of CLNP
6.5 CLNPの操作を能率化すること。
CLNP contains a number of optional and/or variable length fields. For example, CLNP allows addresses to be any integral number of bytes up to 20 bytes in length. It is proposed to "profile" CLNP in order to allow streamlining of router operation. For example, this might involve specifying that all Internet hosts will use an NSAP address of precisely 20 bytes in length, and may specify which optional fields (if any) will be present in all CLNP packets. This can allow all CLNP packets transmitted by Internet
CLNPは多くの任意の、そして/または、可変な長さの分野を含んでいます。 例えば、CLNPは、アドレスがあらゆる長さ最大20バイトの不可欠のバイト数であることを許容します。 それは、ルータ操作が流線型にされるのを許容するためにCLNPの「輪郭を描く」ために提案されます。 例えば、これは、すべてのインターネット・ホストが、長さに正確に20バイトのNSAPアドレスを使用して、すべてのCLNPパケットでどの任意の分野(もしあれば)が存在するかを指定するかもしれないと指定することを伴うかもしれません。 これはインターネットによって伝えられたすべてのCLNPパケットを許容できます。
Callon [Page 8]
Callon[8ページ]
RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992
RFC1347チューバ: アドレシングと1992年6月に掘るための提案
hosts to use a constant header format, in order to speed up header parsing in routers. The details of the Internet CLNP profile is for further study.
一定のヘッダー形式を使用するために、ルータにおけるヘッダー構文解析を早くして、接待します。 さらなる研究にはインターネットCLNPプロフィールの細部があります。
7 References
7つの参照箇所
[1] "The IAB Routing and Addressing Task Force: Summary Report", work in progress.
[1]、「IABルート設定とアドレシング特別委員会:」 「概要Report」は進行中で働いています。
[2] "Protocol for Providing the Connectionless-Mode Network Service", ISO 8473, 1988.
[2] 「コネクションレスなモードネットワーク・サービスを提供するためのプロトコル」、ISO8473、1988。
[3] "Supernetting: An Address Assignment and Aggregation Strategy", V.Fuller, T.Li, J.Yu, and K.Varadhan, March 1992.
[3]、「スーパーネッティング:」 フラー、T.李、J.ユー、およびK.Varadhan、1992年3月に対する「アドレス課題と集合戦略。」
[4] "Extending the IP Internet Through Address Reuse", Paul Tsuchiya, December 1991.
[4] 「アドレス再利用でIPインターネットを広げています」、ポールTsuchiya、1991年12月。
8 Security Considerations
8 セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9 Author's Address
9作者のアドレス
Ross Callon Digital Equipment Corporation 550 King Street, LKG 1-2/A19 Littleton, MA 01460-1289
ロスCallon DEC550キング・ストリート、LKG1-2/A19リトルトン、MA01460-1289
Phone: 508-486-5009
以下に電話をしてください。 508-486-5009
Email: Callon@bigfut.lkg.dec.com
メール: Callon@bigfut.lkg.dec.com
Callon [Page 9]
Callon[9ページ]
一覧
スポンサーリンク