RFC2072 日本語訳
2072 Router Renumbering Guide. H. Berkowitz. January 1997. (Format: TXT=110591 bytes) (Updated by RFC4192) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Berkowitz Request for Comments: 2072 PSC International Category: Informational January 1997
コメントを求めるワーキンググループH.バーコウィッツ要求をネットワークでつないでください: 2072年のPSCの国際カテゴリ: 情報の1997年1月
Router Renumbering Guide
ガイドに番号を付け替えさせるルータ
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
要約
IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes in Internet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration.
現在組織によって使用されているIPアドレスは、用語を加減するために近さで移り変わりそうです。 変化はさまざまな理由に必要になることができます、企業再編成を含んでいて設備の物理的な移動(新しい戦略の関係)は世界的なインターネットの接続性のインターネットサービスプロバイダ(ISP)、新しいアプリケーション、および必要性で変化します。 一般に、良いIPアドレス経営者側は継続するシステム管理を簡素化するかもしれません。 また、プランに番号を付け替えさせる利益は良い付番プランです。 将来の番号を付け替えることを緩和するために取られたほとんどの行動が通常のネットワーク管理を緩和するでしょう。
Routers are the components that interconnect parts of the IP address space identified by unique prefixes. Obviously, they will be impacted by renumbering. Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering. The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort.
ルータはIPアドレス空間の内部連絡の部品がユニークな接頭語で特定したコンポーネントです。 明らかに、番号を付け替えることによって、それらに影響を与えるでしょう。 橋などの他のインタコネクト装置は2個のスイッチ(すなわち、橋を専門にする)、およびスイッチが番号を付け替えるのに影響を受けさせるかもしれないATMを層にします。 番号を付け替えることの努力の一部であるとルータとのこれらの下層インタコネクト装置の相互作用をみなさなければなりません。
Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering.
DNSとSNMPを含んでいて、ルータは多数のネットワークインフラサーバと対話します。 ルータの番号を付け替えることの一部であると純粋なアドレシングとルーティング構造だけではなく、これらの相互作用をみなさなければなりません。
Berkowitz Informational [Page 1] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[1ページ]のRFC2072Router
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivations for Renumbering . . . . . . . . . . . . . . . . 3 4. Numbering and Renumbering. . . . . . . . . . . . . . . . . . 9 5. Moving toward a Renumbering-Friendly Enterprise. . . . . . . 13 6. Potential Pitfalls in Router Renumbering. . . . . . . . . 20 7. Tools and Methods for Renumbering . . . . . . . . . . . . 25 8. Router Identifiers . . . . . . . . . . . . . . . . . . . . . 29 9. Filtering and Access Control . . . . . . . . . . . . . . . . 35 10. Interior Routing . . . . . . . . . . . . . . . . . . . . . . 37 11. Exterior Routing . . . . . . . . . . . . . . . . . . . . . . 39 12. Network Management . . . . . . . . . . . . . . . . . . . . . 41 13. IP and Protocol Encapsulation . . . . . . . . . . . . . . . 43 14. Security Considerations. . . . . . . . . . . . . . . . . . . 44 15. Planning and Implementing the Renumbering . . . . . . . . . 44 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 18. Author's Address . . . . . . . . . . . . . . . . . . . . . . 48
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 注意書き. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 番号を付け替え. . . . . . . . . . . . . . . . 3 4るのに関する動機。 付番して、番号を付け替えます。 . . . . . . . . . . . . . . . . . 9 5. 番号を付け替えるに優しいエンタープライズに近づきます。 . . . . . . 13 6. ルータの番号を付け替えることにおける潜在的落とし穴。 . . . . . . . . 20 7. 番号を付け替え. . . . . . . . . . . . 25 8るツールと方法。 ルータ識別子. . . . . . . . . . . . . . . . . . . . . 29 9。 フィルタリングとアクセス管理. . . . . . . . . . . . . . . . 35 10。 内部のルート設定. . . . . . . . . . . . . . . . . . . . . . 37 11。 外のルート設定. . . . . . . . . . . . . . . . . . . . . . 39 12。 ネットワークマネージメント. . . . . . . . . . . . . . . . . . . . . 41 13。 IPとプロトコルカプセル化. . . . . . . . . . . . . . . 43 14。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . 44 15. 番号を付け替え. . . . . . . . . 44 16ることを計画して、実行します。 承認. . . . . . . . . . . . . . . . . . . . . . 46 17。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 47 18。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction
1. 序論
Organizations can decide to renumber part or all of their IP address space for a variety of reasons. Overall motivations for renumbering are discussed in [RFC2071]. This document deals with the router- related aspects of a renumbering effort, once the decision to renumber has been made.
組織は、さまざまな理由によるそれらのIPアドレス空間の部分かすべてに番号を付け替えさせると決めることができます。 [RFC2071]で番号を付け替えるのに関する総合的な動機について議論します。 いったん番号を付け替えさせる決定をすると、このドキュメントは番号を付け替えることの努力の関係づけられたルータ局面に対処します。
A renumbering effort must be well-planned if it is to be successful. This document deals with planning and implementation guidelines for the interconnection devices of an enterprise. Of these devices, routers have the clearest association with the IP numbering plan.
うまくいくつもりであるなら、番号を付け替えることの努力はよく計画していなければなりません。 このドキュメントは企業のインタコネクト装置のための計画と実施要綱に対処します。 これらの装置に、ルータには、IP付番プランとの最も明確な協会があります。
Planning begins with understanding the problem to be solved. Such understanding includes both the motivation for renumbering and the technical issues involved in renumbering.
計画は解決すべき課題を理解しているのに始まります。 そのような理解は番号を付け替えるのに関する動機と番号を付け替えるのにかかわる専門的な問題の両方を含んでいます。
1. Begin with a short and clear statement of the reason to
renumber. Section 3 of this document discusses common
reasons.
1. 番号を付け替えさせる理由の短くて明確な声明で、始まってください。 このドキュメントのセクション3は一般的な理由について論じます。
2. Understand the principles of numbering in the present and
planned environments. Section 4 reviews numbering and
suggests a method for describing the scope of renumbering.
2. 現在の、そして、計画された環境における付番の原則を理解してください。 セクション4は、番号を付け替えることの範囲について説明するために付番を見直して、方法を示します。
Berkowitz Informational [Page 2] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[2ページ]のRFC2072Router
3. Before the actual renumbering, it can be useful to evolve
the current environment and current numbering to a more
"renumbering-friendly" system. Section 5 discusses ways to
introduce renumbering friendliness into current systems.
3. 実際の番号を付け替えることの前に、より「番号を付け替えるに優しい」システムに現在の環境と現在の付番を発展するのは役に立つ場合があります。 セクション5は現在のシステムに番号を付け替える友情を取り入れる方法を論じます。
4. Be aware of potential pitfalls. These are discussed in
Section 6.
4. 潜在的落とし穴を意識してください。 セクション6でこれらについて議論します。
5. Identify potential requirements for tools, discussed in
Section 7.
5. セクション7で議論したツールのための潜在的要件を特定してください。
6. Evaluate the specific router mechanisms that will be affected
by renumbering. See Sections 8 through 13.
6. 番号を付け替えることによって影響を受ける特定のルータメカニズムを評価してください。 セクション8〜13を見てください。
7. Set up a specific transition plan framework. Guidelines
for such planning are in Section 15.
7. 特定の変遷プラン枠組みをセットアップしてください。 そのような計画のためのガイドラインがセクション15にあります。
When trying to understand the interactions of renumbering on routers, remember there different aspects to the problem, depending on the scope of the renumbering involved. Remember that even an enterprise-wide renumbering probably will not affect all IP addresses visible within the enterprise, since some addresses (e.g., Internet service providers, external business partners) are outside the address space under the control of the enterprise.
ルータにおける番号を付け替えることの相互作用を理解していようとするとき、そこで異なった局面を問題に覚えていてください、かかわった番号を付け替えることの範囲によって。 企業全体の番号を付け替えるさえたぶん企業の中で目に見えるすべてのIPアドレスに影響するというわけではないのを覚えていてください、いくつかのアドレス(例えば、インターネット接続サービス業者、外部のビジネスパートナー)がアドレス空間の外で企業のコントロールの下にあるので。
2. Disclaimer
2. 注意書き
The main part of this document is intended to be vendor-independent. Not all features discussed, of course, have been implemented on all routers. This document should not be used as a general comparison of the richness of features of different implementations. References here are only to those features affected by renumbering. Some illustrative examples may be used that cite vendor-specific characteristics. These examples do not necessarily reflect the current status of products.
このドキュメントの主部が業者から独立していることを意図します。 もちろん議論したというわけではないすべての特徴がすべてのルータで実行されました。 異なった実現の特徴の豊か一般比較としてこのドキュメントを使用するべきではありません。 番号を付け替えることによって影響を受けるそれらの特徴だけにはここでの参照があります。 業者特有の特性を引用するいくつかの説明に役立つ実例が使用されるかもしれません。 これらの例は必ず製品の現在の状態を反映するというわけではありません。
3. Motivations for Renumbering
3. 番号を付け替えるのに関する動機
Reasons to renumber can be technological, organizational, or both. Technological reasons fall into several broad categories discussed below. Just as there can be both technological and organizational motivations for renumbering [RFC2071], there can be multiple technological reasons.
番号を付け替えさせる理由が技術的であって、組織的である場合がある、または、両方。 技術的な理由は以下で議論したいくつかの広いカテゴリになります。 ちょうど技術的なものと[RFC2071]に番号を付け替えさせることに関する同様に組織的な動機があることができるので、複数の技術的な理由があることができます。
There may not be a clear line between organizational and technical reasons for renumbering. While networks have a charm and beauty all their own, the organizational reasons should be defined first in order to justify the budget for the technical renumbering. There
番号を付け替えることの組織的で技術的な理由の間には、明確な線がないかもしれません。 ネットワークである間、魅力と美はそれら自身のを飼ってください、そして、組織的な理由は、最初に、技術的な番号を付け替える予算を正当化するために定義されるべきです。 そこでは
Berkowitz Informational [Page 3] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[3ページ]のRFC2072Router
also may be pure technnical reasons to renumber, such as changes in technology (e.g., from bridging to routing).
また、技術(例えば、橋を架けるのからルーティングまでの)における変化などのように番号を付け替えさせる純粋なtechnnical理由であるかもしれません。
While this document is titled "Router Renumbering Guide," it recognizes that renumbering may be required due to the initial installation of routers in a bridged legacy network. Organizations may have had an adequate bridging solution that did not scale with growth. Some organizations could not able to move to routers until router forwarding performance improved [Carpenter] to be comparable to bridges.
このドキュメントは「ガイドに番号を付け替えさせるルータ」と題をつけられますが、それは、番号を付け替えることが橋を架けられた遺産ネットワークにおける、ルータの初度施設のため必要であるかもしれないと認めます。 組織には、成長で比例しなかった適切な橋を架ける解決策があったかもしれません。 いくつかの組織は動くことができました。ルータ推進性能が橋に匹敵しているために向上するまで[大工仕事をします]、ルータに動くことができません。
Other considerations include compliance with routing outside the organization. Routing issues here are primarily those of the global Internet, but may also involve bilateral private links to other enterprises.
他の問題は組織の外にルーティングへのコンプライアンスを含んでいます。 ここのルート設定問題は、主として世界的なインターネットのものですが、また、他の企業への双方の個人的なリンクにかかわるかもしれません。
Certain new transmission technologies have tended to redefine the basic notion of an IP subnet. The numbering plan needs to work with these new ideas. Legacy bridged networks and leading-edge workgroup switched networks may very well need changes in the subnetting structure. Renumbering needs may also develop with the introduction of new WAN technologies, especially nonbroadcast multiaccess (NBMA) services such as frame relay. Other WAN technologies, dialup media using modems or ISDN, also may have new routing and numbering requirements. Switched virtual circuit services such as ATM, X.25, or switched frame relay also interact with routing and addressing.
ある新しいトランスミッション技術は、IPサブネットの基本的な概念を再定義する傾向がありました。 付番プランは、これらの新しいアイデアで働く必要があります。 遺産の橋を架けられたネットワークとリーディングエッジのワークグループ交換網はサブネッティング構造の変化を非常によく必要とするかもしれません。 また、必要性に番号を付け替えさせるのは新しいWAN技術(特にフレームリレーなどの非放送多重処理(NBMA)サービス)の導入で展開するかもしれません。 また、他のWAN技術(モデムかISDNを使用するダイアルアップメディア)には、新しいルーティングと付番要件があるかもしれません。 また、ATM、X.25、または切り換えられたフレームリレーなどの交換仮想回路サービスはルーティングとアドレシングと対話します。
3.1 Internet Global Routing
3.1 インターネットのグローバルなルート設定
Many discussions of renumbering emphasize interactions among organizations' numbering plans and those of the global Internet [RFC1900]. There can be equally strong motivations for renumbering in organizations that never connect to the global Internet.
組織が世界的なインターネット[RFC1900]のプランとものに付番する中で番号を付け替えることの多くの議論が相互作用を強調します。 世界的なインターネットに決して接続しない組織における番号を付け替えるのに関する強い動機が等しくあることができます。
According to RFC1900, "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....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.
RFC1900によると、「実行可能な代案が開発されるまで、Classless Inter-ドメインルート設定(CIDR)の拡張展開はインターネット・ルーティングシステムを生かして、インターネットの連続したとぎれない成長を維持するために重大です」…そのような組織が新しいサービスプロバイダーに変化するときはいつも、ルーティング情報の成長を含むように、組織のアドレスは変化しなければならないでしょう。
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.... 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
時折、サービスプロバイダー自体はアドレス空間の新しくて、より大きいブロックに変化しなければならないかもしれません。 ルーティング情報の成長を含むのに、これらのケースのどちらかでは、関する組織が、必要があるだろう、番号を付け替えます。 組織が番号を付け替えない、そして、潜在的結果のいくつかが(a) 限られた(インターネット全体であるよりそれほど)IPの接続性、または(b) 追加費用を含むかもしれません。
Berkowitz Informational [Page 4] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[4ページ]のRFC2072Router
to offset the overhead associated with the organization's routing information that Internet Service Providers have to maintain, or both."
「インターネットサービスプロバイダが保守しなければならない組織のルーティング情報に関連しているオーバーヘッド、または両方を相殺するために。」
3.2 Bridge Limitations; Internal Use of LAN Switching
3.2 制限に橋を架けてください。 LANの切り換えの内部の使用
Introducing workgroup switches may introduce subtle renumbering needs. Fundamentally, workgroup switches are specialized, high- performance bridges, which make their main forwarding decisions based on Layer 2 (MAC) address information. Even so, they rarely are independent of Layer 3 (IP) address structure. Pure Layer 2 switching has a "flat" address space that will need to be renumbered into a hierarchical, subnetted space consistent with routing. Traditional bridged networks share many of the problems of workgroup switches, but have additional performance problems when bridged connectivity extends across slow WAN links.
必要性に番号を付け替えさせながら、微妙な状態でスイッチが導入するかもしれないワークグループを導入します。 基本的に、ワークグループスイッチは専門化していて、高い性能橋です。(その橋は彼らの主な推進をLayer2(MAC)アドレス情報に基づく決定にします)。 たとえそうだとしても、それらはLayer3(IP)アドレス構造からめったに独立していません。 純粋なLayer2の切り換えには、ルーティングと一致した階層的で、「副-網で覆」われたスペースに番号を付け替えられる必要がある「平坦な」アドレス空間があります。 伝統的な橋を架けられたネットワークには、ワークグループスイッチの問題の多くを共有しますが、橋を架けられた接続性が遅いWANリンクに達すると、追加性能問題があります。
Introducting single switches or stacks of switches may not have significant impact on addressing, as long as it is remembered that each system of switches is a single broadcast domain. Each broadcast domain should map to a single IP subnet.
スイッチの単一のスイッチかスタックをIntroductingするのは重要な影響をアドレシングに与えないかもしれません、スイッチの各システムがただ一つの放送ドメインであることが覚えていられる限り。 それぞれの放送ドメインは単一のIPにサブネットを写像するべきです。
Virtual LANs (VLAN) further extend the complexity of the role of workgroup switches. It is generally true that moving an end station from one switch port to another within the same "color" VLAN will not cause major changes in addressing. Many discussions of this technology do not make it clear that moving the same end station between different colors will move the end station into another IP subnet, requiring a significant address change.
バーチャルLAN(VLAN)はさらにワークグループスイッチの役割の複雑さを広げています。 一般に、同じ「色」VLANの中で1つのスイッチポートから別のものへ端のステーションを移すのがアドレシングにおける大きな変化を引き起こさないのは、本当です。 この技術の多くの議論は、異なった色の間の同じ端のステーションを移転させると端のステーションが別のIPサブネットに移転すると断言しません、重要なアドレス変化を必要として。
Switches are commonly managed by SNMP applications. These network management applications communicate with managed devices using IP. Even if the switch does not do IP forwarding, it will itself need IP addresses if it is to be managed. Also, if the clients and servers in the workgroup are managed by SNMP, they will need IP addresses. The workgroup, therefore, will need to appear as one or more IP subnets.
スイッチはSNMPアプリケーションで一般的に管理されます。 これらのネットワークマネージメントアプリケーションは、IPを使用することで管理された装置とコミュニケートします。 それが管理されるつもりであり、スイッチがIP推進をしないでも、それは必要性IPアドレスをそれ自体に望んでいます。 また、ワークグループにおけるクライアントとサーバがSNMPによって管理されると、彼らはIPアドレスを必要とするでしょう。 したがって、ワークグループは、1つ以上のIPサブネットとして現れる必要があるでしょう。
Increasingly, internetworking products are not purely Layer 2 or Layer 3 devices. A workgroup switch product often includes a router function, so the numbering plan must support both flat Layer 2 and hierarchical Layer 3 addresses.
ますます、インターネットワーキング製品は純粋にLayer2かLayer3装置ではありません。 ワークグループスイッチ製品がしばしばルータ機能を含んでいるので、付番プランは平坦なLayer2と階層的なLayer両方の3つのアドレスをサポートしなければなりません。
Berkowitz Informational [Page 5] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[5ページ]のRFC2072Router
3.3 Internal Use of NBMA Cloud Services
3.3 NBMA雲のサービスの内部の使用
"Cloud" services such as frame relay often are more economical than traditional services. At first glance, when converting existing enterprise networks to NBMA, it might appear that the existing subnet structure should be preserved, but this is often not the case.
フレームリレーなどの「雲」サービスは伝統的なサービスよりしばしば経済的です。 既存企業ネットワークをNBMAに変換するとき、一見したところでは、既存のサブネット構造が保存されるべきであるように見えるかもしれませんが、これはしばしばそうであるというわけではありません。
Many organizations often began by treating the "cloud" as a single subnet, but experience has shown it is often better to treat the individual virtual circuits as separate subnets. When the individual point-to-point VCs become separate subnets, efficient address utilization requires the use of /30 prefixes for these subnets. This typically means the addressing and routing plan must support multiple prefix lengths, establishing one or more prefix lengths for LAN media with more than two hosts, and subdividing one or more of these shorter prefixes into longer /30 prefixes that minimize address loss.
多くの組織が「雲」をただ一つのサブネットとして扱うことによって、しばしば始まりましたが、経験は、しばしば個々の仮想のサーキットを別々のサブネットとして扱うほうがよいのを示しました。 個々の二地点間VCsが別々のサブネットになると、効率的なアドレス利用は/30接頭語のこれらのサブネットの使用を必要とします。 これは、アドレシングとルーティングプランが複数の接頭語の長さを支持しなければならないことを通常意味します、LANメディアのために2人以上のホストと共に1つ以上の接頭語の長さを確立して、これらのより短い接頭語の1つ以上をアドレスの損失を最小にするより長い/30接頭語に細分して。
There are alternative ways to configure routing over NBMA, using special mechanisms to exploit or simulate point-to-multipoint VCs. These often have a significant performance impact on the router, and may be less reliable because a single point of failure is created. Mechanics of these alternatives are discussed later in this section, but the motivations for such alternatives tend to include:
ポイントツーマルチポイントVCsを利用するか、またはシミュレートするのに特別なメカニズムを使用して、NBMAの上でルーティングを構成する代替の方法があります。 これらは、しばしば重要な性能影響をルータに与えて、1ポイントの失敗が作成されるので、それほど信頼できないかもしれません。 後でこのセクションでこれらの代替手段の整備士について議論しますが、そのような代替手段に関する動機は、以下を含んでいる傾向があります。
1. A desire not to use VLSM. This is often founded in fear
rather than technology.
2. Router implementation issues that limit the number of subnets
or interfaces a given router can support.
3. An inherently point-to-multipoint application (e.g., remote
hosts to a data center). In such cases, some of the
limitations are due to the dynamic routing protocol in use.
In such "star" applications, static routing may actually be
preferable from performance and flexibility standpoints,
since it does not produce routing traffic and is unaffected
by split horizon.
1. VLSMを使用しない願望。 これはしばしば技術よりむしろ恐怖で設立されます。 2. サブネットの数を制限するルータ実現問題か与えられたルータが支持できるインタフェース。 3. 本来のポイントツーマルチポイントアプリケーション(例えば、データセンターへのリモートホスト)。 そのような場合、制限のいくつかがダイナミックルーティングプロトコルの使用中にためです。 そのような「星」アプリケーションでは、スタティックルーティングは実際に性能と柔軟性見地から望ましいかもしれません、それがルーティング交通を作成しないで、分裂地平線のそばで影響を受けないので。
To understand how use of NBMA services affects the addressing structure and routers, it is worth reviewing what would appear to be very basic concepts of IP subnets. The traditional view is that a single subnet is associated with a single physical medium. All hosts physically connected to this medium are assumed to be able to reach all other hosts on the same medium, using data link level services. These services are medium specific: hosts connected to a LAN medium can broadcast to one another, while hosts connected to a point-to- point line simply need to transmit to the other end.
NBMAサービスの使用がどのようにアドレシング構造とルータに影響するかを理解するために、IPサブネットの非常に基本の概念であるように見えることを見直す価値があります。 伝統的な視点はただ一つのサブネットが単独の物理的な媒体に関連しているということです。 物理的にこの媒体に接続されたすべてのホストが同じ媒体の上の他のすべてのホストに届くことができると思われます、データ・リンクレベルサービスを利用して。 これらのサービスは媒体特有です: LAN媒体に接続されたホストはお互いに放送できます、単にポイントからポイントへの線に接続されたホストが、もう一方の端まで伝わる必要がありますが。
Berkowitz Informational [Page 6] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[6ページ]のRFC2072Router
When one host desires to transmit to another, it first determines if the destination is local or remote. A local destination is on the same subnet and assumed to be reachable through data link services. A remote destination is on a different subnet, and it is assumed that router intervention is needed to reach it.
1人のホストが、別のものに伝わることを望んでいるとき、それは、最初に、目的地が地方である、または遠く離れているかを決定します。 地方の目的地は、同じサブネットにあって、データ・リンクサービスで届くと思われます。 遠く離れた目的地が異なったサブネットにあります、そして、ルータ介入がそれに達するのに必要であると思われます。
The first NBMA problem comes up when a single subnet is implemented over an NBMA service. Frame Relay provides single virtual circuits between hosts that have connectivity. It is quite common to design Frame Relay services as partial meshes, where not all hosts have VCs to all others. When the set of hosts in a partial mesh is in a single IP subnet, partial mesh violates the local model of full connectivity. Even when there is full meshing, a pessimistic but reasonable operational model must consider that individual VCs do fail, and full connectivity may be lost transiently.
ただ一つのサブネットがNBMAサービスの上で実行されるとき、最初のNBMA問題は来ます。 フレームRelayは接続性を持っているホストの間のただ一つの仮想のサーキットを提供します。 部分的なメッシュとしてFrame Relayサービスを設計するのは全く一般的です。(そこでは、すべてのホストがすべての他のものにVCsを持っているというわけではありません)。 ただ一つのIPサブネットに部分的なメッシュのホストのセットがあるとき、部分的なメッシュは完全な接続性のローカルのモデルに違反します。 完全なメッシュさえありさえするときさえ、悲観的な、しかし、合理的なオペレーショナル・モデルは、個々のVCsが失敗すると考えなければなりません、そして、完全な接続性ははかなく、失われるかもしれません。
There are several ways to deal with this violation, each with their own limitations. If a specific "central" host has connectivity to N all other hosts, that central host can replicate all frames it receives from one host onto outgoing VCs connecting it with the (N-1) other hosts in the subnet. Such replication usually causes an appreciable CPU load in the replicating router. The replicating router also is a single point of failure for the subnet. This method does not scale well when extended to fuller meshes within the subnet.
それぞれそれら自身の制限でこの違反に対処するいくつかの方法があります。 特定の「中央」のホストに接続性が他のNホストまであるなら、その主要なホストは、サブネットで他の(N-1)ホストにそれに接しながら、それが1人のホストから出発しているVCsに受けるすべてのフレームを模写できます。 通常、そのような模写は模写ルータでかなりのCPU荷重を引き起こします。 模写ルータもサブネットのための1ポイントの失敗です。 サブネットの中で、よりふくよかなメッシュに広げられる場合、この方法はよく比例しません。
In a routing protocol, such as OSPF, that has a concept of designated routers, explicit configuration usually is needed. Other problems in using a meshed subnet is that all VCs may not have the same performance, but the router cannot prefer individual paths within the subnet.
代表ルータの概念を持っているOSPFなどのルーティング・プロトコルでは、通常、明白な構成が必要です。 かみ合っているサブネットを使用することにおける他の問題はすべてのVCsには同じ性能がないかもしれませんが、ルータがサブネットの中で個々の経路を好むことができないということです。
One of the simplest methods is not to attempt to emulate a broadcast medium, but simply to treat each VC as a separate subnet. This will cause a need for renumbering. Efficient use of the address space dictates a /30 prefix be used for the per-VC subnets. Such a prefix often needs VLSM support in the routers.
最も簡単な方法の1つは放送媒体を見習うのを試みるのではなく、単に別々のサブネットとして各VCを扱うことです。 これは番号を付け替えることの必要性を引き起こすでしょう。 アドレス空間の効率的な使用は/30接頭語を決めます。1VCあたりのサブネットには、使用されてください。 そのような接頭語はしばしばルータにおけるVLSMサポートを必要とします。
3.4 Expansion of Dialup Services
3.4 ダイアルアップサービスの拡大
Dialup services, especially public Internet access providers, are undergoing explosive growth. This success represents a particular drain on the available address space, especially with a commonly used practice of assigning unique addresses to each customer.
ダイアルアップサービス(特に公共のインターネット・アクセス・プロバイダー)は爆発的成長を受けています。 この成功は利用可能なアドレス空間への特定の負担を表します、特にユニークなアドレスを各顧客に割り当てる一般的に使用された習慣で。
Berkowitz Informational [Page 7] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[7ページ]のRFC2072Router
In this practice, individual users announce their address to the access server using PPP's IP configuration option [RFC1332]. The server may validate the proposed address against some user identifier, or simply make the address active in a subnet to which the access server (or set of bridged access servers) belongs.
この習慣では、個々のユーザは、彼らのアドレスをアクセス・サーバーにPPPのIP設定オプション[RFC1332]を使用することで発表します。 サーバで、何らかのユーザ識別子に対して提案されたアドレスを有効にするか、またはアドレスは単にアクセス・サーバー(または、橋を架けられたアクセス・サーバーのセット)が属するサブネットでアクティブになるかもしれません。
These access server functions may be part of the software of a "router" and thus are within the scope of this Guide.
これらのアクセス・サーバー機能は、「ルータ」のソフトウェアの一部であるかもしれなく、その結果、このガイドの範囲の中にあります。
The preferred technique [Hubbard] is to allocate dynamic addresses to the user from a pool of addresses available to the access server. Various mechanisms are used actually to do this assignment, and are discussed in Section 5.5.
都合のよいテクニック[ハバード]はダイナミックなアドレスをアクセス・サーバーに利用可能なアドレスのプールからユーザに割り当てることです。様々なメカニズムについて、実際にこの課題をするのに使用されて、セクション5.5で議論します。
3.5 Internal Use of Switched Virtual Circuit Services
3.5 交換仮想回路サービスの内部の使用
Services such as ATM virtual circuits, switched frame relay, etc., present challenges not considered in the original IP design. The basic IP decision in forwarding a packet is whether the destination is local or remote, in relation to the source host's subnet. Address resolution mechanisms are used to find the medium address of the destination in the case of local destinations, or to find the medium address of the router in the case of remote routers.
ATMの仮想のサーキット、切り換えられたフレームリレーなどのサービスはオリジナルのIPデザインで考えられなかった挑戦を提示します。 パケットを進めることにおける基本的なIP決定は目的地が地方である、または遠く離れているということです、送信元ホストのサブネットと関連して。 アドレス解決メカニズムは、地方の目的地の場合で目的地の中型のアドレスを見つけるか、またはリモートルータの場合でルータの中型のアドレスを見つけるのに使用されます。
In these new services, there are cases where it is far more effective to "cut-through" a new virtual circuit to the destination. If the destination is on a different subnet than the source, the cut-through typically is to the egress router that serves the destination subnet.
これらの新種業務には、ケースが新しい仮想のサーキットが目的地に「深く切る」であることがはるかに効果的であるところにあります。 目的地がソースと異なったサブネットにあるなら、目的地サブネットに役立つ出口ルータには通じて切れるのが通常あります。
The advantage of cut-through in such a case is that it avoids the latency of multiple router hops, and reduces load on "backbone" routers. The cut-through decision is usually made by an entry router that is aware of both the routed and switched environments.
通じて切れる利点はこのような場合には複数のルータホップの潜在を避けて、「背骨」ルータで負荷を減少させるということです。 発送されて切り換えられた環境を知っているエントリールータは通常深く切っている決定をします。
This entry router communicates with a address resolution server using the Next Hop Resolution Protocol (NHRP) [Cansever] [Katz]. This server maps the destination network address to either a next-hop router (where cut-through is not appropriate) or to an egress router reached over the switched service. Obviously, the data base in such a server may be affected by renumbering. Clients may have a hard- coded address of the server, which again may need to change.
このエントリールータは、Next Hop Resolutionプロトコル(NHRP)[Cansever][キャッツ]を使用することでアドレス解決サーバとコミュニケートします。 このサーバは次のホップルータ(通じて切れるのが適切でないところ)、または、切り換えられたサービスの上で達した出口ルータに目的地ネットワーク・アドレスを写像します。 明らかに、そのようなサーバのデータベースは、番号を付け替えることによって、影響を受けるかもしれません。 クライアントには、サーバの困難なコード化されたアドレスがあるかもしれません。(再び、サーバは変化する必要があるかもしれません)。
While the NHRP work is in progress at the time of this writing, commercial implementations based on drafts of the protocol standard are in use.
NHRP仕事はこの書くこと時点で、進行していますが、プロトコル標準の草稿に基づく商業実現は使用中です。
Berkowitz Informational [Page 8] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[8ページ]のRFC2072Router
4. Numbering and Renumbering
4. 付番と番号を付け替えること
What is the role of any numbering plan? To understand the general problem, it can be worthwhile to review the basic principles of routers. While most readers will have a good intuitive sense of this, the principles have refined in the current usage of IP.
どんな付番プランの役割も何ですか? 一般的問題を理解するために、ルータの基本原理を見直す価値がある場合があります。 ほとんどの読者がこの良い直感的な感覚を持つ間、原則はIPの現在の使用法で洗練されています。
A router receives an inbound IP datagram on one of its interfaces, and examines some number of bits of the destination address. The sequence of bits examined by the router always begin at the left of the address (i.e., the most significant bit). We call this sequence a "prefix."
ルータは、インタフェースの1つで本国行きのIPデータグラムを受けて、送付先アドレスの何らかの数のビットを調べます。 いつもルータによって調べられたビットの系列はアドレス(すなわち、最も重要なビット)左側始まります。 私たちは、この系列を「接頭語」と呼びます。
Routing decisions are made on totalPrefix bits, which start at the leftmost (i.e., most significant) bit position of the IP address. Those totalPrefix bits may be completely under the control of the enterprise (e.g., if they are in the private address space), or the enterprise may control the lowOrderPrefix bits while the highOrderPrefix bits are assigned by an outside organization.
totalPrefixビットの上でルート設定決定をします。ビットはIPアドレスの一番左(すなわち、最も重要な)のビット位置で始動します。 それらのtotalPrefixビットが企業のコントロールの完全下にあるかもしれませんか(例えば、それらがプライベート・アドレススペースにあるなら)、またはhighOrderPrefixビットが外の組織によって割り当てられている間、企業はlowOrderPrefixビットを制御するかもしれません。
The router looks up the prefix in its routing table (formally called a Forwarding Information Base). If the prefix is in the routing table, the router then selects an outgoing interface that will take the routed packet to the next hop IP address in the end-to-end route. If the prefix cannot be found in the routing table, the router returns an ICMP Destination Unreachable message to the source address in the received datagram.
ルータは経路指定テーブル(正式にForwarding Information基地と呼ばれる)の接頭語を調べます。 接頭語が経路指定テーブルにあるなら、ルータは終わらせる終わりの次のホップIPアドレスルートに発送されたパケットを連れて行く外向的なインタフェースを選択します。 経路指定テーブルで接頭語を見つけることができないなら、ルータは容認されたデータグラムのソースアドレスにICMP Destination Unreachableメッセージを返します。
Assuming the prefix is found in the routing table, the router then transmits the datagram through the indicated outgoing interface. If multicast routing is in effect, the datagram may be copied and sent out multiple outgoing interfaces.
接頭語を仮定するのは経路指定テーブルで見つけられて、次に、ルータは示された外向的なインタフェースを通してデータグラムを送ります。 マルチキャストルーティングが有効であるなら、データグラムは、コピーされたかもしれなくて、複数の外向的なインタフェースを出しました。
Berkowitz Informational [Page 9] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[9ページ]のRFC2072Router
4.1 Categorizing the topology
4.1 トポロジーを分類すること。
From the router renumbering perspective, renumbering impact is apt to be greatest in highly connected parts of "backbones," and least in "stub" parts of the routing domain that have a single route to the backbone.
見解に番号を付け替えさせるルータから、衝撃に番号を付け替えさせるのは、「背骨」の非常に接続された部分で最もすばらしいことでしやすくて、ただ一つのルートを背骨に持っている経路ドメインの「スタッブ」地域で最少です。
Global Internet
^
|
|
Back1-------------------Back2
| |
+-----------+ +----------+
| | | |
Reg1.1------Reg1.2 Reg2.1-----Reg2.2
| | | |
| | | |
Branch Branch Branch Branch
1.1.1 to 1.2.1 to 2.1.1 to 2.2.1 to
1.1.N 1.2.N 2.1.N 2.2.N
グローバルなインターネット^| | Back1-------------------Back2| | +-----------+ +----------+ | | | | Reg1.1------Reg1.2 Reg2.1-----Reg2.2| | | | | | | | 支店支店支店1.1の.1〜1.2に.1〜2.1に.1〜2.2に分岐してください、1.1.N 1.2.N 2.1.N 2.2.Nへの.1
In this drawing, assume Back1 and Back2 exchange full routes; Back1 is also the exterior router. Regional routers (Reg) exchange full routes with one another and aggregate addresses to the backbone routers. Branch routers default to regional routers.
この図面では、Back1とBack2が完全なルートを交換すると仮定してください。 また、Back1は外のルータです。 地方のルータ(レッジ)は背骨ルータへのお互いと集合アドレスと完全なルートを交換します。 支店ルータは地方のルータをデフォルトとします。
From a pure topological standpoint, the higher in the hierarchy, the greater are apt to be the effects of renumbering. This is a first approximation to scoping the task, assuming addresses have been assigned systematically. Systematic address space is rarely the case in legacy networks.
純粋な位相的な見地から、階層構造で、より高くて、よりすばらしいのは、しやすいのが、番号を付け替えることの効果であるということです。 これは系統的にアドレスを割り当ててあると仮定して、タスクを見ることへのまず得られた近似の結果です。 めったに系統的なアドレス空間は遺産ネットワークのケースではありません。
Berkowitz Informational [Page 10] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[10ページ]のRFC2072Router
4.2 Categorizing the address space
4.2 アドレス空間を分類すること。
An inventory of present and planned address space is a prerequisite to successful renumbering. Begin by identifying the prefixes in or planned into your network, and whether they have been assigned in a systematic and hierarchical manner.
現在の、そして、計画されたアドレス空間の目録はうまくいっている番号を付け替えることへの前提条件です。 中で接頭語を特定するか、またはあなたのネットワークに計画されて、それらが系統的で階層的な方法で配属されたか否かに関係なく、始まってください。
+--Unaffected by renumbering [A]
|
|
+--Existing prefixes to be renumbered
| |
| |
| +----To be directly renumbered on "flag day"
| |
| |
| +----Initially to be renumbered to temporary address
|
|
+--Existing prefixes to be retired
|
|
+--Planned new prefixes
|
|
+---totalPrefix change, no length change
|
|
+---highOrderPart change only, no length change
|
|
+---lowOrderPart change only, no length change
|
|
+---highOrderPart change only, high length change
|
|
+---lowOrderPart change only, low length change
|
|
+---totalPrefix change only, changes in high and low
|
|
+---highOrderPart change only, no length change
[A]に番号を付け替えさせることによって影響を受けない+| | +--番号を付け替えるべき既存の接頭語| | | | | +----「旗の日」のときに直接番号を付け替えられるために| | | | | +----初めは仮の住所に番号を付け替えられます。| | +--退職している既存の接頭語| | +--計画された新しい接頭語| | +---totalPrefix変化、長さの変化がありません。| | +---highOrderPartは長さの変化だけを変えません。| | +---lowOrderPartは長さの変化だけを変えません。| | +---highOrderPartは唯一の、そして、高い長さの変化を変えます。| | +---lowOrderPartは唯一の、そして、低い長さの変化を変えます。| | +---totalPrefixは上下における変化だけを変えます。| | +---highOrderPartは長さの変化だけを変えません。
Ideally, a given prefix should either be "unchanged," "old," or "new." Renumbering will be easiest when each "old" prefix can be mapped to a single "new" prefix.
理想的に、与えられた接頭語は、「変わりのない」か、「古い」か、または「新しくあるべきです」。 それぞれの「古い」接頭語をただ一つの「新しい」接頭語に写像できるとき、番号を付け替えることは最も簡単になるでしょう。
Berkowitz Informational [Page 11] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[11ページ]のRFC2072Router
Unfortunately, the ideal often will not be attainable. It may be necessary to run parts of the new and old address spaces in parallel.
残念ながら、理想はしばしば達成できるというわけではないでしょう。 平行な新しくて古いアドレス空間の部品を実行するのが必要であるかもしれません。
Renumbering applies first to prefixes and then to host numbers to the right of the prefix. To understand the scope of renumbering, it is essential to:
番号を付け替えることは最初に接頭語と、そして、そして、接頭語の右へのホスト番号に適用されます。 番号を付け替えることの範囲を理解するのに、それは以下に不可欠です。
1. Identify the prefixes (and possibly host fields) potentially
affected by the renumbering operation.
1. 番号を付け替える操作で潜在的に影響を受ける接頭語(そして、ことによるとホスト分野)を特定してください。
2. Identify the authority that controls the values of the prefix,
or part of the prefix, affected by renumbering.
2. 接頭語の値、または番号を付け替えることによって影響を受ける接頭語の一部を制御する権威を特定してください。
In a given enterprise, prefixes may be present that will be under the complete or partial control of the enterprise, as well as totally outside the control of the enterprise. Let us review the principles of control over address space.
与えられた企業、接頭語には、企業の完全であるか部分的なコントロールの下と、そして、企業のコントロールの完全に外にあるプレゼントがあるかもしれません。 アドレス空間のコントロールの原則を見直しましょう。
More commonly, the most significant bits of the prefix are assigned to the enterprise by an address registry (e.g., InterNIC, RIPE, or APNIC) or by an Internet Service Provider (ISP). This assignment of a value in the most significant bit positions historically has been called a "network number," when the assigned high-order part is 8, 16, or 24 bits long. More recent usage does not limit the assigned part to a byte boundary. The preferred term for the assigned part is a "CIDR block" of a certain number of bits [RFC1518].
より一般的に、接頭語の最も重要なビットはアドレス登録(例えば、InterNIC、RIPE、またはAPNIC)かインターネットサービスプロバイダ(ISP)によって企業に配属されます。 最も重要なビット位置の価値のこの課題は歴史的に「ネットワーク・ナンバー」と呼ばれました、長い間、割り当てられた高位部分が8ビットか16ビットか24ビットであるときに。 より最近の用法は割り当てられた部分をバイト境界に制限しません。 割り当てられた部分への優先使用語はある数のビット[RFC1518]の「CIDRブロック」です。
The enterprise then extends the prefix to the right, creating "subnets." It is critical to realize that routers make routing decisions based on the total prefix of interest, regardless of who controls which bits. In other words, the router really doesn't know or care about subnet boundaries.
そして、「サブネット」を作成して、企業は接頭語を右に広げます。 ルータがルーティングを興味がある総接頭語に基づく決定にするとわかるのは重要です、だれがどのビットを制御するかにかかわらず。 言い換えれば、ルータは、本当にサブネット境界を知りもしませんし、心配もしません。
The way to think about subnetting is that it creates a longer prefix. Even before CIDR, we collapsed multiple subnets into a single network number advertisement sent to external routers. In a more general way, we now think of extending the prefix to the right as subnetting and collapsing it to the left as supernetting, aggregating, or summarizing. Depending on the usage of subnetting or aggregation, different prefix lengths are significant at different router interfaces.
サブネッティングについて考える方法は、より長い接頭語を作成するということです。 CIDRの前で、私たちは外部のルータに送られたただ一つのネットワーク・ナンバー広告まで複数のサブネットを潰しました。 より一般的な方法で、私たちは、現在、スーパーネッティング、集合、または要約としてサブネッティングとして接頭語を右に広げていて、左にそれを潰すことを考えます。 サブネッティングか集合の用法によって、異なった接頭語の長さは異なったルータインタフェースで重要です。
4.3 Renumbering Scope
4.3 範囲に番号を付け替えさせること。
Prefixes may be taken from the private address space [RFC1918] that is not routable on the global Internet. Since these addresses are not routable on the global Internet, changing parts of private address space prefixes is an enterprise-local decision.
世界的なインターネットで発送可能でないプライベート・アドレススペース[RFC1918]から接頭語を取るかもしれません。 これらのアドレスが世界的なインターネットで発送可能でないので、プライベート・アドレス宇宙接頭語の部分を変えるのは、企業ローカルの決定です。
Berkowitz Informational [Page 12] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[12ページ]のRFC2072Router
If a prefix is totally outside the control of the enterprise, it is external, and will be minimally affected by routing. Potential interactions of external prefixes with enterprise renumbering include:
企業のコントロールの完全に外に接頭語があると、それは、外部であり、ルーティングで最少量で影響を受けるでしょう。 企業の番号を付け替えるとの外部の接頭語の潜在的相互作用は:
1) Inadvertent alteration or deletion of external addresses
as part of router reconfiguration.
2) Loss of connectivity to application servers inside the
enterprise, because the external client no longer knows
the internal address of the server.
3) DNS/BGP
4) Security
1) ルータ再構成の一部としての外部アドレスの不注意な変更か削除。 2) 外部クライアントが、もう. 3は内部がサーバを扱うのを知らないので企業の中のアプリケーション・サーバーへの接続性の損失 DNS/BGP4) セキュリティ
Prefixes partially under the control of the enterprise may change. The scope of this will vary depending on whether only the externally controlled part of the prefix changes, or if part of the internally controlled part is to be renumbered. If the length of either the high-order or low-order parts change, the process becomes more complex.
接頭語は企業のコントロールの下で部分的に変化するかもしれません。 接頭語の外部的に制御された部分だけが変化するかどうか、または番号を付け替えられるかどうかに内部的に制御された部分の一部がことであるよって、この範囲は異なるでしょう。 高位か下位の部品変化の長さであるなら、プロセスは、より複雑になります。
High-order-part-only renumbering is most common when an organization changes ISPs, and needs to renumber into the new provider's space. The old prefix may have been assigned to the enterprise but will no longer be used for global routing, or the old prefix may have been assigned to the previous provider. Note that administrative procedures may be necessary to return the previous prefix, although this usually will be done by the previous provider. There often will need to be a period of coexistence between the old and new prefixes.
組織がISP、および必要性を変えると、高オーダー部分だけの番号を付け替えるのは、新しいプロバイダーのスペースに番号を付け替えるために最も一般的です。 グローバルなルーティングにもう使用されないのを除いて、古い接頭語が企業に配属されたかもしれませんか、または古い接頭語は前のプロバイダーに割り当てられたかもしれません。 行政手続が前の接頭語を返すのに必要であるかもしれないことに注意してください、前のプロバイダーで通常これをするでしょうが。 そこでは、しばしば古くて新しい接頭語の間の共存の一区切りであることが必要でしょう。
Low-order-part-only renumbering can occur when an enterprise modifies its internal routing structure, and the changes only affect the internal subnet structure of the enterprise network. This is typical of efforts involved in increasing the number of available subnets (e.g., for more point-to-point media) or increasing the number of hosts on a medium (e.g., in greater use of workgroup switches).
企業が内部のルーティング構造を変更すると、低いオーダー部分だけの番号を付け替えることは起こることができます、そして、変化は企業網の内部サブネット構造に影響するだけです。 これは媒体(例えば、ワークグループスイッチの、より大きい使用での)でホストについて利用可能なサブネット(例えば、より二地点間のメディアのための)か数を増やす数を増強するのにかかわる取り組みの典型です。
Both the high-order and low-order parts may change. This might happen when the enterprise changes to a new ISP, who assigns address space from a CIDR block rather than a classful network previously used. With a different high-order prefix length, the enterprise might be forced to change its subnet structure.
両方の高位と下位の一部が変化するかもしれません。 企業が新しいISP(以前に使用されたclassfulネットワークよりむしろCIDRブロックからアドレス空間を割り当てる)に変化すると、これは起こるかもしれません。 異なった高位接頭語の長さで、企業はやむを得ずサブネット構造を変えるかもしれません。
5. Moving toward a Renumbering-Friendly Enterprise
5. 番号を付け替えるに優しいエンタープライズに近づきます。
Renumbering affects both the configuration of specific router "boxes," and the overall system of routers in a routing domain. The emphasis of this section is on making the current enterprise more renumbering-friendly, before any prefixes are actually changed.
番号を付け替えるのは経路ドメインで特定のルータ「箱」の構成とルータの総合体系の両方に影響します。 このセクションの強調が実際にどんな接頭語も変える前に現在の企業をより番号を付け替えるに優しくするところにあります。
Berkowitz Informational [Page 13] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[13ページ]のRFC2072Router
Renumbering will have the least impact when the minimum number of reconfiguration options are needed. When planning renumbering on routers, consider that many existing configurations may contain hard-coded IP addresses that may not be necessary, even if renumbering were not to occur. Part of a router renumbering effort should include, wherever possible, replacing router mechanisms based on hard-coded addresses with more flexible mechanisms.
番号を付け替えることで、再構成オプションの最小の数が必要であるときに、最少の影響力があるでしょう。 番号を付け替えるのがそうしないつもりであっても、ルータの番号を付け替えることを計画しているときには多くの既存の構成が必要でないかもしれない一生懸命コード化されたIPアドレスを含むかもしれないと考えてください、そして、起こってください。 取り組みに番号を付け替えさせるルータの一部が、どこでも、可能であるところで一生懸命コード化されたアドレスに基づくルータメカニズムをよりフレキシブルなメカニズムに置き換えるのを含むべきです。
Renumbering will also generally be easier if the configuration changes can be made offline on appropriate servers, and then downloaded to the router if the router implementation permits.
また、ルータ実装が可能にするなら、構成変更を適切なサーバでオフラインに作って、次にルータにダウンロードできるなら、一般に、番号を付け替えることは、より簡単になるでしょう。
5.1 Default Routes
5.1 デフォルトルート
A well-known method for reducing the amount of reference by one router to other routers is to use a default route to a higher-level, better-connected router. This assumes a hierarchical network design, which is generally desirable in the interest of scaling.
1つのルータで参照の量を他のルータに減少させるためのよく知られるメソッドは、よりハイレベルの、そして、よりよく接続されたルータにデフォルトルートを使用することです。 これは、階層的なネットワークがデザインであると仮定します。(一般に、スケーリングのために、それは、望ましいです)。
Default routes are most appropriate for stub routers inside a routing domain, and for boundary routers that connect the domain to a single ISP.
経路ドメインの中のスタッブルータ、およびただ一つのISPにドメインをつなげる境界ルータに、デフォルトルートは最も適切です。
5.2 Route Summarization and CIDR
5.2 ルート総括とCIDR
When routes need to be advertised, summarize as much as is practical. Summarization is most effective when address prefixes have been assigned in a consistent and contiguous manner, which is often not the case in legacy networks. Nevertheless, there is less to change when we can refer to blocks of prefixes.
ルートが、広告を出す必要があるときには、実用的であるのと同じくらい多くをまとめてください。 一貫して隣接の方法(しばしばレガシーネットワークのケースであるというわけではない)でアドレス接頭語を割り当ててあるとき、総括は最も効果的です。 それにもかかわらず、私たちがいつブロックの接頭語を示すことができるかを変えるために、以下があります。
Not all routing mechanisms support general summarization. Interior routing mechanisms that do include RIPv2, OSPF, EIGRP, IS-IS, and systems of static routes. RIPv1 and IGRP do support classful summarization (i.e., at Class A/B/C network boundaries only).
すべて掘っていないメカニズムは一般的な総括をサポートします。 RIPv2、OSPF、EIGRPを含んでいる内部のルーティングメカニズム、-、そして、スタティックルートのシステム。 RIPv1とIGRPはclassful総括(すなわち、Class A/B/Cネットワーク限界だけの)をサポートします。
If existing addresses have been assigned hierarchically, it may be possible to renumber below the level of summarization, while hiding the summarization to the rest of the network. In other words, if all the address bits being renumbered are to the right of the summarized prefix length, the change can be transparent to the overall routing system.
ネットワークの残りに総括を隠している間、既存のアドレスを階層的に割り当ててあるなら、総括のレベルの下で番号を付け替えるのにおいて可能であるかもしれません。 言い換えれば、まとめられた接頭語の長さの右に番号を付け替えられるすべてのアドレスビットがあるなら、変化は総合的なルーティングシステムに透明である場合があります。
Even when effective summarization is possible to hide the details of routing, DNS, filters, and other services may be affected by any renumbering.
有効な総括がルーティングの詳細を隠すのにおいて可能であるときにさえ、DNS、フィルタ、および他のサービスはどんな番号を付け替えることで影響を受けるかもしれません。
Berkowitz Informational [Page 14] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[14ページ]のRFC2072Router
5.3 Server References in Routers
5.3 ルータにおけるサーバ参照
Routers commonly communicate with an assortment of network management and other infrastructural servers. Examples of these servers are given in the "Network Management" section below. DNS itself, however, may be an important exception.
ルータはネットワークマネージメントと他のインフラストラクチャのサーバの分類で一般的に交信します。 これらのサーバに関する例は「ネットワークマネージメント」セクションで以下に出されます。 しかしながら、DNS自身は重要な例外であるかもしれません。
Wherever possible, servers should be referenced by DNS name rather than by IP address. If a specific router implementation only supports explicit address references, this should be documented as part of the renumbering plan.
どこでも、可能であるところでは、サーバがIPアドレスでというよりむしろDNS名によって参照をつけられるべきです。 特定のルータ実装が、明白なアドレスが参照であるとサポートするだけであるなら、これは番号を付け替えるプランの一部として記録されるべきです。
Routers may also need to forward end host broadcasts to other infrastructure services (e.g., DNS, DHCP/BOOTP). Configurations that do this are likely to contain hard-coded IP addresses of the destination hosts or their subnets, which will need to be changed as part of renumbering.
また、ルータは、他のインフラストラクチャサービス(例えば、DNS、DHCP/BOOTP)に終わりのホスト放送を送る必要があるかもしれません。 これをする構成はあて先ホストの一生懸命コード化されたIPアドレスか彼らのサブネットを含みそうです。(サブネットは番号を付け替えることの一部として変えられる必要があるでしょう)。
5.4 DNS and Router Renumbering
5.4 DNSとルータの番号を付け替えること
The Domain Name Service is a powerful tool in any renumbering effort, and can help routers as well as end hosts. If traceroute displays DNS names rather than IP addresses, certain debugging options can be transparent through the address transition.
Domain Name Serviceはどんな番号を付け替える取り組みでも強力な道具であり、終わりのホストと同様にルータを助けることができます。 トレースルートがIPアドレスよりむしろDNS名を表示するなら、あるデバッグオプションはアドレス変遷でわかりやすい場合があります。
Be aware that dynamically learned names and addresses may be cached in router tables. For a router to learn changes in address to name correspondence, it may be necessary to restart the router or explicitly clear the cache.
ダイナミックに学習された名前とアドレスがルータテーブルでキャッシュされるかもしれないのを意識してください。 ルータが通信を命名するためにアドレスにおける変化を学ぶように、ルータを再開するか、または明らかにキャッシュをクリアするのが必要であるかもしれません。
Alternatively, router configuration files may contain hard-coded address/name correspondences that will not be affected by a change in the DNS server.
あるいはまた、ルータ構成ファイルはDNSサーバにおける変化で影響を受けない一生懸命コード化されたアドレス/名前通信を含むかもしれません。
Different DNS databases are affected by renumbering. For example, the enterprise usually controls its own "forward" data base, but the reverse mapping data base may be maintained by its ISP. This can require coordination when changing providers.
異なったDNSデータベースは、番号を付け替えることによって、影響を受けます。 例えば、企業は通常それ自身の「前進」のデータベースを制御しますが、データベースを写像する逆はISPによって維持されるかもしれません。 プロバイダーを変えるとき、これはコーディネートを必要とすることができます。
Commonly, router renumbering goes through a transition period. During this transition, old and new addresses may coexist in the routing system. Coexistence over a significant period of time is especially likely for DNS references to addresses that are known in the global Internet [deGroot]. Various DNS servers throughout the world may cache addresses for periods of days.
一般的に、ルータの番号を付け替えるのは過渡期に直面しています。 この変遷の間、古くて新しいアドレスはルーティングシステムに共存するかもしれません。 世界的なインターネット[deGroot]で知られているアドレスのDNS参照に、重要な期間の間の共存は特にありそうです。 世界中の様々なDNSサーバは何日もの期間、アドレスをキャッシュするかもしれません。
Berkowitz Informational [Page 15] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[15ページ]のRFC2072Router
If, for example, a given router interface may have a coexisting new and old address, it can be appropriate to introduce the new address as an additional A record for the new address.
例えば、与えられたルータインタフェースに共存の新しくて古いアドレスがあるかもしれないなら、新しいアドレスのための追加A記録として新しいアドレスを紹介するのは適切である場合があります。
DNS RR statements can end with a semicolon, indicating the rest of the line is a comment. This can be used as the basis of tools to renumber DNS names for router addresses, by putting a comment (e.g., ";newaddr") at the end of the A statements for the new addresses. At an appropriate time, a script could generate a new zone file in which the new addresses become the primary definitions on A records, and the old addresses could become appropriately commented A records. At a later time, these commented entries could be removed.
DNS RR声明はセミコロンで終わって、系列の残りがコメントであることを示すことができます。 「ルータアドレスにツールがDNS名に番号を付け替えさせる基礎としてこれを使用できます、コメントを置くことによって(例えば」、newaddr、」、)、新しいアドレスのためのA声明の終わりで。 適当な機会に、スクリプトは新しいアドレスがA記録でプライマリ定義になる新しいゾーンファイルを生成するかもしれません、そして、旧住所は適切に論評されたA記録になることができました。 後で、これらの論評されたエントリーを取り除くことができました。
Care should be taken to assure that PTR reverse mapping entries are defined for new addresses, because some router vendor tools depend on reverse mapping.
PTRの逆のマッピングエントリーが新しいアドレスのために定義されることを保証するために注意するべきです、いくつかのルータベンダーツールが逆のマッピングによるので。
5.5 Dynamic Addressing
5.5 ダイナミックなアドレシング
Renumbering is easiest when addresses need to be changed in the least possible number of places. Dynamic address assignment is especially attractive for end hosts, and routers may play a key role in this process. Routers may act as servers and actually assign addresses, or may be responsible for forwarding end host address assignment requests to address assignment servers.
アドレスが、場所の最も可能でない数で変えられる必要があるとき、番号を付け替えるのは最も簡単です。 終わりのホストにとって、ダイナミックなアドレス課題は特に魅力的です、そして、ルータはこのプロセスで重要な役割を果たすかもしれません。 ルータは、サーバとして機能して、実際にアドレスを割り当てるかもしれないか、または課題サーバを扱うという推進終わりのホスト・アドレス課題要求に原因となるかもしれません。
The most common use of dynamic address assignment is to provide IP addresses to end systems. Dynamic address assignment, however, is also used to assign IP addresses to router interfaces. An address assignment server may assign an IP address to a router either in the usual DHCP way, based on a MAC address in the router, or simply based on the physical connectivity of the new router. In other words, any router connected on a specific interface of the configuring router would be assigned the same IP address.
ダイナミックなアドレス課題の最も一般の使用はシステムを終わらせるためにIPアドレスを提供することです。しかしながら、また、ダイナミックなアドレス課題は、IPアドレスをルータインタフェースに割り当てるのに使用されます。 アドレス課題サーバはルータにおけるMACアドレスに基づく普通のDHCP道か単に新しいルータの物理的な接続性に基づいてIPアドレスをルータに割り当てるかもしれません。 言い換えれば、同じIPアドレスは構成ルータの特定のインタフェースで接続されたどんなルータにも割り当てられるでしょう。
5.5.1 Router Roles in LAN-based DHCP Address Assignment
5.5.1 LANベースのDHCPアドレス課題におけるルータの役割
End hosts attached to LANs often obtain address assignments from BOOTP or DHCP servers. If the server is not on the same medium as the end hosts, routers may need to play a role in establishing connectivity between the end host and the address server.
LANに付けられた終わりのホストはBOOTPかDHCPサーバからアドレス課題をしばしば得ます。 終わりのホストと同じ媒体の上にサーバがないなら、ルータは、終わりのホストとアドレスサーバの間の接続性を確立することにおける役割を果たす必要があるかもしれません。
If the client is not on the same medium as the address assignment server, routers either must act as address assignment services, or forward limited broadcasts to the location of appropriate servers.
クライアントがアドレス課題サーバと同じ媒体の上にいないなら、ルータはアドレス課題サービス、または前進の限られた放送として適切なサーバの位置に機能しなければなりません。
Berkowitz Informational [Page 16] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[16ページ]のRFC2072Router
If the router acts as an address assignment server, its database of addresses that it can assign may change during renumbering. If the router forwards to a DHCP or BOOTP server, it must know the address of that server. That server address can itself change as a result of renumbering.
ルータがアドレス課題サーバとして機能するなら、それが割り当てることができるアドレスに関するデータベースは番号を付け替えている間、変化するかもしれません。 DHCPかBOOTPサーバへのルータフォワードであるなら、それはそのサーバのアドレスを知らなければなりません。そのサーバアドレス缶自体は番号を付け替えることの結果、変化します。
While the usual perception of DHCP is that it assigns addresses from a pool, such that assignments to a given host at a given time is random within the pool, DHCP can also return a constant IP address for a specific MAC address. This may be much easier to manage and troubleshoot, especially during renumbering.
DHCPの普通の認知は与えられたホストへの課題が一時にプールの中で無作為であるようにプールからのアドレスを割り当てるということですが、また、DHCPは特定のMACアドレスのための一定のIPアドレスを返すことができます。 特に番号を付け替えている間、管理しやすくて、これははるかに障害調査しやすいかもしれません。
Clearly, if the DHCP server identifies end hosts based on their MAC address, consideration must be given to making that address unique, and changing the DHCP database if either the MAC address or the IP address changes. One way to reduce such reconfiguration is to use Locally-Administered Addresses (LAA) on end hosts, rather than globally unique addresses stored in read-only memory (ROM). Using LAAs solves the problem of MAC addresses changing when a network interface card changes, but LAAs have their own management problems of configuration into end systems and maintaining uniqueness within the enterprise.
明確に、DHCPサーバが彼らのMACアドレスに基づく終わりのホストを特定するなら、そのアドレスをユニークにして、MACアドレスかIPアドレスのどちらかが変化するならDHCPデータベースを変えることに対して考慮を払わなければなりません。 そのような再構成を減少させる1つの方法はリードオンリーメモリ(ROM)に保存されたグローバルにユニークなアドレスよりむしろ終わりのホストの上でLocallyによって管理されたAddresses(LAA)を使用することです。 LAAsを使用すると、ネットワーク・インターフェース・カードがいつ変化するかを変えるMACアドレスの問題は解決されますが、LAAsには、エンドシステムへの構成と企業の中でユニークさを維持するというそれら自身の管理問題があります。
5.5.2 Router Roles in Dialup Address Assignment
5.5.2 ダイアルアップアドレス課題におけるルータの役割
There are several possible ways in which an dialup end host interacts with address assignment. Routers/access servers can play critical roles in this process, either to provide connectivity between client and server, or directly to assign addresses.
ダイアルアップ終わりのホストがアドレス課題と対話するいくつかの可能な方法があります。 ルータ/アクセス・サーバーは、アドレスを割り当てるためにクライアントとサーバの間か直接このプロセスにおける重要な役割、接続性を提供するどちらかをプレーできます。
Different vendors handle address assignment in different ways. Methods include:
異なったベンダーは異なった方法でアドレス課題を扱います。 メソッドは:
1. The access server forwards the request to a DHCP server, using
a unique 48-bit identifier associated with the client. Note
that this usually should not be the MAC address of the access
server, since the same MAC address would then be associated
with different hosts.
1. クライアントに関連しているユニークな48ビットの識別子を使用して、アクセス・サーバーはDHCPサーバに要求を転送します。 通常、これがアクセス・サーバーのMACアドレスであるべきでないことに注意してください、同じMACアドレスはその時異なったホストに関連しているでしょう、したがって。
2. The server forwards the request to an authentication server,
which in turn gets a dynamic address either from:
2. サーバは認証サーバに要求を転送します。(それは、以下からダイナミックなアドレスを順番に得ます)。
a. internal pools
b. a DHCP server to which it forwards
インターナルがb. DHCPサーバをプールするそれが進めるa.
3. The server selects an address from locally configured pools
and provides it to the dialing host without the intervention
of other services.
3. サーバは、局所的に構成されたプールからアドレスを選択して、他のサービスの介入なしでダイヤルしているホストにそれを提供します。
Berkowitz Informational [Page 17] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[17ページ]のRFC2072Router
When the router contains assignable addresses, these may need to change as part of renumbering. Alternatively, hard-coded references to address assignment or authentication servers may need to change.
ルータが「割り当て-可能」アドレスを含んでいると、これらは、番号を付け替えることの一部として変化する必要があるかもしれません。 あるいはまた、課題か認証がサーバであると扱う一生懸命コード化された参照は、変化する必要があるかもしれません。
5.5.3 Router Autoonfiguration
5.5.3 ルータAutoonfiguration
This initial address assignment may provide an address only for a single connection (i.e., between the new and configuring routers). The newly assigned address may then be used to "bootstrap" a full configuration into the new router.
この初期のアドレス課題は単独結合(すなわち、新しい、そして、構成ルータの間の)のためだけのアドレスを提供するかもしれません。 そして、新たに割り当てられたアドレスは、新しいルータに完全な構成を「独力で進むこと」に使用されるかもしれません。
Dynamic address assignment to routers is probably most common at outlying "stub" or "edge" routers that connect via WAN links to a central location with a configuration server. Such edge devices may be shipped to a remote site, plugged in to a WAN line, and use proprietary methods to acquire part or all of their address configuration.
中心の位置へのWANリンクを通して構成サーバに接続する辺ぴな「スタッブ」か「縁」ルータでルータへのダイナミックなアドレス課題はたぶん最も一般的です。そのようなエッジデバイスは、WAN系列にプラグを差し込まれたリモートサイトに出荷されて、それらのアドレス構成の部分かすべてを取得する独占メソッドを使用するかもしれません。
When such autoconfiguration is used on edge routers, it may be necessary to force a restart of the edge router after renumbering. Restarting may be the only way to force the autoconfigured router to learn its new address. Other out-of-band methods may be available to change the edge router addresses.
そのような自動構成が縁のルータで使用されるとき、番号を付け替える後に縁のルータの再開を強制するのが必要であるかもしれません。 再開は自動構成されたルータに新しいアドレスを学ばせる唯一の方法であるかもしれません。 他のバンドで出ているメソッドは、縁のルータアドレスを変えるために利用可能であるかもしれません。
5.6 Network Address Translation
5.6 ネットワークアドレス変換
Network address translation (NAT) is a valuable technique for renumbering, or even for avoiding the need to renumber significant parts of an enterprise [RFC1631]. It is not always transparent to network layer protocols, upper layer protocols, and network management tools, and must not be regarded as a panacea.
ネットワーク・アドレス翻訳(NAT)は、番号を付け替える、または企業[RFC1631]の重要な部分に番号を付け替えさせる必要性を避けさえするための有益なテクニックです。 それは、いつもネットワーク層プロトコル、上側の層のプロトコル、およびネットワークマネージメントツールに透明であるというわけではなく、万能薬と見なされてはいけません。
In the classic definition of NAT, certain parts of the routing system are designated as stub domains, and connect to the global domain only through NAT functions. The NAT contains a translation mechanism that maps a stub address to a global address. This mechanism may map statically or dynamically.
NATの古典的な定義では、ルーティングシステムのある部分は、スタッブドメインとして指定されて、NAT機能だけを通してグローバルなドメインに接続します。 NATはスタッブアドレスをグローバルアドレスに写像する変換メカニズムを含んでいます。 このメカニズムは静的かダイナミックに写像されるかもしれません。
A more general NAT mechanism often is implemented in firewall bastion hosts, which isolate "inside" and "outside" addresses through transport- or application-level authenticated gateways. Mappings from a "local" or "inside" address to a global address often is not one-to-one, because an inside address is dynamically mapped to a TCP or UDP port on an outside interface address.
より一般的なNATメカニズムがファイアウォール要塞ホストでしばしば実装されたか、またはアプリケーションレベルはゲートウェイを認証しました。(要塞ホストは輸送で“inside"と「外」のアドレスを隔離します)。 「地方」か“inside"アドレスからグローバルアドレスまでのマッピングは、しばしば1〜1であるというわけではありません、インサイドアドレスがダイナミックに外のインターフェース・アドレスのTCPかUDPポートに写像されるので。
In general, if there are multiple NATs, their translation mechanisms should be synchronized. There are specialized cases when a given stub address appears in more than one stub domain, and ambiguity
一般に、複数のNATsがあれば、彼らの変換メカニズムは同期するべきです。 与えられたスタッブアドレスが1つ以上のスタッブドメイン、およびあいまいさに現れるとき、専門化しているケースがあります。
Berkowitz Informational [Page 18] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[18ページ]のRFC2072Router
develops if one wishes to map, say, from 10.1.0.1/16 in stub domain A to 10.1.0.1/16 in stub domain B. In this case, both 10.1.0.1 addresses identify different hosts. Special mechanisms would have to exist to map the domain A local address into one global address, and to map the domain B local address into a different global address.
開発、人がたとえば10.1から.0を写像したいなら、.1/16は中で10.1.0.1/16のコネスタッブドメインB.In本件にドメインAを引き抜いて、両方の10.1の.0.1アドレスが異なったホストを特定します。 特別なメカニズムは、ドメインAローカルアドレスを1つのグローバルアドレスに写像して、ドメインBローカルアドレスを異なったグローバルアドレスに写像するために存在しなければならないでしょう。
NAT can have a valuable role in renumbering. Its intelligent use can greatly minimize the amount of renumbering that needs to be done. NAT, however, is not completely transparent.
NATは番号を付け替えることにおける貴重な役割を持つことができます。 知的な使用はする必要がある番号を付け替えることの量を大いに最小にすることができます。 しかしながら、NATは完全に透明であるというわけではありません。
Specifically, it can interfere with the proper operation of any protocol that carries an IP address as data, since NAT does not understand passenger fields and is unaware numbers need to change.
明確に、データとしてIPアドレスを運ぶどんなプロトコルの適切な操作も妨げることができます、NATが乗客分野を理解しないで、変化する気づかない数の必要性であるので。
Examples of protocols affected are:
影響を受けるプロトコルに関する例は以下の通りです。
--TCP and UDP checksums that are in part based on the
IP header. This includes end-to-end encryption schemes
that include the TCP/UDP checksum
--ICMP messages containing IP addresses
--DNS queries that return addresses or send addresses
--FTP interactions that use an ASCII-encoded IP address
as part of the PORT command
--一部TCPとUDPチェックサムはIPヘッダーを基礎づけました。 これはIPを含むのが、--DNS質問がその返送先であると扱うというTCP/UDPチェックサム--ICMPメッセージを含んでいるか、またはPORTコマンドの一部としてASCIIによってコード化されたIPアドレスを使用する相互作用をアドレス--FTPに送る終端間暗号化体系を含んでいます。
It may be possible to avoid conflict if only certain hosts use affected protocols. Such hosts could be assigned only global addresses, if the network topology and routing plan permit.
確信しているホストだけが影響を受けるプロトコルを使用するなら、闘争を避けるのは可能であるかもしれません。 ネットワーク形態とルーティングプランが可能にするなら、グローバルなアドレスだけがそのようなホストに割り当てられるかもしれません。
Early NAT experiments suggested that it needs a sparse end-to-end traffic mapping database for reasonable performance. This may or may not be an issue in more hardware-based NAT implementations.
早めのNAT実験は、妥当な性能のための終わりから終わりへのトラフィックマッピングまばらなデータベースを必要とするのを示しました。 これは、よりハードウェアベースのNAT実装で問題であるかもしれません。
Another concern with NAT is that unique host addresses are hidden outside the local stub domains. This may in fact be desirable for security, but may present network management problems. One possibility would be to develop a NAT MIB that could be queried by SNMP to find the specific local-to-global mappings in effect.
NATがある別の関心はユニークなホスト・アドレスが地方のスタッブドメインの外に隠されるということです。 これは、セキュリティのために事実上望ましいかもしれませんが、ネットワーク管理問題を提示するかもしれません。1つの可能性はSNMPが特定のグローバルへのローカルのマッピングが有効であることがわかるために質問できたNAT MIBを開発するだろうことです。
There are also issues for DNS, DHCP, and other address management services. There presumably would need to be local servers within stub domains, so address requests would be resolved uniquely in each stub (or would return appropriate global addresses).
DNS、DHCP、および他のアドレス経営指導のための問題もあります。 そこでは、おそらく、スタッブドメインの中のローカルサーバであることが必要でしょう、したがって、アドレス要求が各スタッブ(または、適切なグローバルなアドレスを返す)で唯一決議されるでしょう。
Berkowitz Informational [Page 19] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[19ページ]のRFC2072Router
6. Potential Pitfalls in Router Renumbering
6. ルータの番号を付け替えることにおける潜在的落とし穴
One way to categorize potential pitfalls is to look at those associated with the overall numbering plan itself and routing advertisement, and those associated with protocol behavior. In general, the former case is static and the latter is dynamic.
潜在的落とし穴を分類する1つの方法は、総合的な付番プラン自体に関連しているとしてそれらを見て、プロトコルの振舞いに関連しているとしてルーティング広告、およびそれらを見ることです。 一般に、前のケースは静的です、そして、後者はダイナミックです。
6.1 Static
6.1 静電気
Problems can be implicit to the address/routing structure itself. These can include failures of components to understand arbitrary prefix addressing (i.e., classless routing), reachability due to inappropriate default or aggregated routes, etc.
問題はアドレス/ルーティング構造自体に暗黙である場合があります。 これらは任意の接頭語アドレシング(すなわち、階級のないルーティング)を理解しないコンポーネントのこと、不適当なデフォルトか集められたルートによる可到達性などを含むことができます。
6.1.1 Classless Routing Considerations
6.1.1 階級のないルート設定問題
Among the major reasons to renumber is to gain globally routable address space. In the global Internet, routable address space is based on arbitrary-length prefixes rather than traditional address classes. Classless Inter-Domain Routing (CIDR) is the administrative realization of prefix addressing in the global Internet. Inside enterprises, arbitrary prefix length addressing often is called Variable Length Subnet Masking (VLSM) or "subnetting a subnet."
番号を付け替えさせる主要な理由の中に、利得には発送可能アドレス空間がグローバルにあります。 世界的なインターネットでは、発送可能アドレス空間が伝統的なアドレスのクラスよりむしろ任意の長さの接頭語に基づいています。 階級のないInter-ドメインルート設定(CIDR)は世界的なインターネットでの接頭語アドレシングの管理実現です。 企業の中では、任意の接頭語長さのアドレシングはしばしばVariable Length Subnet Masking(VLSM)か「サブネッティングaサブネット」と呼ばれます。
The general rules of prefix addressing must be followed in CIDR. Among these are permitting use of the all-zeroes and all-one subnets [RFC1812], and not assuming that a route to a "Class A/B/C network number" implies routes to all subnets of that network. Assumptions also should not be made that a prefix length is implied by the structure of the high-order bits of the IP address (i.e., the "First Octet Rule").
接頭語アドレシングの総則は、CIDRこれらがオールゼロとオール1つのサブネット[RFC1812]の使用を可能にしているAmongで続かれていて、「クラスA/B/Cネットワーク・ナンバー」へのルートがそのネットワークのすべてのサブネットにルートを含意すると仮定してはいけません。 また、接頭語の長さがIPアドレス(すなわち、「最初のオクテット則」)の高位のビットの構造によって含意されるという仮定をするべきではありません。
This ideal, unfortunately, is not understood by a significant number of routers (and terminal access servers that participate in routing), and an even more significant number of host IP implementations.
残念ながら、この理想は多くのルータ(そして、ルーティングに参加する端末のアクセス・サーバー)、およびさらに重要な数のホストIP実装に解釈されません。
When planning renumbering, network designers must know if the new address has been allocated using CIDR rules rather than traditional classful addressing. If CIDR rules have been followed in address assignment, then steps need to be taken to assure the router understands them, or appropriate steps need to be taken to interface the existing environment to the CIDR environment.
番号を付け替えることを計画しているとき、ネットワーク設計者は、新しいアドレスが伝統的なclassfulアドレシングよりむしろCIDR規則を使用することで割り当てられたかどうかを知らなければなりません。 CIDRがアドレス課題で続かれたように裁決して、次に、踏むなら、ルータを保証するために取られるべき必要性がそれらを理解しているか、または適切なステップは、CIDR環境への既存の環境を連結するように取られる必要があります。
Current experience suggests that it is best, when renumbering, to maintain future compatibility by moving to a CIDR-supportive routing environment. While this is usually thought to mean introducing a classless dynamic routing protocol, this need not mean that routing become much more complex. In a RIPv1 environment, moving to RIPv2
CIDR支持しているルーティング環境に移行することによって将来の互換性を維持するために番号を付け替えるとき、現在の経験は、それが最も良いと示唆します。 通常、これが、階級のないダイナミックルーティングプロトコルを紹介することを意味すると考えられている間、これは、ルーティングがはるかに複雑になることを意味する必要はありません。 RIPv2に移行するRIPv1環境で
Berkowitz Informational [Page 20] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[20ページ]のRFC2072Router
may be a relatively simple change. Alternative simple methods include establishing a default route from a non-CIDR-compliant routing domain to a CIDR-compliant service provider, or making use of static routes that are CIDR-compliant.
比較的簡単な変化であるかもしれません。 代替の簡単なメソッドが、aからデフォルトルートを確立するのを含んでいる、非CIDR対応する、CIDR対応することのサービスプロバイダーにドメインを発送するか、またはCIDR対応であるスタティックルートを利用します。
Some routers support classless routing without further configuration, other routers support classless routing but require specific configuration steps to enable it, while other routers only understand classful routing. In general, most renumbering will eventually require classless routing support. It is essential to know if a given router can support classless routing. If it does not, workarounds may be possible. Workarounds are likely to be necessary.
いくつかのルータがさらなる構成なしで階級のないルーティングをサポートして、他のルータは、それを可能にするために階級のないルーティングをサポートしますが、特定の構成ステップを必要とします、他のルータはclassfulルーティングを理解しているだけですが。 一般に、ほとんどの番号を付け替えるのが結局、階級のないルーティングサポートを必要とするでしょう。 与えられたルータが階級のないルーティングをサポートすることができるかどうかを知るのは不可欠です。 そうしないなら、回避策は可能であるかもしれません。 回避策は必要である傾向があります。
6.1.1.1 Aggregation Problems
6.1.1.1 集計の問題
In experimenting with the CIDR use of a former Class A network number, it was shown in RFC1879 that CIDR compliance rules must be enabled explicitly in some routers, while other routers do not understand CIDR rules.
前のClass Aネットワーク・ナンバーのCIDR使用を実験する際に、RFC1879にいくつかのルータで明らかにCIDR承諾規則を可能にしなければならないのが示されました、他のルータはCIDR規則を理解していませんが。
RFC 1897 demonstrated problems with some existing equipment, especially "equipment that depends on use of a classful routing protocol, such as RIPv1 are prone to misconfiguration. Tested examples are current Ascend and Livingston gear, which continue to use RIPv1 as the default/only routing protocol. RIPv1 use will create an aggregate announcement.... The Ascend was told to announce 39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent 39/8." RIPv1, like all classful interior protocols, is obsolescent.
RFC1897は何らかの既存の設備、特に「RIPv1などのclassfulルーティング・プロトコルの使用による設備はmisconfigurationの傾向があること」で問題を示しました。 テストされた例は、現在のAscendとリビングストンギヤです。(そのギヤはデフォルト/唯一のルーティング・プロトコルとしてRIPv1を使用し続けています)。 RIPv1使用は集合発表を作成するでしょう… 「AscendはRIPv1がこれができないので39.1に.28/24を発表するために、Ascendが代わりに39/8を送ったと言われました。」 すべてが内部のプロトコルをclassfulするようにRIPv1は退行性です。
6.1.1.2 Discontiguous Networks
6.1.1.2 Discontiguousネットワーク
Another problem that can occur with routers or routing mechanisms that do not understand arbitrary length prefix addressing is that of discontiguous networks. This problem is easy to create inadvertently when renumbering. In the example below, assume the enterprise has been using 10.0.0.0/8 as its primary prefix, but has introduced an ISP whose registered addresses were in 172.31.0.0/16.
任意の長さの接頭語アドレシングを理解していないルータかルーティングメカニズムで起こることができる別の問題はdiscontiguousネットワークのものです。 番号を付け替えるとき、この問題はうっかり作成しやすいです。 以下の例では、企業が10.0に.0.0/を使用していると仮定してください、プライマリ接頭語としての8、172.31には登録されたアドレスがあったISPを導入した、.0 .0/16。
Berkowitz Informational [Page 21] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[21ページ]のRFC2072Router
Assume a RIPv1 system of three routers:
3つのルータのRIPv1システムを仮定してください:
10.1.0.1/16 10.2.0.1/16
| |
| |
+-------------------------------------+
| Router 1 |
+-------------------------------------+
| 172.31.1.1/24
|
|
| 172.31.1.2/24
+-------------------------------------+
| Router 2 |<------OUTSIDE
+-------------------------------------+
| 172.31.2.1/24
|
|
| 172.31.2.2/24
+-------------------------------------+
| Router 3 |
+-------------------------------------+
| |
| |
10.3.0.1/16 10.4.0.1/16
10.1.0.1/16 10.2.0.1/16 | | | | +-------------------------------------+ | ルータ1| +-------------------------------------+ | 172.31.1.1/24 | | | 172.31.1.2/24 +-------------------------------------+ | ルータ2| <、-、-、-、-、--+の外で-------------------------------------+ | 172.31.2.1/24 | | | 172.31.2.2/24 +-------------------------------------+ | ルータ3| +-------------------------------------+ | | | | 10.3.0.1/16 10.4.0.1/16
Router 1 can reach its two locally connected subnets, 10.1.0.0/16 and 10.2.0.0/16. It will aggregate them into a single announcement of 10.0.0.0/8 when it advertises out the 172.31.1.1 interface.
ルータ1は.0/16に2つの局所的に接続されたサブネット、10.1.0 16と.0/10.2.0に達することができます。 それは10.0のただ一つの発表へのそれらに集められるでしょう。.0 それであるときに、.0/8は172.31から.1.1インタフェースの広告を出します。
In like manner, Router 3 can reach its two locally connected subnets, 0.3.0.0/16 and 10.4.0.0/16. It will aggregate them into a single announcement of 10.0.0.0/8 when it advertises out the 172.31.2.2 interface.
同様に、Router3は.0/16に2つの局所的に接続されたサブネット、0.3.0 16と.0/10.4.0に達することができます。 それは10.0のただ一つの発表へのそれらに集められるでしょう。.0 それであるときに、.0/8は172.31から.2.2インタフェースの広告を出します。
When Router 2 receives a packet from its "outside" interface destined, say, to 10.1.1.56/16, where does it send it? Router 2 has received two advertisements of 10.0.0.0 on different interfaces, without any detail of subnets inside 10.0.0.0. Router 2 has an ambiguous routing table in terms of the next hop to a subnet of 10.0.0.0. We call this problem, when parts of the same classful network are separated by different networks, discontigous subnets.
Router2がパケットを受けるとき、「外」のインタフェースから、.1.56/がたとえば10.1に運命づけられていた、16 それはそれをどこに送りますか? ルータ2は10.0の2つの広告を受け取りました。.0 .0 異なるところでは、.0はサブネット内面の10.0.0の少しも詳細なしで連結します。 ルータ2で、次に関するあいまいな経路指定テーブルは.0に10.0のサブネットに.0を飛び越します。 同じclassfulネットワークの部分が異なったネットワーク、discontigousサブネットによって切り離されるとき、私たちはこの問題を呼びます。
Two problems occur in this configuration. Router 2 does not know where to send outside packets destined for a subnet of 10.0.0.0. Connectivity, however, also will break between Routers 1 and 3, because Router 2 does not know the next hop for any subnet of 10.0.0.0.
2つの問題がこの構成で起こります。 ルータ2は、発信するために、パケットの外では、.0が10.0のサブネットのためにどこで運命づけられていたかを.0に知りません。 しかしながら、また、接続性がRouters1と3で知れ渡るでしょう、Router2が10.0のどんなサブネットでも次のホップを知らないので。.0 .0。
Berkowitz Informational [Page 22] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[22ページ]のRFC2072Router
There are several workarounds to this problem. Obviously, one would be to change to a routing mechanism that does advertise subnets. An alternative would be to establish an IP-over-IP tunnel through Router 2, and give this a subnet in 10.0.0.0. This additional subnet would be visible only in Routers 1 and 3. It would solve the connectivity problem between Routers 1 and 3, but Router 2 would still not be able to forward outside packets. This might be a perfectly acceptable solution if Router 2 is simply being used to connect two parts of 10.0.0.0.
この問題へのいくつかの回避策があります。 明らかに、1つはサブネットの広告を出すルーティングメカニズムに変化することになっているでしょう。 代替手段がRouter2を通してIP過剰IPトンネルを確立して、このaサブネットを中に与えるだろうことである、10.0、.0、.0 この追加サブネットはRouters1と3だけで目に見えるでしょう。 それはRouters1と3の間の接続性問題を解決するでしょうが、Router2はまだ外のパケットを進めることができないでしょう。 Router2が10.0の2つの部品を接続するのに単に使用されているなら、これは完全に許容できるソリューションであるかもしれません。.0 .0。
Another way to deal with the discontiguous network problem is to assign secondary addresses in 10.0.0.0 to the R1-R2 and R2-R3 interfaces, which would allow the 10.0.0.0 subnets to be advertised to R2. This would work as long as there is no problem in advertising the 10.0.0.0 subnets into the R2 routing system. There would be a problem, for example, if the 10.0.0.0 address were in the private address space but the R2 primary addresses were registered, and R2 advertised the 10.0.0.0 addresses to the outside.
ネットワーク問題がセカンダリアドレスを割り当てることになっているdiscontiguousに対処する別の方法、10.0、.0、.0、R1-R2とR2-R3インタフェースに。(インタフェースは.0.0サブネットがR2に広告を出すのを10.0に許容するでしょう)。 10.0の.0.0サブネットのR2ルーティングシステムに広告を出すのにおいて問題が全くない限り、これは働いているでしょう。 10.0に、.0が扱う.0がプライベート・アドレススペースにありますが、R2のプライマリアドレスが登録されて、R2が10.0の.0.0アドレスの外部に広告を出すなら、例えば問題があるでしょうに。
This problem can be handled if R2 has filtering mechanisms that can selectively block 10.0.0.0 advertisements to the outside world. The configuration, however, will become more and more complicated.
R2が選択的に10.0の.0.0広告を妨げることができるフィルタリングメカニズムを外の世界に持っているなら、この問題を扱うことができます。 しかしながら、構成はますます複雑になるでしょう。
6.1.1.3 Router-Host Interactions
6.1.1.3 ルータホスト相互作用
The situation may not be as bleak if hosts do not understand prefix addressing but routers do. Methods exist for hiding a VLSM structure from end hosts that do not understand it. These do involve protocol mechanisms as workarounds, but the fundamental problem is hosts' understanding of arbitrary prefix lengths.
ホストが、接頭語アドレシングにもかかわらず、ルータがするのを理解していないなら、状況は同じくらい荒涼でないかもしれません。 メソッドは、それを理解していない終わりのホストからVLSM構造を隠すために存在しています。 これらは回避策としてプロトコルメカニズムにかかわりますが、基本的な問題はホストの任意の接頭語の長さの理解です。
A key mechanism is proxy ARP [Carpenter]. The basic mechanism of using proxy ARP in prefix-based renumbering is to have the hosts issue an ARP whenever they want to communicate with a destination. If the destination is actually on the same subnet, it will respond directly to the ARP. If the destination is not, the router will respond as if it were the destination, and the originating host will send the datagram to the router. Once the datagram is in the router, the VLSM-aware router can forward it.
主要なメカニズムはプロキシARP[大工]です。 接頭語ベースの番号を付け替えるのにプロキシARPを使用する基本的機構は彼らが目的地で交信したがっているときはいつも、ホストにARPを発行させることです。 目的地が実際に同じサブネットにあると、それは直接ARPに応じるでしょう。 目的地がそうでないなら、ルータはまるでそれが目的地であるかのように応じるでしょう、そして、送信元ホストはデータグラムをルータに送るでしょう。 ルータにデータグラムがいったんあると、VLSM意識しているルータはそれを進めることができます。
Many end hosts, however, will only issue an ARP if they conclude the destination is on their own subnet. All other traffic is sent to a hard-coded default router address. In such cases, workarounds may be needed to force the host to ARP for all destinations.
しかしながら、彼らが、目的地がそれら自身のサブネットにあると結論づける場合にだけ、多くの終わりのホストがARPを発行するでしょう。 一生懸命コード化されたデフォルトルータアドレスに他のすべてのトラフィックを送ります。 そのような場合、回避策が、すべての目的地のためにARPにホストを強制するのに必要であるかもしれません。
One workaround involves a deliberate misconfiguration of hosts. Hosts that only understand default routers also are apt only to understand classful addressing. If the host is told its major (i.e.,
1つの回避策がホストの慎重なmisconfigurationにかかわります。 デフォルトルータを理解しているだけであるホストも単にclassfulアドレシングを理解している傾向があります。 すなわち少佐がホストに言われる、(。
Berkowitz Informational [Page 23] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[23ページ]のRFC2072Router
classful) network is not subnetted, even though the address plan actually is subnetted, this will often persuade it to ARP to all destinations.
classful) ネットワークは「副-網で覆」われません、アドレスプランが実際に「副-網で覆」われます、とこれがすべての目的地へのARPをそれをしばしば説得するでしょう。
This also works for hosts that do not understand subnetting at all. An example will serve for both levels of host understanding. Assume the enterprise uses 172.31.0.0/16 as its major address, which is in the Class B format. This is actually subnetted with eight bits of subnetting -- 172.31.0.0/24. Individual hosts unaware of VLSM, however, either infer Class B from the address value, or are told that the subnet mask in effect is 255.255.0.0.
また、これは全くサブネッティングを理解していないホストのために働いています。 例は両方のレベルのホスト理解を満たすでしょう。 主要なアドレスとして企業用途172.31.0.0/16を仮定してください。(Class B形式にはそれは、あります)。 8ビットのサブネッティングで172.31に「副-網で覆」われて、これは実際にそうです。.0 .0/24。 しかしながら、VLSMに気づかない個々のホストは、アドレス値からClass Bを推論するか、または事実上、サブネットマスクがあると言われます。255.255 .0 .0。
Yet another approach that helps hosts find routers is to run passive RIP on the hosts, so that they hear routing updates. They assume any host that issues routing updates must be a router, so traffic for non- local destinations can be forwarded there. While RIPv1 does not support arbitrary prefixes, the router(s) issuing the routing updates may have additional capabilities that let them correctly forward such traffic. The priority, therefore, is to get the non-local routers to a router that understands the overall routing structure, and passive RIP may be a viable way to do this.
ホストがルータを見つけるのを助けるさらに別のアプローチは受け身のRIPをホストに実行することです、彼らがルーティングアップデートを聞くように。 彼らが、ルーティングアップデートを発行するどんなホストもルータであるに違いないと仮定するので、非地方の目的地へのトラフィックをそこに送ることができます。 RIPv1は任意の接頭語をサポートしませんが、ルーティングアップデートを発行するルータはそれらが正しくそのようなトラフィックを進める追加能力を持っているかもしれません。 優先権がしたがって、総合的なルーティング構造を理解しているルータに非ローカルルータを手に入れることであり、受け身のRIPはこれをする実行可能な方法であるかもしれません。
It may be appropriate to cut over on a site-by-site basis [Lear]. In such an approach, some sites have VLSM-aware hosts but others do not. As long as the routing structure supports VLSM, workarounds can be applied where needed.
それはサイトごとのベース[リア]でカットオーバーするのが適切であるかもしれません。 そのようなアプローチでは、いくつかのサイトがVLSM意識しているホストを持っていますが、他のものは持っているというわけではありません。 ルーティング構造がVLSMをサポートする限り、必要であるところで回避策を適用できます。
6.1.2 MAC Address Interactions
6.1.2 マックーアドレス相互作用
While it is uncommon now for a router to acquire any of its interface addresses as a DHCP client, this may become more common. When a router so acquires addresses, care must be taken that the MAC address presented to the DHCP server is in fact unique.
ルータがDHCPクライアントとしてインターフェース・アドレスのどれかを習得するのが、現在珍しい間、これは、より一般的になるかもしれません。 ルータがいつしたがって、アドレスを習得して、気にかけるか取らなければなりません。事実上、DHCPサーバに提示されたMACアドレスはユニークです。
Modern routers usually support protocol architectures besides IP. Some of these architectures, notably DECnet, Banyan VINES, Xerox Network Services, and IPX, may modify MAC addresses of routers such that a given MAC address appears on more than one interface. While this is normally not a problem, it could cause difficulties when the MAC address is assumed to be unique.
通常、現代のルータはIP以外にプロトコルアーキテクチャをサポートします。 これらのアーキテクチャのいくつか(著しくDECnet、Banyanバインズ、ゼロックスNetwork Services、およびIPX)がルータのMACアドレスを変更するかもしれないので、与えられたMACアドレスは1つ以上のインタフェースに現れます。 これは通常問題ではありませんが、MACアドレスが特有であると思われるとき、それは困難を引き起こす場合がありました。
Other situations occur when the same MAC address can appear on more than one interface. There are high-availability IBM options which establish primary and backup instances of the same MAC address on different physical interfaces of 37x5 communications controllers.
同じMACアドレスが1つ以上のインタフェースに現れることができるなら、他の状況は起こります。 予備選挙を確立して、同じMACアドレスのインスタンスのバックアップをとる高可用性IBMのオプションが37×5台のコミュニケーションコントローラの異なった物理インターフェースにあります。
Berkowitz Informational [Page 24] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[24ページ]のRFC2072Router
Some end hosts running protocol stacks other than IP, notably DECnet, may change their MAC address from the globally assigned built-in address.
IP以外のプロトコル・スタックを動かす終わりのホスト(著しくDECnet)の中にはグローバルに割り当てられた内蔵のアドレスから自分達のMACアドレスを変える人もいるかもしれません。
6.2 Dynamic
6.2 動力
Dynamic protocol mechanisms that to some extent depend on IP addresses may be affected by router renumbering. These include mechanisms that assign or resolve addresses (e.g., DHCP, DNS), mechanisms that use IP addresses for identification (e.g., SNMP), security and authentication mechanisms, etc. The listed mechanisms are apt to have configuration files that will be affected by renumbering.
ある程度よるダイナミックなプロトコルメカニズムは、番号を付け替えながら、IPアドレスでルータで影響を受けるかもしれません。 これらはアドレスを割り当てるか、または決議するメカニズム(例えば、DHCP、DNS)と識別にIPアドレスを使用するメカニズム(例えば、SNMP)とセキュリティと認証機構などを含んでいます。 記載されたメカニズムには、番号を付け替えることによって影響を受ける構成ファイルがある傾向があります。
Another area of dynamic behavior that can be affected is caching. Application servers, directory functions such as DNS, etc., may cache IP addresses. When the router is renumbered, these servers may point to old addresses. Certain proxy server functions may reside on routers, and the router may need to be restarted to reset the cache.
影響を受けることができる動的挙動の別の領域はキャッシュです。 アプリケーション・サーバー(DNSなどのディレクトリ機能)はIPアドレスをキャッシュするかもしれません。 ルータが番号を付け替えられるとき、これらのサーバは旧住所を示すかもしれません。 あるプロキシサーバ機能はルータにあるかもしれません、そして、ルータはキャッシュをリセットするために再開される必要があるかもしれません。
The endpoints of TCP tunnels terminating on routers may be internally identified by address/port pairs at each end. If the address changes, even if the port remains the same, the tunnel is likely to need to be reestablished.
ルータで終わるTCPトンネルの終点は各端のときにアドレス/ポート組によって内部的に特定されるかもしれません。 ポートが同じままで残ってもアドレスが変化するなら、トンネルが復職するのが必要でありそうです。
7. Tools and Methods for Renumbering
7. 番号を付け替えるツールとメソッド
The function of a renumbering tool can be realized either as manual procedures as well as software. This section deals with functionality of hypothetical yet general renumbering tools rather than their implementation.
ソフトウェアと同様に手作業として番号を付け替えるツールの機能を実現できます。 このセクションはそれらの実装よりむしろ仮定していますが、一般的な番号を付け替えるツールの機能性に対処します。
General caveat: tools should know whether the environment supports classless addressing. If it does not, newly generated addresses should be checked to see they do not fall into the all-zeroes or all-ones subnet values.
一般警告: ツールは、環境が階級のないアドレシングをサポートするかどうかを知るべきです。 そうしないなら、新たに生成しているアドレスは、オールゼロかオールものサブネット値にならないのを確実にするためにチェックされるべきです。
7.1 Search Mechanisms
7.1 検索メカニズム
Tools will be needed to search configuration files and other databases to identify addresses and names that will be affected by reorganization. This search should be based on the address inventory described above.
ツールが、再編成で影響を受けるアドレスと名前を特定するために構成ファイルと他のデータベースを捜すのに必要でしょう。 この検索は上で説明されたアドレス目録に基づくべきです。
Especially when searching for names, common search tools using regular expressions (e.g., grep) may be very useful. Some additional search tools may be needed. One would convert dotted decimal search arguments to binary and only then makes the comparison.
特に名前を捜し求めるとき、正規表現(例えば、grep)を使用する一般的な検索ツールは非常に役に立つかもしれません。 いくつかの追加検索ツールが必要であるかもしれません。 1つはドット付き10進法検索議論をバイナリーに変換するでしょう、そして、その時だけが比較をします。
Berkowitz Informational [Page 25] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[25ページ]のRFC2072Router
The comparison may need to be done under the constraint of a mask. Such a comparator would also be relevant as the second phase that looks for ipAddress and other relevant strings in MIBs.
比較は、マスクの規制でする必要があるかもしれません。 また、そのような比較器もMIBsでipAddressと他の関連ストリングを探す2番目のフェーズとして関連しているでしょう。
7.2 Address Modification
7.2 アドレス変更
The general mechanism for address modification is substitution of an arbitrary number of bits in an address. In the simplest cases, there is a one-to-one correspondence between old and new bit positions.
アドレス変更のための一般的機構はアドレスで、ビットの特殊活字の数字の代替です。 最も簡単な場合には、古くて新しいビット位置の間には、1〜1つの通信があります。
Especially when address modification is manual, it should be remembered that the affected bits can be obscured by dotted decimal notation. Work in, or at least consider, binary notation to assure accuracy.
特にアドレス変更が手動であるときに、ドット付き10進法で影響を受けるビットを見えなくすることができるだろうというのが覚えていられるべきです。 2進法を中で扱うか、または少なくとも、考えて、精度を保証してください。
Several basic functions can be defined:
いくつかの基本機能を定義できます:
zerobits(position,length):
clear <length> bits starting at <position>
orbits(position,length,newbits)
OR the bit string <newbits> of <length> starting at <position>
zerobits(位置、長さ): <位置の>で<位置の>軌道(位置、長さ、newbits)ORで<の長さの>のビット列<newbits>を始動し始める明確な<長さの>ビット
In these examples, the index [j] is used to identify entries in the address inventory database for existing addresses, while [k] identifies new addresses.
これらの例では、インデックス[j]は既存のアドレスのためのアドレス目録データベースにおけるエントリーを特定するのに使用されます、[k]が新しいアドレスを特定しますが。
Remember that these tools operate at a bit level, so the new address will have to be converted back into dotted decimal, MIB ASN.1, or other notation before it can be replaced into configuration files.
それを構成ファイルに取り替えることができる前にドット付き10進法、MIB ASN.1、または他の記法に新しいアドレスを変換し返さなければならないためにこれらのツールがしばらくレベルで作動したのを覚えていてください。
7.2.1 Prefix Change, No Change in Length
7.2.1 接頭語変化、長さにおける変化がありません。
If the entire new prefix has the same number of bits as the old external part, requiring no change to subnetting, the router part of renumbering may be fairly simple. If the router configurations are available in machine-readable form, as text files or parsable SNMP data, it is a relatively simple task to define a tool to examine IP addresses in the configuration, identify those beginning with the old prefix, and substitute the new prefix bit-by-bit.
サブネッティングへの変化を全く必要としないで、全体の新しい接頭語が古い外部の部分に同じ数のビットを持っているなら、番号を付け替えることのルータ部分はかなり簡単であるかもしれません。 ルータ構成がテキストファイルかparsable SNMPデータとして機械可読なフォームで利用可能であるなら、構成でIPアドレスを調べて、それらの始めを古い接頭語と同一視して、接頭語ビットごとに新しい置換するためにツールを定義するのは、比較的簡単なタスクです。
for each address[j],
zerobits(0,PrefixLength[j])
orbits(0,PrefixLength[j],NewPrefix[j])
各アドレス[j]、zerobits、(0、PrefixLength[j])軌道(0、PrefixLength[j]、NewPrefix[j])
Note that the host part is unaffected. Both subnet specifications (e.g., for route advertisements) and specific host references will be changed correctly in this simple case.
ホスト部分が影響を受けないことに注意してください。 この簡単な場合で正しくサブネット仕様(例えば、ルート広告のための)と特定のホスト参照の両方を変えるでしょう。
Berkowitz Informational [Page 26] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[26ページ]のRFC2072Router
7.2.2 highOrderPart change
7.2.2 highOrderPart変化
Matters are slightly more complex when the change applies only to the externally-controlled part of the prefix, as might be the case when an organization changes ISPs and renumbers into the ISP's address space, without changing the internal subnet structure.
変化であるときに、件はわずかに複雑です。内部サブネット構造を変えないで、組織がISPを変えるときのケースであるかもしれないことのような接頭語の外部的に制御された部分だけに付けて、ISPのアドレス空間に番号を付け替えます。
The substitution process is much as the previous case, except only the high-order bits change:
代替プロセスは高位のビット変化だけ以外の先の事件として多くです:
for each address,
zerobits(0,highOrderPartLength[j])
orbits(0,highOrderPartLength,newHighOrderPart[k])
各アドレス、zerobits、(0、highOrderPartLength[j])軌道(0、highOrderPartLength、newHighOrderPart[k])
7.2.3 lowOrderPart change
7.2.3 lowOrderPart変化
Organizations might renumber only the lowOrderPart (i.e., the subnet field) of their address space. This might be done to clean up an address space into contiguous blocks prior to introducing a routing system that aggregates addresses, such as OSPF.
組織はそれらのアドレス空間のlowOrderPart(すなわち、サブネット分野)だけに番号を付け替えさせるかもしれません。 アドレスに集められるルーティングシステムを紹介する前に隣接のブロックにアドレス空間をきれいにするためにこれをするかもしれません、OSPFなどのように。
for each address[j],
zerobits(highOrderPartLength[j],lowOrderPartLength[j])
orbits(highOrderPartLength[j],
lowOrderPartLength[j],newLowOrderPart[k])
各アドレス[j]、zerobits、(highOrderPartLength[j]、lowOrderPartLength[j])軌道(highOrderPartLength[j]、lowOrderPartLength[j]、newLowOrderPart[k])
7.2.4 lowOrderPart change, Change in lowOrderPart length
7.2.4 lowOrderPart変化、lowOrderPartの長さにおけるChange
When the length of the subnet field changes in all or part of the address space, things become significantly more complex. A fairly simple case arises when the host field is consistently too long, at least in the affected subnets. This is common, for example, when address space is being recovered in an existing Class B network with 8 bits of subnetting. Certain /24 bit prefixes are being extended to /30 and reallocated to point-to-point real or virtual (e.g., DLCI) media.
サブネット分野の長さがアドレス空間のすべてか一部で変化すると、いろいろなことはかなり複雑になります。 ホスト分野は少なくとも影響を受けるサブネットが一貫して長過ぎるときに、かなり簡単なケースが起こります。 アドレス空間がサブネッティングの8ビットで既存のClass Bネットワークで回復されているとき、例えば、これは一般的です。 /の24ビットのある接頭語は、/30に広げられて、二地点間本当の、または、仮想(例えば、DLCI)のメディアに再割当てされています。
for each address [j]
if address is affected by renumbering
if newLowOrderPartLength[k] > oldLowOrderPartLength[j]
then
zerobits(highOrderPartLength[k],newLowOrderPartLength[k])
orbits(highOrderPartLength[k],newLowOrderPart[k])
end
アドレスがnewLowOrderPartLength[k]の>のoldLowOrderPartLength[j]の当時のzerobitsであるなら番号を付け替えることによって影響を受けるならそれぞれに関しては、[j]を扱ってください、(highOrderPartLength[k]、newLowOrderPartLength[k])軌道、(highOrderPartLength[k]、newLowOrderPart[k])は終わります。
Berkowitz Informational [Page 27] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[27ページ]のRFC2072Router
7.2.5 highOrderPart change, Change in highOrderPart length
7.2.5 highOrderPart変化、highOrderPartの長さにおけるChange
When the length of the high-order part changes, but it is desired to keep the existing subnet structure, constraints apply. The situation is fairly simple if the new high-order part is shorter than the existing high order part.
高位部分の長さが変化しますが、既存のサブネット構造を保つのが必要であるときに、規制は適用されます。 新しい高位部分が既存の高位部分より短いなら、状況はかなり簡単です。
If the new high-order part is longer than the old high order part, constraints are more complex. The key is to see if any of the <k> most significant bits of the oldHighOrderPart, which overlap the <k> least significant bits of the newHighOrderPart, are nonzero. If no bits are nonzero, it may be simply to overlay the new prefix bits.
新しい高位部分が古い高位部分より長いなら、規制は、より複雑です。 キーは、oldHighOrderPartの<k>最上位ビットのどれかが非零であるかどうかわかることになっています。oldHighOrderPartはnewHighOrderPartの<k>最下位ビットを重ね合わせます。 どんなビットも非零でないなら、単にオーバレイへ、新しさがビットを前に置くということであるかもしれません。
7.3 Naming
7.3 命名
It is worthwhile to distinguish that a router's use of a DNS name does not necessarily mean that name is defined in a name server. Routers often contain static address to name mappings local to the router, so both the DNS zone files and the router configurations will need to be checked.
名前は名前が必ず意味するというわけではないDNSのルータの使用ですが、それを区別する価値があります。. ルータがルータへのローカルのマッピングと命名するためにしばしば静的なアドレスを含むネームサーバで定義されています、したがって、DNSゾーンファイルとルータ構成の両方がチェックされる必要があるでしょう。
What we first want to do is generate a list of name/address mappings, the mapping mechanism for each instance (e.g., static entry in configuration file, RR in our zone's DNS, RR in a zone file outside ours), the definition statement (or equivalent if the routers are configured with SNMP), and current IP address. We then want to compare the addresses in this list to the list defined earlier of prefixes affected by renumbering. The intersection of these lists define where we need to make changes.
最初にしたいと思うことは名前/アドレスのリストがマッピングと、各インスタンス(例えば、構成ファイルにおける静的なエントリー、私たちのゾーンのDNSのRR、ゾーンのRRは外に私たちのものをファイルする)のためのマッピングメカニズムと、定義声明(同等物はルータであるならSNMPによって構成される)と、現在のIPアドレスであると生成することです。 そして、より早く番号を付け替えることによって影響を受ける接頭語について定義されたリストへのこのリストのアドレスを比較したいと思います。 これらのリストの交差点は、私たちが、どこで変更を行う必要であるかを定義します。
Note that the explicit definition statement, or at leasts its variables, should be kept. In the real world, static IP address mappings in hosts may not have been maintained as systematically as are RR records in a DNS server. It is entirely possible that different host mapping entries for the same name point to different addresses.
明白な定義声明、または最少のその変数が保管されるべきであることに注意してください。 本当の世界では、ホストの静的IPアドレスマッピングがDNSサーバでのRR記録のように同じくらい系統的に維持されていないかもしれません。同じ名前のための異なったホストマッピングエントリーが異なったアドレスを示すのは、完全に可能です。
7.3.1 DNS Tools
7.3.1 DNSツール
The DNS itself can both delay and and speed router renumbering. Caches in DNS servers both inside and outside the organization may have sufficient persistence that a "flag day" cutover is not practical if worldwide connectivity is to be kept. DNS can help, however, make a period of old and new address coexistence work.
DNS自身はともにルータの番号を付け替えることを遅らせて、そして、促進できます。 組織の外で実用的に中でDNSサーバで両方をキャッシュして、「旗の日」カットオーバは十分な固執ですが、世界的な接続性が保たれることであるならキャッシュしたかもしれません。 しかしながら、DNSは、古くて新しいアドレス共存の一区切りが働かせるのを助けることができます。
If, for example, a given router interface may have a coexisting new and old address, it can be appropriate to introduce the new address as a CNAME alias for the new address.
例えば、与えられたルータインタフェースに共存の新しくて古いアドレスがあるかもしれないなら、新しいアドレスのためにCNAMEとして通称新しいアドレスを紹介するのは適切である場合があります。
Berkowitz Informational [Page 28] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[28ページ]のRFC2072Router
DNS RR statements can end with a semicolon, indicating the rest of the line is a comment. This can be used as the basis of tools to renumber DNS names for router addresses, by putting a comment (e.g., ";newaddr") at the end of the CNAME statements for the new addresses. At an appropriate time, a script could generate a new zone file in which the new addresses become the primary definitions on A records, and the old addresses could become appropriately commented CNAME records. At a later time, these commented CNAME entries could be removed.
DNS RR声明はセミコロンで終わって、系列の残りがコメントであることを示すことができます。 「ルータアドレスにツールがDNS名に番号を付け替えさせる基礎としてこれを使用できます、コメントを置くことによって(例えば」、newaddr、」、)、新しいアドレスのためのCNAME声明の終わりで。 適当な機会に、スクリプトは新しいアドレスがA記録でプライマリ定義になる新しいゾーンファイルを生成するかもしれません、そして、旧住所は適切に論評されたCNAME記録になることができました。 後で、これらの論評されたCNAMEエントリーを取り除くことができました。
Care should be taken to assure that PTR reverse mapping entries are defined for new addresses, because some router vendor tools depend on reverse mapping.
PTRの逆のマッピングエントリーが新しいアドレスのために定義されることを保証するために注意するべきです、いくつかのルータベンダーツールが逆のマッピングによるので。
7.3.2 Related name tools
7.3.2 関連名前ツール
Especially on UNIX and othe that do routing, there may be static name definitions. Such definitions are probably harder to keep maintained than entries in the DNS, simply because they are more widely distributed.
特にルーティングをするUNIXとotheに、静的な名前定義があるかもしれません。 単に彼らがDNSのエントリーより広く分配されるのでそのような定義はたぶん維持されていた状態で、より保ちにくいです。
Several tools are available to generate more maintainable entries. A perl script called h2n converts host tables into zone data files that can be added to the DNS server. It is available as ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z. Another tool, makezones, is part of the current BIND distribution, and can also be obtained from ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones
いくつかのツールが、より維持できるエントリーを生成するために利用可能です。 h2nと呼ばれるパールスクリプトはDNSサーバに追加できるゾーンデータファイルにホストテーブルを変換します。それは、 ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z 別のツール(makezones)を現在のBIND分配の一部であり、また、 ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones から得ることができるので、利用可能です。
See the DNS Resources Directory at http://www.dns.net/dnsrd.
http://www.dns.net/dnsrd でDNSリソースディレクトリを見てください。
8. Router Identifiers
8. ルータ識別子
Configuration commands in this category assign IP addresses to physical or virtual interfaces on a single router. They also include commands that assign IP-address-related information to the router "box" itself, and commands which involve the router's interaction with neighbors below the full routing level (e.g., default gateways, ARP).
このカテゴリにおける構成コマンドはただ一つのルータで物理的であるか仮想のインタフェースにIPアドレスを割り当てます。 また、彼らはIPアドレス関連の情報をルータ「箱」自体に割り当てるコマンド、および完全なルーティングレベル(例えば、デフォルトゲートウェイ、ARP)の下における隣人とのルータの相互作用にかかわるコマンドを含んでいます。
Routers may have other unique identifiers, such as DNS names used for the set of addresses on the "box," or SNMP systemID strings.
ルータには、他のユニークな識別子があるかもしれません、「箱」に関するアドレスのセットに使用されるDNS名、またはSNMP systemIDストリングなどのように。
8.1. Global Router Identification
8.1. グローバルなルータ識別
Traditional IP routers do not have unique identifiers, but rather are treated as collections of IP addresses associated with their interfaces. Some protocol mechanisms, notably OSPF and BGP, need an
伝統的なIPルータは、ユニークな識別子を持っていませんが、むしろそれらのインタフェースに関連しているIPアドレスの収集として扱われます。 いくつかのプロトコルメカニズム、著しくOSPF、およびBGPが必要です。
Berkowitz Informational [Page 29] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[29ページ]のRFC2072Router
address for the router itself, typically to establish tunnel endpoints between peer routers. Other applications include "unnumbered interfaces" used to conserve address space for serial media, a practice discussed further below.
ルータのためにそれ自体を通常扱ってください。同輩ルータの間のトンネル終点を証明するために。 他のアプリケーションは連続のメディア、以下でさらに議論した習慣のためにアドレス空間を保存するのに使用される「無数のインタフェース」を含んでいます。
In the illustration below, the 10.1.0.0/16 address space is used for global identifiers. A TCP tunnel runs from 10.1.0.1 to 10.1.0.2, but its traffic is load-shared among the two real links, 172.31.1.0 and 172.31.2.0.
以下のイラストでは、10.1.0.0/16アドレス空間はグローバルな識別子に使用されます。 TCPトンネルは10.1から.0を.1〜10.1に実行します。そして、.0 .2 唯一のトラフィックが負荷で2つの中で共有された本当のリンクである、172.31、.1、.0、172.31 .2 .0。
172.31.4.1/24 172.31.5.1/24
| |
| |
+-------------------------------------+
| Router 1 |
| |
| 10.1.0.1/16 |
| # |
+-------------------#-----------------+
| 172.31.1.1/24 # | 172.31.2.1/24
| # |
| # |
| # |
| # |
| # |
| # |
| 172.31.1.2/24 # | 172.31.2.2/24
+-------------------#-----------------+
| Router 2 |
| |
| 10.1.0.2/16 |
| |
+-------------------------------------+
| |
| |
172.31.5.1/24 172.31.6.1/24
172.31.4.1/24 172.31.5.1/24 | | | | +-------------------------------------+ | ルータ1| | | | 10.1.0.1/16 | | # | +-------------------#-----------------+ | 172.31.1.1/24 # | 172.31.2.1/24 | # | | # | | # | | # | | # | | # | | 172.31.1.2/24 # | 172.31.2.2/24 +-------------------#-----------------+ | ルータ2| | | | 10.1.0.2/16 | | | +-------------------------------------+ | | | | 172.31.5.1/24 172.31.6.1/24
A common practice to provide router identifiers is using the "highest IP address" on the router as an identifier for the "box." Many implementations have a default mechanism to establish the router ID, which may be the highest configured address, or the highest active address.
ルータ識別子を提供する一般的な習慣は「箱」に識別子としてルータにおける「最も高いIPアドレス」を使用しています。 多くの実装には、最も高い構成されたアドレス、または最も高いアクティブなアドレスであるかもしれないルータIDを確立するデフォルトメカニズムがあります。
Berkowitz Informational [Page 30] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[30ページ]のRFC2072Router
Typical applications of a global router ID may not require it be a "real" IP address that is advertised through the routing domain, but is simply a 32-bit identifier local to each router. When this is the case, this identifier can come from the RFC 1918 private address space rather than the enterprise's registered address space.
経路ドメインを通って広告を出しますが、単に32ビットの識別子である「本当」のIPアドレスが各ルータにローカルであったなら、グローバルなルータIDの主用途はそれを必要としないかもしれません。 これがそうであるときに、この識別子は企業の登録されたアドレス空間よりむしろ1918年のRFCの個人的なアドレス空間から来ることができます。
Allowing default selection of the router ID can be unstable and is not recommended. Most implementations have a means of declaring a pseudo-IP address for the router itself as opposed to any of its ports.
ルータIDのデフォルト選択を許すのは、不安定である場合があり、推薦されません。 ほとんどの実装には、ポートのどれかと対照的にルータ自体のための疑似IPアドレスを宣言する手段があります。
Changes to this pseudo-address may have implications for DNS. Even if this is not a real address, A and PTR resource records may have been set up for it, so diagnostics can display names rather than addresses.
この疑似アドレスへの変化には、DNSのための意味があるかもしれません。 AとPTRリソース記録がこれが本当のアドレスでなくても、それに設定されたかもしれないので、病気の特徴はアドレスよりむしろ名前を表示できます。
Another potential DNS implication is that a CNAME may have been established for the entire set of interface addresses on a router. This allows testing, telnet, etc., to the router via any reachable path.
別の潜在的DNS含意はCNAMEがルータに関する全体のインターフェース・アドレスのために設立されたかもしれないということです。 これはどんな届いている経路を通してもテスト、telnetなどをルータに許容します。
8.2 Interface Address
8.2 インターフェース・アドレス
Interface addresses are perhaps the most basic place to begin router renumbering. Interface configuration will require an IP address, and usually a subnet mask or prefix length. Some implementations may not have a subnet mask in the existing configuration, because they use a "default mask" based on a classful assumption about the address. Be aware of possible needs for explicit specification of a subnet mask or other prefix length specification when none previously was specified. This will be especially common on older host-based routers.
インターフェース・アドレスは恐らくルータの番号を付け替えることを始める最も基本的な場所です。 インタフェース構成は通常IPアドレスと、サブネットマスクか接頭語の長さを必要とするでしょう。 いくつかの実装は既存の構成でサブネットマスクを持っていないかもしれません、アドレスに関するclassful仮定に基づく「デフォルトマスク」を使用するので。 なにも以前に指定されなかったとき、サブネットマスクか他の接頭語長さの仕様の明白な仕様の可能な必要性を意識してください。 これは、より古いホストベースのルータで特に一般的になるでしょう。
Multiple IP addresses, in different subnets, can be assigned to the same interface. This is often a valuable technique in renumbering, because the router interface can be configured to respond to both the new and old addresses.
異なったサブネットでは、複数のIPアドレスを同じインタフェースに割り当てることができます。 しばしばこれは番号を付け替えることで有益なテクニックです、両方の新しくて古いアドレスに応じるためにルータインタフェースを構成できるので。
Caution is necessary, however, in using multiple subnet addresses on the same interface. OSPF and IS-IS implementations may not advertise the additional addresses, or may constrain their advertisement so all must be in the same area.
しかしながら、警告が同じインタフェースに関する複数のサブネットアドレスを使用するのにおいて必要です。 そして、OSPF、-、実装が追加アドレスの広告を出さないか、または彼らの広告を抑制するかもしれないので、すべてが同じ領域にあるに違いありません。
Berkowitz Informational [Page 31] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[31ページ]のRFC2072Router
When this method is used to make the interface respond to new and old addresses, and the renumbering process is complete, care must be taken in removing the old addresses. Some router implementations have special meaning to the order of address declarations on an interface. It is highly likely that routers, or at least the interface, must be restarted after an address is removed.
このメソッドがインタフェースを新しくて古いアドレスに応じさせるのに使用されて、番号を付け替えるプロセスが完全であるときに、旧住所を取り除きながら、注意を中に入れなければなりません。 いくつかのルータ実装がインタフェースにおけるアドレス宣言の注文に特別な意味を持っています。 アドレスを取り除いた後にルータ、または少なくともインタフェースを非常に再開しなければならなそうです。
8.3 Unnumbered Interfaces
8.3 無数のインタフェース
As mentioned previously, several conventions have been used to avoid wasting subnet space on serial links. One mechanism is to implement proprietary "half-router" schemes, in which the unnumbered link between router pairs is treated as an "internal bus" creating a "virtual router," such that the scope of the unnumbered interface is limited to the pair of routers.
既述のとおり、数人のコンベンションが、連続のリンクにサブネットスペースを浪費するのを避けるのに使用されました。 1つのメカニズムは独占「半分ルータ」体系を実装することです、無数のインタフェースの範囲がルータの組に制限されるように。(そこでは、ルータ組の間の無数のリンクが、「仮想のルータ」を作成しながら、「内部のバス」として扱われます)。
| +------------+ +------------+ | | | | | | | | e0 | |s0 s0 | | | |-------------| R1 |................| R2 |-------| | 192.168.1.1 | 10.1.0.1/16| | 10.1.0.2/16| | | /24 | | | | | | +------------+ +------------+
| +------------+ +------------+ | | | | | | | | e0| |s0 s0| | | |-------------| R1|................| R2|-------| | 192.168.1.1 | 10.1.0.1/16| | 10.1.0.2/16| | | /24 | | | | | | +------------+ +------------+
In the above example, software in routers R1 and R2 automatically forward every packet received on serial interface S0 to Ethernet interface E0. They forward every packet on e0 to their local S0. Neither S0 has an IP address. R1 has the router ID 10.1.0.1/16 and R2 has 10.1.0.2/16.
上記の例、R1とR2が自動的に進めるルータにおけるソフトウェアでは、あらゆるパケットがシリアルインタフェースS0でイーサネットインタフェースに0E受信されました。 彼らはe0であらゆるパケットを地元のS0に送ります。 どちらのS0も、IPアドレスがありません。 R1には、ルータID10.1.0.1/16があります、そして、R2には、.0が10.1に.2/16にあります。
It is thus impossible to send a specific ping to the S0 interfaces, making it difficult to test whether a connectivity problem is due to S0 or E0. Some management is possible as long as at least one IP address on the router (e.g., E0) is reachable, since this will permit SNMP connectivity to the router. Once the router is reachable with SNMP, the unnumbered interface can be queried through the MIB ifTable.
その結果、特定のピングをS0インタフェースに送るのは不可能です、接続性問題がS0か0Eのためであるか否かに関係なく、テストするのを難しくして。 ルータ(例えば、0E)に関する少なくとも1つのIPアドレスが届いている限り、何らかの管理が可能です、これがSNMPの接続性をルータに可能にするので。 ルータがいったんSNMPと共に届くようになると、MIB ifTableを通して無数のインタフェースについて質問できます。
Another approach is to use the global router identifier as a pseudo- address for every unnumbered interface on a router. In the above example, R1 would use 10.1.0.1 as its identifier. This provides an address to be used for such functions as the IP Route Recording option, and for providing a next-hop-address for routes.
別のアプローチはルータのあらゆる無数のインタフェースに疑似アドレスとしてグローバルなルータ識別子を使用することです。 上記では、例、R1は使用するでしょう。10.1 .0 .1 識別子として。 これは、IP Route Recordingオプションのような機能と、次のホップアドレスをルートに供給するのに使用されるためにアドレスを提供します。
Berkowitz Informational [Page 32] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[32ページ]のRFC2072Router
The second approach is cleaner, but still can create operational difficulties. If there are multiple unnumbered interfaces on a router, which one (if any) should/will respond to a ping? Other network management mechanisms do not work cleanly with unnumbered interface.
2番目のアプローチは、より清潔ですが、まだ運転上の諸問題を作成できます。 複数の無数のインタフェースがルータにあれば、/はピングにどれを(もしあれば)反応させるべきですか? 他のネットワークマネージメントメカニズムは無数のインタフェースで清潔に動作しません。
As part of a renumbering effort, the need for unnumbered interfaces should be examined. If the renumbering process moves the domain to classless addressing, then serial links can be given addresses with a /30 prefix, which will waste a minimum of address space.
番号を付け替える取り組みの一部として、無数のインタフェースの必要性は調べられるべきです。 番号を付け替えるプロセスがドメインを階級のないアドレシングに動かすなら、/30接頭語があるアドレスを連続のリンクに与えることができます。(接頭語は最小アドレス空間を浪費するでしょう)。
For dedicated or virtual dedicated point-to-point links within an organization, another alternative to unnumbered operation is using RFC1918 private address space. Inter-router links rarely need to be accessed from the Internet unless explicitly used for exterior routing. External traceroutes will also fail reverse DNS lookup.
組織の中のひたむきであるか仮想の専用ポイントツーポイント接続のために、無数の操作への別の代替手段はRFC1918プライベート・アドレススペースを使用することです。 外のルーティングに明らかに使用されない場合、相互ルータリンクによってインターネットからめったにアクセスされる必要はありません。 また、外部のトレースルートは逆のDNSルックアップに失敗するでしょう。
If unnumbered interfaces are kept, and the router-ID convention is used, it will probably be more stable to rely on an explicitly configured router ID rather than a default from a numbered interface address.
無数のインタフェースが保たれて、ルータIDコンベンションが使用されていると、番号付のインターフェース・アドレスからデフォルトよりむしろ明らかに構成されたルータIDを当てにするのはたぶんさらに安定するでしょう。
The situation becomes even more awkward if it is desired to use unnumbered interfaces over NBMA services such as Frame Relay. OSPF, for example, uses the IP address of numbered interfaces as a unique identifier for that interface. Since unnumbered interfaces do not have their own unique address, OSPF has not obvious way to identify these interfaces. A physical index (e.g., ifTable) could be used, but would have to be extended to have an entry for each logical entry (i.e., VC) multiplexed onto the physical interface.
Frame RelayなどのNBMAサービスの上で無数のインタフェースを使用するのが必要であるなら、状況はさらに無器用になります。 例えば、OSPFはそのインタフェースにユニークな識別子として番号付のインタフェースのIPアドレスを使用します。 無数のインタフェースがそれら自身のユニークな住所を知っていないので、OSPFには、これらのインタフェースを特定する当たり前の方法がありません。 物理的なインデックス(例えば、ifTable)は、使用できましたが、物理インターフェースに多重送信されたそれぞれの論理的なエントリー(すなわち、VC)のためのエントリーを持つために広げられなければならないでしょう。
8.4 Address Resolution
8.4 アドレス解決
While mapping of IP addresses to LAN MAC addresses is usually done automatically by the router software, there will be cases where special mappings may be needed. For example, the MAC address used by router interfaces may be locally administered (i.e., set manually), rather than relying on the burnt-in hardware address. It may be part of a proprietary method that dynamically assigns MAC addresses to interfaces. In such cases, an IP address may be part of the MAC address configuration statements and will need to be changed.
通常、ルータソフトウェアで自動的にLAN MACアドレスへのIPアドレスに関するマッピングをしている間、ケースが特別なマッピングが必要であるかもしれないところにあるでしょう。 例えば、ルータによって使用されるMACアドレスは燃えるのを当てにするより局所的にむしろ管理された(すなわち、手動で、セットします)ハードウェアがアドレスであったかもしれないなら連結します。 それはインタフェースへのダイナミックにアドレスをMACに割り当てる独占メソッドの一部であるかもしれません。 そのような場合、IPアドレスは、MACアドレス構成声明の一部であるかもしれなく、変えられる必要があるでしょう。
Berkowitz Informational [Page 33] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[33ページ]のRFC2072Router
Manual mapping to medium addresses will usually be needed for NBMA and switched media. When renumbering IP addresses, statements that map the IP address to frame relay DLCIs, X.121 addresses, SMDS and ATM addresses, telephone numbers, etc., will need to be changed to the new address. Local requirements may require a period of parallel operation, where the old and new IP addresses map to the same medium address.
通常、中型のアドレスへの手動のマッピングがNBMAと切り換えられたメディアに必要でしょう。 IPアドレスに番号を付け替えさせるとき、フレームリレーDLCIsとX.121アドレスとSMDSとATMアドレス、電話番号などにIPアドレスを写像する声明は、新しいアドレスに変えられる必要があるでしょう。 地方の要件は並列操作の期間を必要とするかもしれません。(そこでは、古くて新しいIPが同じ中型のアドレスに地図を扱います)。
8.5 Broadcast Handling
8.5 放送取り扱い
RFC1812 specifies that router interfaces MUST NOT forward limited broadcasts (i.e., to the all-ones destination address, 255.255.255.255). It is common, however, to have circumstances where a LAN segment is populated only by clients that communicate with key servers (e.g., DNS or DHCP) by sending limited broadcasts. Router interfaces can cope with this situation by translating the limited broadcast address to a directed broadcast address or a specific host address, which is legitimate to forward.
RFC1812は、ルータインタフェースが限られた放送(すなわち、目的地が255.255に.255を扱うオールものの.255への)を進めてはいけないと指定します。 しかしながら、LANセグメントが単に送付の限られた放送で主要なサーバ(例えば、DNSかDHCP)とコミュニケートするクライアントによって居住される事情を持っているのは一般的です。 ルータインタフェースは、指示された放送演説か特定のホスト・アドレスに限られた放送演説を翻訳することによって、この状況を切り抜けることができます。(ホスト・アドレスは、進めるために正統です)。
When limited address translation is done for serverless segments, and the new target address is renumbered, the translation rule must be reconfigured on every interface to a serverless segment. Be sure to recognize that a given segment might have a server from the perspective of one service (e.g., DHCP), but could be serverless for other services (e.g., NFS or DNS).
serverlessセグメントのために限られたアドレス変換をして、新しいあて先アドレスに番号を付け替えさせるとき、あらゆるインタフェースで翻訳規則をserverlessセグメントに再構成しなければなりません。 与えられたセグメントが1つのサービス(例えば、DHCP)の見解からサーバを持っているかもしれませんが、他のサービス(例えば、NFSかDNS)のためのserverlessであるかもしれないと必ず認めてください。
8.6 Dynamic Addressing Support
8.6 ダイナミックなアドレシングサポート
Routers can participate in dynamic addressing with RARP, DHCP, BOOTP, or PPP. In a renumbering effort, several kinds of changes may made to be made on routers participating in dynamic addressing.
ルータはRARP、DHCP、BOOTP、またはPPPと共にダイナミックなアドレシングに参加できます。 番号を付け替える取り組みでは、ダイナミックなアドレシングに参加しながらルータで作らされていて、数種類の変化はそうするかもしれません。
If the router acts as a server for dynamic address assignment, the addresses it assigns will need to be renumbered. These might be specific addresses associated with MAC addresses or dialup ports, or could be a pool of addresses. Pools of addresses may be seen in pure IP environments, or in multiprotocol situations such as Apple MacIP.
ルータがダイナミックなアドレス課題のためのサーバとして機能すると、それが割り当てるアドレスは、番号を付け替えられる必要があるでしょう。 これらの力は、MACアドレスかダイアルアップポートに関連している特定のアドレスである、またはアドレスのプールであるかもしれません。 アドレスのプールは純粋なIP環境、またはアップルMacIPなどの「マルチ-プロトコル」状況で見られるかもしれません。
If the router does not assign addresses, it may be responsible for forwarding address assignment requests to the appropriate server(s). If this is the case, there may be hard-coded references to the IP addresses of these servers, which may need to be changed as part of renumbering.
ルータがアドレスを割り当てないなら、適切なサーバへのフォーワーディング・アドレス課題要求に責任があるかもしれません。 これがそうであるなら、番号を付け替えることの一部として変えられる必要があるかもしれないこれらのサーバのIPアドレスの一生懸命コード化された参照があるかもしれません。
Berkowitz Informational [Page 34] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[34ページ]のRFC2072Router
9. Filtering and Access Control
9. フィルタリングとアクセスコントロール
Routers may implement mechanisms to filter packets based on criteria other than next hop destination. Such mechanisms often are implemented differently for unicast packets (the most common case) or for multicast packets (including routing updates). Filtering rules may contain source and/or destination IP addresses that will need to change as part of a renumbering effort.
ルータは、次のホップの目的地以外の評価基準に基づくパケットをフィルターにかけるためにメカニズムを実装するかもしれません。 そのようなメカニズムはユニキャストパケット(最も一般的なケース)かマルチキャストパケットのためにしばしば異なって実装されます(アップデートを発送するのを含んでいて)。 規則をフィルターにかけると、ソース、そして/または、番号を付け替える取り組みの一部として変化する必要がある送付先IPアドレスは含むかもしれません。
Filtering can be done to implement security policies or to control traffic. In either case, extreme care must be taken in changing the rules, to avoid leakage of sensitive information. denial of access to legitimate users, or network congestion.
安全保障政策を実装するか、または交通整理するためにフィルタリングができます。 どちらの場合ではも、機密情報正統のユーザ、またはネットワークの混雑へのアクセスの否定の漏出を避けるために規則を変えながら、極端な注意を中に入れなければなりません。
Routers may implement logging of filtering events, typically denial of access. If logging is implemented, logging servers to which log events are sent preferably should be identified by DNS name. If the logging server is referenced by IP address, its address may need to change during renumbering. Care should be taken that critical auditing data is not lost during the address change.
ルータはイベント、通常アクセサリーの否定をフィルターにかける伐採を実装するかもしれません。 伐採が実装されるなら、望ましくは、ログイベントが送られる伐採サーバはDNS名によって特定されるべきです。 伐採サーバがIPアドレスによって参照をつけられるなら、アドレスは、番号を付け替えている間、変化する必要があるかもしれません。 注意は取って、その重要な監査のデータがアドレス変化の間、失われていないということであるべきです。
9.1 Static Access Control Mechanisms
9.1 静的なアクセス管理機構
Router filters typically contain some number of include/exclude rules that define which packets to include in forwarding and which to exclude. These rules typically contain an address argument and some indication of the prefix length. This length indication could be a count, a subnet mask, or some other mask.
フィルタが何らかの数を通常含むルータは、推進にどのパケットを含むか、そして、どれを除いたらよいかを定義する規則を、含んでいるか、または除きます。 これらの規則はアドレス議論と接頭語の長さのいくつかのしるしを通常含んでいます。 この長さの指示は、カウント、サブネットマスク、またはある他のマスクであるかもしれません。
When renumbering, the address argument clearly has to change. It can be more subtle if the prefix length changes, because the length specification in the rule must change as well. Needs for such changes may be hard to recognize, because they apply to ranges of addresses that might be at a level of aggregation above the explicit renumbering operation.
番号を付け替えるとき、アドレス議論は明確に変化しなければなりません。 接頭語の長さが変化するなら、より微妙である場合があります、規則による長さの仕様がまた、変化しなければならないので。 そのような変化の必要性は認識するのが困難であるかもしれません、明白な番号を付け替える操作を超えて集合のレベルにあるかもしれないアドレスの範囲に適用するので。
RFC 1812 requires that address-based filtering allow arbitrary prefix lengths, but some hosts and routers might only allow classful prefixes.
RFC1812は、アドレスベースのフィルタリングが任意の接頭語の長さを許容するのを必要としますが、いくつかのホストとルータがclassful接頭語を許容するだけであるかもしれません。
Berkowitz Informational [Page 35] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[35ページ]のRFC2072Router
9.2 Special Firewall Considerations
9.2 特別なファイアウォール問題
Routers are critical components of firewall systems. Architecturally, two router functions are described in firewall models, the external screening router between the outside and the "demilitarized zone (DMZ)," and the internal screening router between the inside and the "perimeter network." Between these two networks is the bastion host, in which reside various non-routing isolation and authentication functions, beyond the scope of this document.
ルータはファイアウォールシステムの重要な要素です。建築上、2つのルータ機能がファイアウォールモデル、外部と「非武装地帯(DMZ)」の間の外部の選別ルータ、および内部と「周辺ネットワーク」の間の内部の選別ルータで説明されます。 これらの2つのネットワークの間に、要塞ホスト(様々な非ルーティング分離と認証機能はある)があります、このドキュメントの範囲を超えて。
One relevant aspect of the bastion host, however, is that it may do address translation or higher-layer mappings between differnt address spaces. If the "outside" address space (i.e., visible to the Internet) changes, this will mean that the outside screening router will need configuration changes. Since the outside screening router may be under the control of the ISP rather than the entrerprise, administrative coordination will be needed.
しかしながら、要塞ホストの1つの関連局面はdifferntアドレス空間の間のアドレス変換か、より高い層のマッピングをするかもしれないということです。 「外」のアドレス空間(すなわち、インターネットに目に見える)が変化すると、これは、外の選別ルータが構成変更を必要とすることを意味するでしょう。 以来に、外の選別ルータがむしろISPのコントロールの下にあるかもしれない、entrerpriseする、管理的調整が必要でしょう。
DMZ +--------+ Peri-
|---| Public | meter
+-----------+ | | Hosts | | +-----------+
From | External | | +--------+ |---| Internal |
Internet...| Screening |---| +--------+ | | Screening |
| Router | |---| Bastion|------| | Router |....To
+-----------+ | | Host | | +-----------+ Internal
| +--------+ | +-----------+ Network
| +--------+ |---| Dialup |
|---| Split | | | Access |
| | DNS | | | Server |
| +--------+ | +-----------+
非武装地帯+--------+ ペーリ|---| 公衆| メーター+-----------+ | | ホスト| | +-----------+| 外部| | +--------+ |---| 内部| インターネット…| 選別|---| +--------+ | | 選別| | ルータ| |---| とりで|------| | ルータ|....+に-----------+ | | ホスト| | +-----------+内部です。| +--------+ | +-----------+ ネットワーク| +--------+ |---| ダイアルアップ| |---| 分けられます。| | | アクセス| | | DNS| | | サーバ| | +--------+ | +-----------+
External screening routers typically have inbound access lists that block unauthorized traffic from the Internet, and outbound access lists that permit access only to DMZ servers and the bastion host. The inbound filters commonly block the Private Address Space, as well as address space from the enterprise's internal network. If the internal network address changes, the inbound filters clearly will need to change.
外部の選別ルータには、インターネット、およびアクセスを許可する外国行きのアクセスリストだけからDMZサーバと要塞ホストまで権限のないトラフィックを妨げる本国行きのアクセスリストが通常あります。 本国行きのフィルタは企業の内部のネットワークから兵士のAddress Space、およびアドレス空間を一般的に妨げます。 内部のネットワーク・アドレスが変化すると、本国行きのフィルタは、明確に変化する必要があるでしょう。
If DMZ host addresses change, the corresponding outbound filters from the external screening host also will need to change. Internal screening routers permit access from the internal network to selected servers on the perimeter network, as well as to the bastion host itself. If the enterprise uses private address space internally, renumbering may not affect this router.
DMZホスト・アドレスが変化すると、外部の選別ホストからの対応する外国行きのフィルタも、変化する必要があるでしょう。 内部の選別ルータは周辺ネットワークで内部のネットワークから選択されたサーバまでアクセスを許可します、よく要塞ホスト自体のように。 企業が内部的にプライベート・アドレススペースを使用するなら、番号を付け替えるのはこのルータに影響しないかもしれません。
Berkowitz Informational [Page 36] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[36ページ]のRFC2072Router
Another component of a firewall system is the "split DNS" server, which provides address mapping in relation to the globally visible parts of the
ファイアウォールシステムの別の部品は「分裂DNS」サーバです。(そのサーバはグローバルに目に見える部分と関連してアドレス・マッピングを提供します)。
9.3 Dynamic Access Control Mechanisms
9.3 動的呼出し制御機構
Certain access control services, such as RADIUS and TACACS+, may insert dynamically assigned access rules into router configurations. For example, a RADIUS database "contains a list of requirements which must be met to allow access for the user. This always includes verification of the password, but can also specify the client(s) or port(s) to which the user is allowed access. [Rigney]."
RADIUSやTACACS+などのあるアクセス制御サービスはダイナミックに割り当てられたアクセス規則をルータ構成に挿入するかもしれません。 例えば、RADIUSデータベースは「ユーザのためのアクセスを許すために満たさなければならない必要条件のリストを含んでいます」。 これはいつもパスワードの検証を含んでいます、また、クライアントを指定するか、またはアクセサリーがユーザがどれであるかに許容された(s)を移植できるのを除いて 「[Rigney]。」
Configuration information dynamically communicated to the router may be in the form of filtering rules. Effectively, this authentication database becomes an extension of the router configuration database. Both these databases may need to change as part of a renumbering effort.
ダイナミックにルータに伝えられた設定情報がフィルタリング規則の形にあるかもしれません。 事実上、この認証データベースはルータ構成データベースの拡大になります。 これらのデータベースの両方が、番号を付け替える取り組みの一部として変化する必要があるかもしれません。
Another dynamic configuration issue arises when "stateful packet screening" on bastion hosts or routers is used to provide security for UDP-based services, or simply for IP. In such services, when an authorized packet leaves the local environment to go into an untrusted address space, a temporary filtering rule is established on the interface on which the response to this packet is expected. The rule typically has a lifetime of a single packet response. If these rules are defined in a database outside of the router, the rule database again is an extension of router configuration that must be part of the renumbering effort.
要塞ホストかルータの「statefulパケット選別」がUDPベースのサービス、または単にIPにセキュリティを提供するのに使用されるとき、別の動的設定問題は起こります。 地方の環境が認可されたパケットで信頼されていないアドレス空間に入るときのそのようなサービスに、一時的なフィルタリング規則はこのパケットへの応答が予想されるインタフェースで確立されます。 規則には、ただ一つのパケット応答の寿命が通常あります。 これらの規則がデータベースで定義されるなら、ルータの外では、規則データベースは再び番号を付け替える取り組みの一部であるに違いないルータ構成の拡大です。
10. Interior Routing
10. 内部のルート設定
This section deals with routing inside an enterprise, which generally follows, ignoring default routes, the rules:
このセクションは企業の中でルーティングに対処します:一般に、デフォルトルート、規則を無視して、企業は続きます。
1. Does a single potential route exist to a destination?
If so, use it.
2. Is there more than one potential path to a destination?
If so, use the path with the lowest end-to-end metric.
3. Are there multiple paths with equal lowest cost to the
destination? If so, consider load balancing.
1. ただ一つの潜在的ルートは目的地に存在していますか? そうだとすれば、それを使用してください。 2. 目的地への1つ以上の潜在的経路がありますか? そうだとすれば、最も低い終わりから端がメートル法で経路を使用してください。 3. 目的地への等しい最も低い費用がある複数の経路がありますか? そうだとすれば、ロードバランシングを考えてください。
Most enterprises do not directly participate in global Internet routing mechanisms, the details of which are of concern to their service providers. The next section deals with those more complex exterior mechanisms.
ほとんどの企業は直接世界的なインターネットルーティングメカニズムに参加しません。その詳細はそれらのサービスプロバイダーに重要です。 次のセクションはそれらのより複雑な外のメカニズムに対処します。
Berkowitz Informational [Page 37] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[37ページ]のRFC2072Router
10.1 Static Routes
10.1のスタティックルート
During renumbering, the destination and/or next hop address of static routes may need to change. It may be necessary to restart routers or explicitly clear a routing table entry to force the changed static route to take effect.
番号を付け替えている間、スタティックルートの目的地、そして/または、次のホップアドレスは、変化する必要があるかもしれません。 ルータを再開するか、または変えられたスタティックルートを実施させるために明らかに経路指定テーブルエントリーをクリアするのが必要であるかもしれません。
10.2 RIP (Version 1 unless otherwise specified)
10.2 リップ(そうでなくない場合、バージョン1は指定しました)
The Routing Information Protocol (RIP) has long been with us, as one of the first interior routing protocols. It still does that job in small networks, and also has been used for assorted functions that are not strictly part of interior routing. In this discussion, we will first deal with pure interior routing applications.
最初の内部のルーティング・プロトコルの1つとしてルーティング情報プロトコル(RIP)が長い間、私たちと共にいます。 まだ、小さいところの仕事も内部のルーティングでネットワークでつないで、また、さまざまな機能が厳密に離れていないので使用されているのはしています。 この議論では、私たちは最初に、純粋な内部のルーティングアプリケーションに対処するつもりです。
In a renumbering effort that involves classless addressing, RIPv1 may not be able to cope with the new addressing scheme. Officially, this protocol is Historic and should be avoided in new routing plans. Where legacy support requirements dictate it be retained, it is worthwhile to try to limit RIPv1 in "stub" parts of the network. Vendor-specific mechanisms may be available to interface RIPv1 to a classless environment.
階級のないアドレシングにかかわる番号を付け替える取り組みでは、RIPv1は新しいアドレシング体系に対処できないかもしれません。 公式に、このプロトコルは、Historicであり、新しいルーティングプランで避けられるべきです。 レガシーサポート要件命令が保有されて、ネットワークの「スタッブ」部分でRIPv1を制限しようとする価値があるところ。 ベンダー特有のメカニズムは、階級のない環境にRIPv1を連結するように利用可能であるかもしれません。
As part of planning renumbering, strong consideration should be given to moving to RIPv2, OSPF, or other classless routing protocols as the primary means of interior routing. Doing so, however, may not remove the need to run RIP in certain parts of the enterprise.
計画の番号を付け替えることの一部として、内部のルーティングのプライマリ手段としてRIPv2、OSPF、または他の階級のないルーティング・プロトコルに移行することに対して強い考慮を払うべきです。 しかしながら、そうするのは企業のある部分でRIPを実行する必要性を取り除かないかもしれません。
RIP is widely implemented on hosts, where it may be used as a method of router discovery, or for load-balancing and fault tolerance when multiple routers are on a subnet. In these applications, RIP need not be the only routing protocol in the domain; RIP may be present only on stub subnets. Destination information from more capable routing protocols may be translated into RIP updates. While it is generally reasonable to minimize or remove RIP as part of a renumbering effort, be careful not to disable the ability of hosts to locate routers.
複数のルータがサブネットで実装されるとき、RIPはホストか、それがルータ発見のメソッドとして使用されるかもしれないところか、負荷分散と耐障害性のために広く実装されます。 これらのアプリケーションでは、RIPはそのドメインで唯一のルーティング・プロトコルである必要はありません。 RIPはスタッブサブネットだけに存在しているかもしれません。 よりできるルーティング・プロトコルからの目的地情報はRIPアップデートに翻訳されるかもしれません。 一般に、番号を付け替える取り組みの一部としてRIPを最小にするか、または取り外すのが妥当である間、ホストがルータの場所を見つける能力を無効にしないように、注意してください。
RIP is also used as a quasi-exterior routing mechanism between some customers and their ISPs, as a means simpler than BGP for the customer to announce routes to the provider.
また、RIPは何人かの顧客と彼らのISPの間の準外のルーティングメカニズムとして使用されます、BGPより顧客がルートをプロバイダーに発表するのが簡単である手段として。
10.3 OSPF
10.3 OSPF
OSPF has several sensitivities to renumbering beyond those of simpler routing protocols. If router IDs are assigned to be part of the registered address space, they may need to be changed as part of the renumbering effort. It may be appropriate to use RFC 1918 private
OSPFは、より簡単なルーティングのものを超えてプロトコルに番号を付け替えさせるのにいくつかの敏感さを持っています。 ルータIDが登録されたアドレス空間の一部になるように割り当てられるなら、それらは、番号を付け替える取り組みの一部として変えられる必要があるかもしれません。 それは個人的にRFC1918を使用するのが適切であるかもしれません。
Berkowitz Informational [Page 38] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[38ページ]のRFC2072Router
address space for router IDs, as long as these can be looked up in a DNS server within the domain.
ドメインの中のDNSサーバでこれらを調べることができる限り、ルータIDのためのアドレス空間。
Summarization rules are likely to be affected by renumbering, especially if area boundaries change.
総括規則は、特にエリアの境界が変化するなら番号を付け替えることによって、影響を受けそうです。
Special addressing techniques, such as unnumbered interfaces and physical interfaces with IP addresses in multiple subnets, may not be transparent to OSPF. Care should be exercised in their use, and their use definitely should be limited to intra-area scope.
複数のサブネットにおけるIPアドレスとの無数のインタフェースや物理インターフェースなどの特別なアドレシングのテクニックはOSPFに見え透いていないかもしれません。 注意は彼らの使用に訓練されるべきです、そして、彼らの使用は確実にイントラ領域の範囲に制限されるべきです。
If part of the renumbering motivation is the introduction of NBMA services, there can be numerous impacts on OSPF. Generally, the best way to minimize impact is to use separate subnets for each VC. By doing so, different OSPF costs can be assigned to different VCs, designated router configuration is not needed, etc.
番号を付け替える動機の一部がNBMAサービスの導入であるなら、多数の影響がOSPFにあることができます。 一般に、影響を最小にする最も良い方法は各VCに別々のサブネットを使用することです。 そうすることによって、異なったOSPFコストを異なったVCsに割り当てることができて、代表ルータ構成は必要ではありませんなど。
10.4 IS-IS
10.4 IS-IS
IP prefixes are usually associated with IS-IS area definitions. If IP prefixes change, there may be a corresponding change in area definitions.
通常、IP接頭語が関連している、-、領域指定。 IP接頭語が変化するなら、領域指定における対応する変化があるかもしれません。
10.5 IGRP and Enhanced IGRP
10.5 IGRPと高められたIGRP
When a change from IGRP to enhanced IGRP is part of a renumbering effort, the need to disable IGRP automatic route summarization needs to be considered. This is likely if classless addressing is being implemented.
IGRPから高められたIGRPまでの変化が番号を付け替える取り組みの一部であるときに、IGRPが自動ルート総括であると無効にする必要性は、考えられる必要があります。 階級のないアドレシングが実装することにされるのであるなら、これはありそうです。
Also be aware of the nuances of automatic redistribution between IGRP and EIGRP. The "autonomous system number," which need not be a true AS number but simply identifies a set of cooperating routers, must be the same on the IGRP and EIGRP processes for automatic redistribution to occur.
また、IGRPとEIGRPの間の自動再分配のニュアンスを意識してください。 「自律システム番号」(真のAS番号である必要はありませんが単に1セットの協力ルータを特定する)は、自動再分配が起こるようにIGRPとEIGRPプロセスで同じでなければなりません。
11. Exterior Routing
11. 外のルート設定
Exterior routes may be defined statically. If dynamic routing is involved, such routes are learned primarily from BGP. RIP is not infrequently used to allow ISPs to learn dynamically of new customer routes, although there are security concerns in such an approach. IGRP and EIGRP can be used to advertise external routes.
外のルートは静的に定義されるかもしれません。 ダイナミックルーティングがかかわるなら、そのようなルートは主としてBGPから学習されます。 RIPはISPがダイナミックに新しい顧客ルートを知るのを許容するのにまれに使用されません、そのようなアプローチには安全上の配慮がありますが。 外部経路の広告を出すのにIGRPとEIGRPを使用できます。
Berkowitz Informational [Page 39] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[39ページ]のRFC2072Router
Renumbering that affects BGP-speaking routers can be complex, because it can require changes not only in the BGP routers of the local Autonomous System, but also require changes in routers of other AS and in routing registries. This will require careful administrative coordination.
BGP-話しルータに影響する番号を付け替えるのは複雑である場合があります、地方のAutonomous SystemのBGPルータだけで釣り銭がいるのではなく、他のASのルータとルーティング登録に釣り銭がいもすることができるので。 これは慎重な管理的調整を必要とするでしょう。
If for no other reason than documentation, consider use of a routing policy notation [RIPE-181++] [RPSL] to describe exterior routing policies
ドキュメンテーションいいえ以外の理由で、ルーティング方針記法[RIPE-181++][RPSL]の使用が外のルーティング方針を説明すると考えてくださいなら
11.1 Routing Registries/Routing Databases
11.1 ルート設定登録/ルート設定データベース
Organizations who participate in exterior routing usually will have routing information not only in their routers, but in databases operated by registries or higher-level service providers (e.g., the Routing Arbiter).
通常、外のルーティングに参加する組織が登録か、よりハイレベルのサービスプロバイダー(例えば、ルート設定Arbiter)にそれらのルータだけではなく、データベースでルーティング情報を運用させるでしょう。
If an ISP whose previous address space came from a different provider either renumbers into a different provider's address space, or gains a recognized block of its own, there may be administrative requirements to return the previously allocated addresses. These include changes in IN-ADDR.ARPA delegation, SWIP databases, etc., and need to be coordinated with the specific registries and providers involved. Not all registries and providers have the same policies.
前のアドレス空間が異なったプロバイダーから来たISPが異なったプロバイダーのアドレス空間、または利得にそれ自身の認識されたブロックに番号を付け替えさせるなら、以前に割り当てられたアドレスを返すという管理要件があるかもしれません。 これらは、IN-ADDR.ARPA委譲、SWIPデータベースなどにおける変化を含んで、特定の登録とプロバイダーがかかわっていて調整される必要があります。 すべての登録とどんなプロバイダーにも、同じ方針がありません。
If the enterprise is a registered Autonomous System and renumbers into a different address space, route objects with old prefixes in routing registries need to be deleted and route objects with new prefixes need to be added.
企業が登録されたAutonomous Systemであり、古い接頭語で異なったアドレス空間、ルートにオブジェクトに登録が削除されるために必要とするルーティングで番号を付け替えさせるか、そして、新しい接頭語があるルートオブジェクトは、加えられる必要があります。
11.2 BGP--Own Organization
11.2BGP--自身の組織
IP addressing information can be hard-coded in several aspects of a BGP speaker. These include:
IPアドレス指定情報はBGPスピーカーのいくつかの局面で一生懸命コード化できます。 これらは:
1. Router ID
2. Peer router IP addresses
3. Advertised prefix lists
4. Route filtering rules
1. ルータID2。 同輩ルータIPアドレス3。 広告を出している接頭語は4を記載します。 ルートフィルタリング規則
Some tools exist [RtConfig] for generating policy configuration part of BGP router configuration statements from the policies specified in RIPE-181 or RPSL.
いくつかのツールが、RIPE-181かRPSLで指定された方針からのBGPルータ構成声明の方針構成部分を生成するために存在しています[RtConfig]。
Berkowitz Informational [Page 40] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[40ページ]のRFC2072Router
11.3 BGP--Other AS
11.3 BGP--もう一方
Other autonomous systems, including nonadjacent ones, can contain direct or indirect (e.g., aggregated) references to the above routing information. Tools exist that can do preliminary checking of connectivity to given external destinations [RADB].
nonadjacentものを含む他の自律システムは上記のルーティング情報の直接の、または、間接的な(例えば、集められる)参照を含むことができます。 与えられた外部の目的地[RADB]に接続性の予備の照合ができるツールが存在しています。
12. Network Management
12. ネットワークマネージメント
This section is intended to deal with those parts of network management that are intimately associated with routers, rather than a general discussion of renumbering and network management.
このセクションが親密に番号を付け替えるのとネットワークマネージメントの一般的な議論よりむしろルータに関連づけられるネットワークマネージメントのそれらの部品に対処することを意図します。
Methods used for managing routers include telnets to virtual console ports, SNMP, and TFTP. Network management scripts may contain hard- coded references to IP addresses supporting these services. In general, try to convert script references to IP addresses to DNS names.
ルータを管理するのに使用されるメソッドは仮想コンソールのポート、SNMP、およびTFTPにtelnetを含んでいます。 スクリプトが一生懸命含むかもしれないネットワークマネージメントはこれらのサービスをサポートするIPアドレスの参照をコード化しました。 一般に、IPアドレスのスクリプト参照をDNS名に変換するようにしてください。
A critical and complex problem will be converting SNMP databases, which are usually organized by IP address.
重要で複雑な問題はSNMPデータベースを変換するでしょう。(通常、データベースはIPアドレスによって組織化されます)。
12.1 Configuration Management
12.1 構成管理
Names and addresses of servers that participate in configuration management may need to change, as well as the contents of the configurations they provide. TFTP servers are commonly used here, as may be SNMP managers.
構成管理に参加するサーバの名前とアドレスは、変化する必要があるかもしれません、それらが提供する構成のコンテンツと同様に。 SNMPマネージャが使用するかもしれないように、TFTPサーバはここで一般的に使用されます。
12.2 Name Resolution/Directory Services
12.2 名前解決/ディレクトリサービス
During renumbering, it will probably be useful to assign DNS names to interfaces, virtual interfaces, and router IDs of routers. Remember that it is perfectly acceptable to identify internal interfaces with RFC1597/RFC1918 private addresses, as long as firewalling or other filtering prevent these addresses to be propagated outside the enterprise.
番号を付け替える間、ルータのインタフェース、仮想インターフェース、およびルータIDへの名前をDNSに割り当てるのはたぶん役に立ちます。 内部のインタフェースをRFC1597/RFC1918プライベート・アドレスと同一視するのが完全に許容できるのを覚えていてください、そして、フィルターにかけて、firewallingしているか、または他である限り、これらのアドレスを防いで、企業の外で伝播されてください。
If dynamic addressing is used, dynamic DNS should be considered. Since this is under development, it may be appropriate to consider proprietary means to learn what addresses have been assigned dynamically, so they can be pinged or otherwise managed.
ダイナミックなアドレシングが使用されているなら、ダイナミックなDNSは考えられるべきです。 これが開発中であるので、ダイナミックにどんなアドレスを割り当ててあるかを学ぶ独占手段を考えるのはそれらに確認するか、または別の方法で対処できるように適切であるかもしれません。
Also remember that some name resolution may be done by static tables that are part of router configurations. Changing the DNS entries, and even restarting the routers, will not change these.
また、ルータ構成の一部である静的なテーブルで何らかの名前解決をしたかもしれないのを覚えていてください。 DNSエントリーを変えて、ルータを再開する場合、これらは変化しないでしょう。
Berkowitz Informational [Page 41] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[41ページ]のRFC2072Router
12.3 Fault Management
12.3 障害管理
Abnormal condition indications can be sent to several places that may have hard-coded IP addresses, such as SNMP trap servers, syslogd servers, etc.
SNMP罠サーバ、syslogdサーバなどの一生懸命コード化されたIPアドレスを持っているかもしれない処々方々に異常な状態指摘を送ることができます。
It should be remembered that large bursts of transient errors may be caused as part of address cutover in renumbering. Be aware that these bursts might overrun the capacity of logging files, and conceivably cause loss of auditing information. Consider enlarging files or otherwise protecting them during cutover.
一時的エラーの大きい炸裂が番号を付け替えることにおけるアドレスカットオーバの一部として引き起こされたかもしれないのが覚えていられるべきです。 これらの炸裂が伐採ファイルの容量をオーバランさせて、多分監査の情報の損失をもたらすかもしれないのを意識してください。 カットオーバの間、ファイルを拡大するか、またはそうでなければ、それらを保護すると考えてください。
12.4 Performance Management
12.4 パフォーマンス管理
Performance information can be recorded in routers themselves, and retrieved by network management scripts. Other performance information may be sent to syslogd, or be kept in SNMP data bases.
パフォーマンス情報をルータ自体に記録して、ネットワークマネージメントスクリプトで検索できます。 他の性能情報をsyslogdに送るか、またはSNMPデータベースの中に保つかもしれません。
Load-generating scripts used for performance testing may contain hard-coded IP addresses. Look carefully for scripts that contain executable code for generating ranges of test addresses. Such scripts may, at first examination, not appear to contain explicit IP addresses. They may, for example, contain a "seed" address used with an incrementing loop.
性能テストに使用される負荷を生成するスクリプトは一生懸命コード化されたIPアドレスを含むかもしれません。 テストアドレスの範囲を生成するために慎重に実行コードを含むスクリプトを探してください。 最初に、試験では、そのようなスクリプトは明白なIPアドレスを含むように見えないかもしれません。 例えば、それらは増加している輪と共に使用される「種子」アドレスを含むかもしれません。
12.5 Accounting Management
12.5 会計管理
Accounting records may be sent periodically to syslogd or as SNMP traps. Alternatively, the SNMP manager or other management applications may periodically poll accounting information in routers, and thus contain hard-coded IP addresses.
syslogdかSNMPが捕らえるとき、定期的に会計帳簿を送るかもしれません。 あるいはまた、SNMPマネージャか他の管理アプリケーションが、定期的にルータにおける課金情報に投票して、その結果、一生懸命コード化されたIPアドレスを含むかもしれません。
12.6 Security Management
12.6 セキュリティ管理
Security management includes logging, authentication, filtering, and access control. Routers can have hard-coded references to servers for any of these functions.
経営者側が登録するのを含むセキュリティ、認証、フィルタリング、およびアクセスは制御されます。 ルータはサーバのこれらの機能のどれかの一生懸命コード化された参照を持つことができます。
In addition, routers commonly will contain filters containing security-related rules. These rules are apt to need explicit recoding, since they tend to operate on a bit level.
さらに、ルータは一般的にセキュリティ関連の規則を含むフィルタを含むでしょう。 これらの規則は少し平らな状態で傾向があるのによる作動する明白な再コード化を必要とする傾向があります。
Some authentication servers and filtering mechanisms may dynamically update router filters.
いくつかの認証サーバとメカニズムをフィルターにかけると、ルータフィルタはダイナミックにアップデートされるかもしれません。
Berkowitz Informational [Page 42] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[42ページ]のRFC2072Router
12.7 Time Service
12.7 時間指定サービス
Hard-coded references to NTP servers should be changed to DNS when possible, and renumbered otherwise.
可能であるときに、DNSに変えます。別の方法で、NTPサーバの一生懸命コード化された参照は、番号を付け替えられるべきです。
13. IP and Protocol Encapsulation
13. IPとプロトコルカプセル化
IP packets can be routed to provide connectivity for non-IP protocols, or for IP traffic with addresses not consistent with the active routing environment. Such encapsulating functions usually have a tunneling model, where an end-to-end connection between two "passenger" protocol addresses is mapped to a pair of endpoint IP addresses. Generic Route Encapsulation is a representative means of such tunneling [RFC1701, RFC1702].
非IPプロトコル、またはIPトラフィックのための接続性をアクティブなルーティング環境と一致していないアドレスに提供するためにIPパケットを発送できます。 そのような要約機能には、通常、トンネリングモデルがあります。そこでは、2つの「乗客」プロトコルアドレスの間の終わりから終わりへの関係が1組の終点IPアドレスに写像されます。 ジェネリックRoute Encapsulationはそのようなトンネリング[RFC1701、RFC1702]の代表している手段です。
13.1 Present
13.1 プレゼント
Renumbering of the primary IP environment often does not mean that passenger protocol addresses need to change. In fact, such protocol encapsulation for IP traffic may be a very viable method for handling legacy systems that cannot easily be renumbered. For this legacy case, the legacy IP addresses can be tunneled over the renumbered routing environment.
プライマリIP環境の番号を付け替えるのは、乗客プロトコルアドレスが、変化する必要をしばしば意味するというわけではありません。 事実上、IPトラフィックのためのそのようなプロトコルカプセル化は容易に番号を付け替えられることができない取り扱いレガシーシステムのための非常に実行可能なメソッドであるかもしれません。 このレガシーケースにおいて、番号を付け替えているルーティング環境の上でレガシーIPアドレスにトンネルを堀ることができます。
Also note that IP may be a passenger protocol over non-IP systems using IPX, AppleTalk, etc.
また、IPがIPX、AppleTalkなどを使用する非IPシステムの上の乗客プロトコルであるかもしれないことに注意してください。
13.2 Future
13.2 未来
Tunneling mechanisms are fundamental for the planned transition of IPv4 to IPv6. As part of an IPv4 renumbering effort, it may be worthwhile to reserve some address space for future IPv6 tunnels.
IPv6へのIPv4の計画された変遷に、トンネリングメカニズムは基本的です。 取り組みに番号を付け替えさせるIPv4の一部として、将来のIPv6トンネルへの何らかのアドレス空間を予約する価値があるかもしれません。
While there are clear and immediate needs for IPv4 renumbering, there may be cases where IPv4 renumbering can be deferred for some months or years. If the effort is deferred, it may be prudent at that time to consider if available IPv6 implementations or tunneling mechanisms form viable alternatives to IPv4 renumbering. It might be appropriate to renumber certain parts of the existing IPv4 space directly into the IPv6 space. Tools for this purpose are experimental at the time this document was written.
IPv4の番号を付け替えることの明確で即座の必要性がある間、ケースが数何カ月も年間IPv4の番号を付け替えることを延期できるところにあるかもしれません。 取り組みが延期されるなら、利用可能なIPv6実装かトンネリングメカニズムがIPv4の番号を付け替えるのに実行可能な代案を形成するかどうか考えるのはその時、慎重であるかもしれません。 既存のIPv4スペースのある地域に直接IPv6スペースに番号を付け替えさせるのは適切であるかもしれません。 このドキュメントが書かれたとき、ツールはこのために実験的です。
Berkowitz Informational [Page 43] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[43ページ]のRFC2072Router
14. Security Considerations
14. セキュリティ問題
Routers are critical parts of firewalls, and are otherwise used for security enforcement. Configuration errors made during renumbering can expose systems to malicious intruders, or deny service to authorized users. The most critical area of concern is that filters are configured properly for old and new address, but other numbers also can impact security, such as pointers to authentication, logging, and DNS servers.
ファイアウォールの重要な部分です。別の方法で、ルータは、セキュリティー施行に使用されます。 番号を付け替えている間にされた構成誤りは、悪意がある侵入者にシステムを暴露する場合があるか、または認定ユーザに対するサービスを否定する場合があります。 関心の最も重要な領域はフィルタが古くて新しいアドレスのために適切に構成されますが、他の数もセキュリティに影響を与えることができるということです、認証への指針や、伐採や、DNSサーバなどのように。
During a renumbering operation, it may be appropriate to introduce authentication mechanisms for routing updates.
番号を付け替える操作の間、ルーティングアップデートのために認証機構を紹介するのは適切であるかもしれません。
15. Planning and Implementing the Renumbering
15. 番号を付け替えることを計画して、実装します。
Much of the effort in renumbering will be on platforms other than routers. Nevertheless, routers are a key part of any renumbering effort.
番号を付け替えることにおける、取り組みの多くがルータ以外のプラットホームにあるでしょう。 それにもかかわらず、ルータはどんな番号を付け替える取り組みの主要な部分です。
Step 1--Inventory of affected addresses and names.
1を踏んでください--影響を受けるアドレスと名前の目録。
Step 2--Design any needed topological changes. If temporary address
space, network address translators, etc., are needed, obtain
them.
ステップ2--あらゆる必要な位相的な変化を設計してください。 仮の住所スペース、ネットワークアドレス変換機構などが必要であるなら、彼らを得てください。
Step 3--Install and test changes to make the network more
renumbering-friendly. These include making maximum use of
default routes and summarization, while minimizing address-
based references to servers.
ステップ3--変化をインストールして、テストして、ネットワークをより番号を付け替えるに優しくしてください。 これらは、アドレス基底付き参照をサーバに最小にしている間、デフォルトの最大の使用をルートと総括にするのを含んでいます。
Step 4--Plan the actual renumbering. Should it be phased or total?
Can it be done in a series of stub network renumberings,
possibly with secondary addresses on core routers? Is NAT
appropriate? If so, how is it to be used?
ステップ4--実際の番号を付け替えることを計画してください。 それは、段階的ですか、総であるべきですか? 一連のスタッブネットワーク「再-番号の付け方」でことによるとコアルータに関するセカンダリアドレスでそれができますか? NATは適切ですか? そうだとすれば、それによってどのように使用されることになっていますか?
What is your plan of retreat if major problems develop?
Make a distinction between problems in the routing system
and unforeseen problems in hosts affected by renumbering.
大した問題が展開するなら、あなたの後退の地図は何ですか? 番号を付け替えることによって、ルーティングシステムの問題とホストの予期せぬ問題の区別を影響を受けさせてください。
Step 5--Take final backups.
ステップ5--最終的なバックアップを取ってください。
Berkowitz Informational [Page 44] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[44ページ]のRFC2072Router
Step 6--Cut over addresses and names, or begin coexistence.
ステップ6--アドレスと名前をカットオーバーするか、または共存を始めてください。
Make needed DNS and firewall changes.
Restart routers and servers as appropriate.
Clear caches as appropriate.
Remember static name definitions in routers may not be affected
by DNS changes.
Coordinate changes with affected external organizations (e.g.,
ISPs, business partners, routing registries)
必要なDNSとファイアウォール変更を行ってください。 適宜ルータとサーバを再開してください。 適宜キャッシュをクリアしてください。 ルータとの静的な名前定義がDNS変化で影響を受けなかったかもしれないのを覚えていてください。 影響を受ける外部の組織と共に変化を調整してください。(例えば、ISP、ビジネスパートナー、ルーティング登録)
Step 6--Document what isn't already documented. Make notes to help
the person who next needs to renumber. Share experience with
the PIER working group or other appropriate organizations.
ステップ6--既に記録されないことを記録してください。 メモを作って、次が番号を付け替える必要がある人を助けてください。 PIERワーキンググループか他の適切な組織の経験を共有してください。
15.1 Applying Changes
15.1 変化を適用すること。
Renumbering changes should be introduced with care into operational networks. For changes to take effect, it is likely that at least interfaces and probably routers will have to be restarted. The sequence in which changes are applied must be carefully thought out, to avoid loss of connectivity, routing loops, etc., while the renumbering is in process.
変化に番号を付け替えさせるのは慎重に操作上のネットワークに取り入れられるべきです。 変化が効くように、少なくともインタフェースとたぶんルータは再開されなければならなそうでしょう。 接続性、ルーティング輪などの損失を避けるために、慎重に、変化が適用されている系列を考え抜かなければなりません、番号を付け替えることがプロセスにありますが。
See case studies presented to the PIER Working Group for examples of operational renumbering experience. Organizations that have undergone renumbering have had to pay careful attention to informing users of possible outages, coordinating changes among multiple sites, etc. It will be an organization-specific decision whether router renumbering can be implemented incrementally or must be done in a major "flag day" conversion.
ケーススタディが操作上の番号を付け替える経験に関する例のためにPIER作業部会に提示されるのを見てください。 番号を付け替えることを受けた組織は可能な供給停止についてユーザに知らせることに関する慎重な注意を向けなければなりませんでした、複数のサイトなどの中で変化を調整して それはルータの番号を付け替えることを増加して実装することができなければならないか、または主要な「旗の日」変換でしなければならないかという組織特有の決定でしょう。
Before making significant changes, TAKE BACKUPS FIRST of all router configuration files, DNS zone files, and other information that documents your present environment.
以前、著しい変化、すべてのルータ構成ファイル、DNSゾーンファイル、および他の情報のTAKE BACKUPS FIRSTをそれにすると、あなたの現在の環境は記録されます。
15.2 Configuration Control
15.2 構成管理
Operationally, an important part of renumbering and continued numbering maintenance is not to rely on local router interfaces, either command language interpreter, menu-based, or graphic, for the more sophisticated aspects of configuration, but to do primary configuration (and changes) on an appropriate workstation. On a workstation or other general-purpose computer, configuration files can be edited, listed, processed with macro processors and other tools, etc. Source code control tools can be used on the router configuration files.
番号を付け替えていて継続的な付番メインテナンスの重要な部分は操作上、ローカルルータインタフェース、メニューベースの、または、グラフィックのコマンド言語インタプリタに構成の、より洗練された局面に頼るのではなく、適切なワークステーションの上でプライマリ構成(そして、変化)をすることです。 ワークステーションか他の汎用計算機の上では、構成ファイルは編集されて、記載されて、マクロプロセッサで処理されて他のツールであるかもしれませんなど。 ルータ構成ファイルでソースコードコントロールツールを使用できます。
Berkowitz Informational [Page 45] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[45ページ]のRFC2072Router
Once the configuration file is defined for a router, mechanisms for loading it vary with the specific router implementation. In general, these will include a file transfer using FTP or TFTP into a configuration file on the router, SNMP SET commands, or logging in to the router as a remote console and using a terminal emulator to upload the new configuration under the router's interactive configuration mode. Original acquisition of legacy configuration files is the inverse of this process.
構成ファイルがルータのためにいったん定義されると、それをロードするためのメカニズムは特定のルータ実装で異なります。 一般に、これらは、ルータ、SNMP SETコマンド、リモートコンソールとしてルータにログインして、またはルータの対話的な構成モードの下で新しい構成をアップロードするのに端末エミュレータを使用することに関する構成ファイルにFTPかTFTPを使用することでファイル転送を含むでしょう。 レガシー構成ファイルのオリジナルの獲得はこのプロセスの逆です。
15.3 Avoiding Instability
15.3 不安定性を避けること。
Routing processes tend towards instability when they suddenly need to handle very large numbers of updates, as might occur if a "flag day" cutover is not carefully planned. A general guideline is to make changes in only one part of a routing hierarchy at a time.
突然非常に多くのアップデートを扱う必要があると、ルート設定プロセスは不安定性の傾向があります、「旗の日」カットオーバが慎重に計画されていないなら起こるかもしれないとき。 一般的ガイドラインは一度にルーティング階層構造の一部だけでの変更を行うことです。
Routing system design should be hierarchical in all but the smallest domains. While OSPF and IS-IS have explicit area-based hierarchical models, hierarchical principles can be used with most implementations of modern routing protocols. Hierarchy can be imposed on a protocol such as RIPv2 or EIGRP by judicious use of route aggregation, routing advertisement filtering, etc.
ルート設定システム設計は全部で階層的な、しかし、最も小さいドメインであるべきです。 そして、OSPFである、-、明白な領域ベースの階層的なモデル、階層的な原則は現代のルーティング・プロトコルのほとんどの実装と共に使用されたはずですか? ルート集合、ルーティング広告フィルタリングなどの賢明な使用でRIPv2かEIGRPなどのプロトコルに階層構造を課すことができます。
Respecting a hierarchical model during renumbering means such things as renumbering a "stub" part of the routing domain and letting that part stabilize before changing other parts. Alternatively, it may be reasonable to add new numbers to the backbone, allowing it to converge, renumbering stubs, and then removing old numbers from the backbone. Obviously, these guidelines are most practical when there is a distinct old and new address space without overlaps. If a block of addresses must simply be reassigned, some loss of service must be expected.
他の部品を変える前に、「スタッブ」に番号を付け替えさせるようなものが分ける経路ドメインの手段に番号を付け替えさせている間、階層的なモデルを尊敬して、その部分をさせるのは安定しています。 あるいはまた、新しい数をバックボーンに加えるのは妥当であるかもしれません、それが一点に集まるのを許容して、バックボーンからスタッブに番号を付け替えさせて、次に、古い数を取り除いて。 異なった古くて新しいアドレス空間がオーバラップなしであるとき、明らかに、これらのガイドラインは最も実際的です。 単に1ブロックのアドレスを再選任しなければならないなら、いくらかのサービスの損失を予想しなければなりません。
16. Acknowledgments
16. 承認
Thanks to Jim Bound, Paul Ferguson, Geert Jan de Groot, Roger Fajman, Matt Holdrege, Dorian Kim, Walt Lazear, Eliot Lear, Will Leland, and Bill Manning for advice and comments.
アドバイスとコメントをジムBound、ポールファーガソン、ヘールト・1月のdeグルート、ロジャーFajman、マットHoldrege、ドリアン・キム、ウォルト・ラジア、エリオットリア、ウィル・リーランド、およびビル・マニングをありがとうございます。
Berkowitz Informational [Page 46] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[46ページ]のRFC2072Router
17. References
17. 参照
[RFC2071] Ferguson, P., and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[RFC2071] ファーガソン、P.、およびH.バーコウィッツ、「番号を付け替える概要をネットワークでつないでください」 「私はなぜそれととにかくそれであるものが欲しいでしょうか?」、RFC2071、1997年1月。
[Cansever] Cansever, D., "NHRP Protocol Applicability Statement", Work in Progress.
D.、「NHRPプロトコル適用性証明」という[Cansever]Canseverは進行中で働いています。
[Katz] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress.
[キャッツ]LucianiとJ.とキャッツとD.とPiscitello、D.とコール、B.、「次のNBMAは解決プロトコル(NHRP)を飛び越す」処理中の作業。
[Hubbard] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC 2050, November 1996.
[ハバード] ハバードとK.とKostersとM.とコンラッドとD.とKarrenberg、D.とJ.ポステル、「インターネット登録IP配分ガイドライン」、BCP12、RFC2050、1996年11月。
[RFC1631] Egevang,, K., and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[RFC1631]Egevang、K.、およびP.フランシス、「IPネットワークアドレス変換機構(NAT)」(RFC1631)5月1994番目
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G-J., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、マスコウィッツ、R.、Karrenberg、D.、deグルート、G-J.とE.リア、「個人的なインターネットのためのアドレス配分」RFC1918(1996年2月)。
[RFC1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[RFC1900] 大工、B.とY.Rekhter、「番号を付け替えるのは仕事を必要とである」RFC1900、1996年2月。
[RPS] Alaettinoglu, C., Bates, T., Gerich, E., Terpstra, M., and C. Villamizer, "Routing Policy Specification Language", Work in Progress.
[RPS]AlaettinogluとC.とベイツとT.とGerichとE.とテルプストラ、M.とC.Villamizer、「ルート設定方針仕様言語」は進行中で働いています。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[Rigney] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997.
[Rigney] Rigney、C.、ルーベン、A.、シンプソン、W.、およびS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2058(1997年1月)。
[Carpenter] Message to PIER Mailing List, see PIER Archives
[大工仕事をします] PIER Mailing Listへ通信してください、そして、PIERアーカイブを見てください。
[Lear] Message to PIER Mailing List, see PIER Archives
[リア] PIER Mailing Listへ通信してください、そして、PIERアーカイブを見てください。
[deGroot] Message to PIER Mailing List, see PIER Archives
[deGroot] PIER Mailing Listへ通信してください、そして、PIERアーカイブを見てください。
[Wobus] "DHCP FAQ Memo", http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
[Wobus]「DHCP FAQメモ」、 http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
Berkowitz Informational [Page 47] RFC 2072 Router Renumbering Guide January 1997
ガイド1997年1月に番号を付け替えさせるバーコウィッツ情報[47ページ]のRFC2072Router
18. Author's Address
18. 作者のアドレス
Howard C. Berkowitz PSC International 1600 Spring Hill Road, Suite 310 Vienna VA 22182
スイート310ウィーンヴァージニア ハワードC.バーコウィッツPSC国際1600スプリングヒル道路、22182
Phone: +1 703 998 5819 EMail: hcb@clark.net
以下に電話をしてください。 +1 5819年の703 998メール: hcb@clark.net
Berkowitz Informational [Page 48]
バーコウィッツInformationalです。[48ページ]
一覧
スポンサーリンク
