RFC1900 日本語訳

1900 Renumbering Needs Work. B. Carpenter, Y. Rekhter. February 1996. (Format: TXT=9528 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                       B. Carpenter
Request for Comments: 1900                                    Y. Rekhter
Category: Informational                                              IAB
                                                           February 1996

コメントを求めるワーキンググループB.大工要求をネットワークでつないでください: 1900年のY.Rekhterカテゴリ: 情報のIAB1996年2月

                         Renumbering Needs Work

番号を付け替えるのは仕事を必要とします。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   Renumbering, i.e., changes in the IP addressing information of
   various network components, is likely to become more and more
   widespread and common. The Internet Architecture Board (IAB) would
   like to stress the need to develop and deploy solutions that would
   facilitate such changes.

番号を付け替えること(すなわち、様々なネットワーク要素に関するIPアドレス指定情報における変化)はますます広範囲で一般的になりそうです。 インターネット・アーキテクチャ委員会(IAB)はそのような変化を容易にする解決策を見いだして、配布する必要性を強調したがっています。

Table of Contents

目次

   1. Motivation................................................... 1
   2. DNS versus IP Addresses...................................... 2
   3. Recommendations.............................................. 3
   4. Security Considerations...................................... 4
   Acknowledgements................................................ 4
   Authors' Addresses.............................................. 4

1. 動機… 1 2. DNS対IPアドレス… 2 3. 推薦… 3 4. セキュリティ問題… 4つの承認… 4人の作者のアドレス… 4

1. Motivation

1. 動機

   Hosts in an IP network are identified by IP addresses, and the IP
   address prefixes of subnets are advertised by routing protocols.  A
   change in such IP addressing information associated with a host or
   subnet is known as "renumbering".

IPアドレスでIPネットワークのホストを特定します、そして、ルーティング・プロトコルはサブネットのIPアドレス接頭語の広告を出します。 ホストかサブネットに関連しているそのようなIPアドレス指定情報における変化は「番号を付け替える」として知られています。

   Renumbering may occur for a variety of reasons.  For example, moving
   an IP host from one subnet to another requires changing the host's IP
   address.  Physically splitting a subnet due to traffic overload may
   also require renumbering.  A third example where renumbering may
   happen is when an organization changes its addressing plan.  Such
   changes imply changing not only hosts' addresses, but subnet numbers
   as well.  These are just three examples that illustrate possible
   scenarios where renumbering could occur.

番号を付け替えることはさまざまな理由で起こるかもしれません。 例えば、1からIPホストを動かして、別のものへのサブネットは、ホストのIPアドレスを変えるのを必要とします。 また、トラフィックオーバーロードのため物理的にサブネットを分けるのは、番号を付け替えるのを必要とするかもしれません。 番号を付け替えることが起こるかもしれない3番目の例は組織がアドレシングプランを変える時です。 ホストのアドレスだけではなく、また、サブネット番号も変える変化が含意するそのようなもの。 これらは番号を付け替えることが起こることができた可能なシナリオを例証するちょうど3つの例です。

Carpenter & Rekhter          Informational                      [Page 1]

RFC 1900                 Renumbering Needs Work            February 1996

仕事1996年2月に必要性に番号を付け替えさせる大工とRekhterの情報[1ページ]のRFC1900

   Increasingly, renumbering will be needed for organizations that
   require Internet-wide IP connectivity, but do not themselves provide
   a sufficient degree of address information aggregation.  Unless and
   until viable alternatives are developed, extended deployment of
   Classless Inter-Domain Routing (CIDR) is vital to keep the Internet
   routing system alive and to maintain continuous uninterrupted growth
   of the Internet.  With current IP technology, this requires such
   organizations to use addresses belonging to a single large block of
   address space, allocated to their current service provider which acts
   as an aggregator for these addresses.  To contain the growth of
   routing information, whenever such an organization changes to a new
   service provider, the organization's addresses will have to change.
   Occasionally, service providers themselves may have to change to a
   new and larger block of address space. In either of these cases, to
   contain the growth of routing information, the organizations
   concerned would need to renumber their subnet(s) and host(s). If the
   organization does not renumber, then some of the potential
   consequences may include (a) limited (less than Internet-wide) IP
   connectivity, or (b) extra cost to offset the overhead associated
   with the organization's routing information that Internet Service
   Providers have to maintain, or both.

ますます、番号を付け替えることが自分たちをするというわけではないのを除いて、インターネット全体のIPの接続性を必要とする組織に必要でしょう。十分な度合いのアドレス情報集合を提供してください。 実行可能な代案が開発されるまで、Classless Inter-ドメインルート設定(CIDR)の拡張展開は、インターネット・ルーティングシステムを生かして、インターネットの連続したとぎれない成長を維持するために重大です。 現在のIP技術で、これは、そのような組織がこれらのアドレスのためのアグリゲータとして機能するそれらの当期の勤務プロバイダーに割り当てられたアドレス空間に関する1大量株に属すアドレスを使用するのを必要とします。 そのような組織が新しいサービスプロバイダーに変化するときはいつも、ルーティング情報の成長を含むように、組織のアドレスは変化しなければならないでしょう。 時折、サービスプロバイダー自体はアドレス空間の新しくて、より大きいブロックに変化しなければならないかもしれません。 これらのケースのどちらかでは、ルーティング情報の成長を含むように、関する組織は、彼らのサブネットとホストに番号を付け替えさせる必要があるでしょう。 組織が番号を付け替えない、そして、潜在的結果のいくつかが、インターネットサービスプロバイダが保守しなければならない組織のルーティング情報に関連しているオーバーヘッド、または両方を相殺するために(a) 限られた(インターネット全体であるよりそれほど)IPの接続性、または(b) 追加費用を含むかもしれません。

   Currently, renumbering is usually a costly, tedious and error-prone
   process.  It normally requires the services of experts in the area
   and considerable advance planning.  Tools to facilitate renumbering
   are few, not widely available, and not widely deployed. While a
   variety of ad hoc approaches to renumbering have been developed and
   used, the overall situation is far from satisfactory.  There is
   little or no documentation that describes renumbering procedures.
   While renumbering occurs in various parts of the Internet, there is
   little or no documented experience sharing.

現在、通常、番号を付け替えるのは高価で、退屈で誤り傾向があるプロセスです。 通常、それは領域とかなりの前売りの計画における、専門家のサービスを必要とします。 番号を付け替えるのを容易にするツールは広く利用可能で、広く配布されるのではなく、わずかです。 番号を付け替えることへのさまざまな臨時のアプローチが、開発されて、使用されましたが、全般的情況は全く満足できません。 手順に番号を付け替えさせるとまず説明しないドキュメンテーションがあります。 番号を付け替えることはインターネットの様々な地域に起こりますが、共有するというまず記録されなかった経験があります。

2. DNS versus IP Addresses

2. DNS対IPアドレス

   Within the Internet architecture an individual host can be identified
   by the IP address(es) assigned to the network interface(s) on that
   host.  The Domain Name System (DNS) provides a convenient way to
   associate legible names with IP addresses.  The DNS name space is
   independent of the IP address space.  DNS names are usually related
   to the ownership and function of the hosts, not to the mechanisms of
   addressing and routing.  A change in DNS name may be a sign of a real
   change in function or ownership, whereas a change in IP address is a
   purely technical event.

インターネットアーキテクチャの中では、そのホストの上のネットワーク・インターフェースに割り当てられたIPアドレス(es)で個々のホストを特定できます。 ドメインネームシステム(DNS)はIPアドレスの読みやすい名前を関連づける便利な方法を提供します。 スペースというDNS名はIPアドレス空間から独立しています。 通常、DNS名はアドレシングとルーティングのメカニズムではなく、ホストの所有権と機能に関連します。 DNS名における変化は機能か所有権における本当の変化の兆候であるかもしれませんが、IPアドレスにおける変化は純粋に技術的なイベントです。

   Expressing information in terms of Domain Names allows one to defer
   binding between a particular network entity and its IP address until
   run time. Domain Names for enterprises, and Fully Qualified Domain
   Names (FQDNs, see RFC 1594) for servers and many user systems, are

Domain Namesに関して情報を言い表すのに、1つはランタイムまで特定のネットワーク実体とそのIPアドレスの間の結合を延期できます。 企業のためのドメインNames、およびサーバと多くのユーザシステムのためのFully Qualified Domain Names(FQDNs、RFC1594を見る)があります。

Carpenter & Rekhter          Informational                      [Page 2]

RFC 1900                 Renumbering Needs Work            February 1996

仕事1996年2月に必要性に番号を付け替えさせる大工とRekhterの情報[2ページ]のRFC1900

   expected to be fairly long-lived, and more stable than IP addresses.
   Deferring the binding avoids the risk of changed mapping between IP
   addresses and specific network entities (due to changing addressing
   information).  Moreover, reliance on FQDNs (rather than IP addresses)
   also localizes to the DNS the changes needed to deal with changing
   addressing information due to renumbering.

IPアドレスよりかなり長命であって、安定していると予想しました。 結合を延期すると、IPアドレスと特定のネットワーク実体(アドレス指定情報を変えるのによる)の間の変えられたマッピングの危険は避けられます。 そのうえ、また、FQDNs(IPアドレスよりむしろ)への信用は番号を付け替えるためアドレス指定情報を変える変化が対処する必要があったDNSにローカライズします。

   In some cases, both the addresses and FQDNs of desk top or portable
   systems are allocated dynamically. It is only a highly responsive
   dynamic DNS update mechanism that can cope with this.

いくつかの場合、ダイナミックにアドレスとデスク・トップか携帯用システムのFQDNsの両方を割り当てます。 それはこれを切り抜けることができる非常に敏感なダイナミックなDNSアップデートメカニズムにすぎません。

3. Recommendations

3. 推薦

   To make renumbering more feasible, the IAB strongly recommends that
   all designs and implementations should minimise the cases in which IP
   addresses are stored in non-volatile storage maintained by humans,
   such as configuration files.  Configuration information used by
   TCP/IP protocols should be expressed, whenever possible, in terms of
   Fully Qualified Domain Names, rather than IP addresses. Hardcoding IP
   addresses into applications should be deprecated.  Files containing
   lists of name to address mappings, other than that used as part of
   DNS configuration, should be deprecated, and avoided wherever
   possible.

以上に番号を付け替えさせるのを可能にするように、IABは、すべてのデザインと実装がIPアドレスが人間によって維持された非揮発性記憶装置で保存される場合を最小とならせるべきであることを強く勧めます、構成ファイルなどのように。 TCP/IPプロトコルによって使用される設定情報は言い表されるべきです、可能であるときはいつも、IPアドレスよりむしろFully Qualified Domain Namesに関して。 IPアドレスをアプリケーションにHardcodingするのは推奨しないはずです。 DNS構成の一部として使用されるのを除いて、名前のリストをアドレス・マッピングに含むファイルは、どこでも、可能であるところで推奨しなく、避けられるべきです。

   There are times when legacy applications which require configuration
   files with IP addresses rather than Domain Names cannot be upgraded
   to meet these recommendations. In those cases, it is recommended that
   the configuration files be generated automatically from another file
   which uses Domain Names, with the substitution of addresses being
   done by lookup in the DNS.

Domain NamesよりむしろIPアドレスがある構成ファイルを必要とするレガシーアプリケーションがこれらの推薦を満たすためにアップグレードできない回があります。 それらの場合では、構成ファイルがDomain Namesを使用する別のファイルから自動的に生成されるのは、お勧めです、DNSのルックアップでアドレスの代替をしていて。

   Use of licensing technology that is based upon the IP address of a
   host system makes renumbering quite difficult. Therefore, the use of
   such technology should be strongly discouraged.

ホストシステムのIPアドレスに基づいている認可技術の使用で、番号を付け替えるのはかなり難しくなります。 したがって、そのような技術の使用は強くお勧めできなくあるべきです。

   The development and deployment of a toolkit to facilitate and
   automate host renumbering is essential.  The Dynamic Host
   Configuration Protocol (DHCP) is clearly an essential part of such a
   toolkit.  The IAB strongly encourages implementation and wide-scale
   deployment of DHCP.  Dynamic router discovery (RFC 1256) and service
   location (work in progress in the IETF) also belong in this toolkit.
   Support for dynamic update capabilities to the Domain Name System
   (DNS) that could be done with sufficient authentication would further
   facilitate host renumbering.  The IAB strongly encourages progression
   of work in this area towards standardization within the IETF, with
   the goal of integrating DHCP and dynamic update capabilities to
   provide truly autoconfigurable TCP/IP hosts.

ホストの番号を付け替えることを容易にして、自動化するツールキットの開発と展開は不可欠です。 Dynamic Host Configuration Protocol(DHCP)は明確にそのようなツールキットの不可欠の部分です。 IABは強くDHCPの実装と広いスケール展開を奨励します。 また、このツールキットにはダイナミックなルータ発見(RFC1256)とサービス位置(IETFの処理中の作業)があります。 十分な認証でできたドメインネームシステム(DNS)へのダイナミックなアップデート能力のサポートはさらにホストの番号を付け替えることを容易にするでしょう。 IABはこの領域で強くIETFの中の標準化に向かって仕事の進行を奨励します、DHCPと本当に自動構成可能なTCP/IPホストを提供するダイナミックなアップデート能力を統合するという目標のために。

Carpenter & Rekhter          Informational                      [Page 3]

RFC 1900                 Renumbering Needs Work            February 1996

仕事1996年2月に必要性に番号を付け替えさせる大工とRekhterの情報[3ページ]のRFC1900

   The IAB strongly encourages sharing of experience with renumbering
   and documenting this sharing within the Internet community.  The IAB
   suggests that the IETF (and specifically its Operational Requirements
   Area) may be the most appropriate place to develop such
   documentation.  The IAB welcomes the creation of the PIER (Procedures
   for Internet and Enterprise Renumbering) working group.

IABは、インターネットコミュニティの中にこの共有の番号を付け替えて、記録すると経験を共有するよう強く奨励します。 IABは、IETF(そして、明確にOperational Requirements Area)がそのようなドキュメンテーションを開発する最も適切な場所であるかもしれないと示唆します。 IABはPIER(インターネットとエンタープライズRenumberingへの手順)ワーキンググループの創設を歓迎します。

4. Security Considerations

4. セキュリティ問題

   Renumbering is believed to be compatible with the Internet security
   architecture, as long as addresses do not change during the lifetime
   of a security association.

番号を付け替えるのはインターネットセキュリティー体系と互換性があると信じられています、アドレスがセキュリティ協会の生涯変化しない限り。

Acknowledgements

承認

   This document is a collective product of the Internet Architecture
   Board.

このドキュメントはインターネット・アーキテクチャ委員会の集合的な製品です。

   Useful comments were received from several people, especially Michael
   Patton, Steve Bellovin, Jeff Schiller, and Bill Simpson.

数人、特にマイケル・パットン、スティーブBellovin、ジェフ・シラー、およびビル・シンプソンから役に立つコメントを受けました。

Authors' Addresses

作者のアドレス

   Brian E. Carpenter
   Group Leader, Communications Systems
   Computing and Networks Division
   CERN
   European Laboratory for Particle Physics
   1211 Geneva 23, Switzerland

ブライアンE.大工のグループのリーダーと通信網コンピューティングとネットワーク事業部CERN欧州原子核共同研究機構1211ジュネーブ23、スイス

   Phone:  +41 22 767-4967
   Fax:    +41 22 767-7155
   Telex:  419000 cer ch
   EMail: brian@dxcoms.cern.ch

以下に電話をしてください。 +41 22 767-4967Fax: +41 22 767-7155 テレックスで送信してください: 419000cer ch EMail: brian@dxcoms.cern.ch

   Yakov Rekhter
   cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134

ヤコフRekhterコクチマスのSystems170の西タスマン・Driveサンノゼ、カリフォルニア 95134

   Phone: (914) 528-0090
   EMail: yakov@cisco.com

以下に電話をしてください。 (914) 528-0090 メールしてください: yakov@cisco.com

Carpenter & Rekhter          Informational                      [Page 4]

大工とRekhter情報です。[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

マルチバイト文字列(日本語文字)を一文字づつ取り出す

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る