RFC1879 日本語訳

Network Working Group                                 B. Manning, Editor
Request for Comments: 1879                                           ISI
Category: Informational                                     January 1996

ワーキンググループのB.マニング、コメントを求めるエディタ要求をネットワークでつないでください: 1879年のISIカテゴリ: 情報の1996年1月

                       Class A Subnet Experiment
                      Results and Recommendations

クラスは、サブネット実験結果と推薦です。

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.

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

Discussion/Purpose

議論/目的

   This memo documents some experiences with the RFC 1797 [1] subnet A
   experiment (performed by the Net39 Test Group (see credits)) and
   provides a number of recommendations on future direction for both the
   Internet Registries and the Operations community.

このメモは、RFC1797[1]サブネットA実験(Net39 Test Group(クレジットを見る)によって実行される)でいくつかの経験を記録して、将来の方向でインターネットRegistriesとOperations共同体の両方に多くの推薦を提供します。

   Not all proposed experiments in RFC 1797 were done. Only the "case
   one" type delegations were made.  Additional experimentation was done
   within the DNS service, by supporting a root nameserver and the
   primary for the domain from within the subnetted address space.  In
   addition, testing was done on classless delegation [2].

RFC1797でのすべて提案されなかった実験をしました。 「ケース1」タイプ委譲だけが作られました。 DNSサービスの中で追加実験をしました、中からドメインへの根のネームサーバと予備選挙に「副-網で覆」われたアドレス空間をサポートすることによって。 さらに、階級のない委譲[2]ではテストしたこと。

   Internet Services offered over the RFC 1797 experiment were:

RFC1797実験の上に提供されたインターネットのサービスは以下の通りでした。

         Finger
         HTTP
         Telnet
         FTP server/client
         Gopher
         kerberos
         lpr (and its ilk)
         X
         DNS

指のHTTP Telnet FTPサーバ/クライアントゴーファーkerberos lpr(そして、一族)X DNS

   F.Root-Servers.Net, a root name server had an interface defined as
   part of the RFC 1797 experiment.  Attached is a report fragment on
   it's performance: "My root server has processed 400,000,000 queries
   in the last 38 days, and well over half of them were to the temporary
   39.13.229.241 address (note that I retained the old 192.5.5.241
   address since I knew a lot of folks would not update their root.cache
   files and I didn't want to create a black hole.)" - Paul Vixie

F.根-Servers.Net、根のネームサーバで、RFC1797実験の一部とインタフェースを定義しました。 それの性能のレポート断片を取り付けます: 「私のルートサーバーはここ38日間で4億の質問を処理しました、そして、半分のそれらのかなり上に、一時的な39.13には.241が扱う.229が(私が、多くの人々が彼らのroot.cache filesをアップデートしないのを知っていたので.241が演説する人.5と私がブラックホールを作成したくなかった古い192.5を保有したことに注意してください。)ありました」--ポール、Vixie

Manning                      Informational                      [Page 1]

RFC 1879               Class A Subnet Experiment            January 1996

サブネット実験1996年1月に情報[1ページ]のRFC1879のクラスを配置します。

   Initial predictions [3] seemed to indicate that the safest path for
   an ISP that participates in such a routing system is to have -all- of
   the ISP clients be either:

持つためにそのようなルーティングシステムに参加するISPのための最も安全な経路がそうであるという[3]が示すように思えた予測に頭文字をつける、-、オール、ISPクライアントでは、どちらかになってください:

                a) singly connected to one upstream ISP
        OR
                b) running a classless interior routing protocol

単独で1上流のISP OR bに関連づけられたa)) 階級のない内部のルーティング・プロトコルを実行すること。

   It is also noted that a network with default route may not notice it
   has potential routing problems until it starts using subnets of
   traditional A's internally.

また、デフォルトルートがあるネットワークが、それには内部的に伝統的なAのもののサブネットを使用し始めるまで潜在的ルーティング問題があるのに気付かないかもしれないことに注意されます。

Problems & Solutions

問題とソリューション

Operations

操作

   There were initial problems in at least one RIPE181 [4]
   implementation.  It is clear that operators need to register in the
   Internet Routing Registry (IRR) all active aggregates and delegations
   for any given prefix.  Additionally, there need to be methods for
   determining who is authoritative for announcing any given prefix.

少なくとも1つのRIPE181[4]実装には初期の問題がありました。 オペレータが、どんな与えられた接頭語のためにもインターネットルート設定Registry(IRR)にすべてのアクティブな集合と委譲を示す必要があるのは、明確です。 さらに、何か与えられた接頭語を発表するのに、だれが正式であるかを決定するためのメソッドがあるのが必要です。

   It is expected that problems identified within the confines of this
   experiment are applicable to some RFC 1597 prefixes or any "natural"
   class "A" space.

問題がこの実験の境界がRFC1597が前に置くいくつかに適切であるか、またはいずれも「自然である」というクラスの中でスペースを特定したと予想されます。

   Use of traceroute (LSRR) was critical for network troubleshooting
   during this experiment. In current cisco IOS, coding the following
   statement will disable LSRR and therefore inhibit cross-provider
   troubleshooting:

ネットワークトラブルシューティングに、トレースルート(LSRR)の使用はこの実験の間、重要でした。 現在のコクチマスIOSでは、以下の声明をコード化するのは、LSRRを無効にして、したがって、交差しているプロバイダーが障害調査されるのを禁止するでしょう:

                no ip source-route

ip送信元経路がありません。

   We recommend that this statement -NOT- be placed in active ISP cisco
   configurations.

私たちは、これが声明してないことを勧めます。アクティブなISPコクチマス構成に置かれます。

   In general, there are serious weaknesses in the Inter-Provider
   cooperation model and resolution of these problems is outside the
   scope of this document. Perhaps the IEPG or any/all of the national
   or continental operations bodies [5] will take this as an action item
   for the continued health and viability of the Internet.

一般に、Inter-プロバイダー協力モデルには重大な弱点があります、そして、このドキュメントの範囲の外にこれらの問題の解決があります。 恐らく国家の、または、大陸の操作本体[5]のすべてが望んでいるIEPGかどんな/もインターネットの長引く健康と生存力のための宿題としてこれをみなします。

Manning                      Informational                      [Page 2]

RFC 1879               Class A Subnet Experiment            January 1996

サブネット実験1996年1月に情報[2ページ]のRFC1879のクラスを配置します。

Routing

ルート設定

   A classic cisco configuration that has the following statements

以下の声明がある古典的なコクチマス構成

                ip route 39.1.28.0 255.255.255.0
                router bgp 64000
                redistribute static

ipルート39.1.28.0 255.255.255.0ルータbgp64000は静電気を再配付します。

   will, by default, promote any classful subnet route to a full
   classful route (supernet routes will be left alone).  This behaviour
   can be changed in at least the following two ways:

デフォルトで、どんなclassfulサブネットルートも完全なclassfulルートに促進するでしょう(supernetルートは放っておかれるでしょう)。 このふるまいは少なくとも以下で2つの方法に変わることができます:

        1:
                ip route 39.1.28.0 255.255.255.0
                router bgp 64000
                no auto-summary
                redistribute static

1: ipは静的に39.1.28.0 255.255 どんな自動概要も再配付しない.255.0ルータbgp64000を発送します。

        2:
                ip route 39.1.28.0 255.255.255.0
                router bgp 64000
                network 39.1.28.0 mask 255.255.255.0
                redistribute static route-map static-bgp
                ....
                access-list 98 deny 39.1.28.0 0.255.255.255
                access-list 98 permit any
                ....
                route-map static-bgp
                match ip address 98

2: .0がマスクをかけるipルート39.1.28.0 255.255.255.0ルータbgp64000ネットワーク39.1.28、255.255、.255、.0、静的にbgpでスタティックルート地図を再配付してください…、アクセスリスト、98は98が可能にする39.1.28.0 0.255.255.255アクセスリストに対していずれも否定します… 静的なbgpマッチipアドレス98をルートで写像してください。

   Users of cisco gear currently need to code the following two
   statements:

コクチマスギヤのユーザは、現在、以下の2つの声明をコード化する必要があります:

                ip classless
                ip subnet-zero

ipの階級のないipサブネット-ゼロ

   The implication of the first directive is that it eliminates the idea
   that if you know how to talk to a subnet of a network, you know how
   to talk to ALL of the network.

最初の指示の含意はネットワークのサブネットと話す方法を知っているなら、あなたがネットワークのすべてと話す方法を知っているという考えを排除するということです。

   The second is needed since it is no longer clear where the all-ones
   or all-zeros networks are [6].

オールものかオールゼロネットワークがどこの[6]であるかがもう明確でないので、2番目が必要です。

   Other infrastructure gear exhibited similar or worse behaviour.
   Equipment that depends on use of a classful routing protocol, such a
   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

他のインフラストラクチャギヤは同様の、または、より悪いふるまいを示しました。 classfulルーティング・プロトコルの使用による設備、そのようなRIPv1はmisconfigurationの傾向があります。 テストされた例は、現在のAscendとリビングストンギヤです。(そのギヤはデフォルト/唯一のルーティング・プロトコルとしてRIPv1を使用し続けています)。 RIPv1使用は集合を作成するでしょう。

Manning                      Informational                      [Page 3]

RFC 1879               Class A Subnet Experiment            January 1996

サブネット実験1996年1月に情報[3ページ]のRFC1879のクラスを配置します。

   announcement.

発表。

   This pernicious use of this classful IGP was shown to impact
   otherwise capable systems.  When attempting to communicate between an
   Ascend and a cisco the promotion problem identified above, was
   manifest. The problem turned out to be that a classful IGP (RIPv1)
   was being used between the Ascends and ciscos. The Ascend was told to
   announce 39.1.28/24, but since RIPv1 can't do this, the Ascend
   instead sent 39/8.  We note that RIPv1, as with all classful IGPs
   should be considered historic.

このclassful IGPのこの有害な使用はAscendとコクチマスの間で交信するのを試みながらそうでなければ、できるシステムいつに影響を与えるかために、上で特定された販売促進問題が明白であることが示されました。 問題はclassful IGP(RIPv1)がAscendsとコクチマスの間で使用されていたということであると判明しました。 AscendはRIPv1がこれができないので39.1に.28/24を発表するために、Ascendが代わりに39/8を送ったと言われました。 classful IGPsがすべてで歴史的であると考えられるべきであるとき、私たちはそのRIPv1に注意します。

   This validates the predictions discussed in [3].

これは[3]で議論した予測を有効にします。

Cisco Specific Examples

コクチマスの特定の例

   There are actually three ways to solve the unintended aggregation
   problem, as described with current cisco IOS.  Which of them applies
   will depend on what software version is in the router. Workarounds
   can be implemented for ancient (e.g., 8.X) version software.

実際に、故意でない集計の問題を解決する3つの方法が現在のコクチマスIOSと共に説明されるようにあります。 それらのどれが適用するかはルータにはどんなソフトウェアバージョンがあるかによるでしょう。 古来(例えば、8.X)のバージョンソフトウェアのために回避策を実装することができます。

        o Preferred solution: turn on "ip classless" in the
          routers and use a default route inside the AS.
          The "ip classless" command prevents the existence of
          a single "subnet" route from blocking access via the
          default route to other subnets of the same old-style network.
          Default only works with single-homed ISPs.

o 都合のよいソリューション: ルータで「ip階級がありません、な」状態でつけてください、そして、ASの中でデフォルトルートを使用してください。 「ip階級のない」コマンドは、ただ一つの「サブネット」ルートの存在が同じ古いスタイルネットワークの他のサブネットへのデフォルトルートでアクセスを妨げるのを防ぎます。 デフォルトが働いているだけである、シングル家へ帰る、ISP。

        o Workaround for 9.1 or later software where the
          "ip classless" command is not available: install a
          "default network route" like this:
          "ip route 39.0.0.0 255.0.0.0 <next-hop>" along the axis
          the default route would normally take.  It appears
          an ISP can utilize the "recursive route lookups" so
          the "next-hop" may not actually need to be a directly
          connected neighbour -- the internal router can e.g.,
          point to a loopback interface on the border router.
          This can become "really uncomfortably messy" and it may
          be necessary to use a distribute-list to prevent
          the announcement of the shorter mask.

o 「ip階級のない」コマンドが利用可能でない9.1のための回避策か後のソフトウェア: こののように「デフォルトネットワークルート」をインストールしてください: 通常、デフォルトルートが取る軸に沿った「ipルート39.0.0.0 255.0.0.0の<の次のホップの>。」 ISPが「再帰的なルートルックアップ」を利用できるので「次のホップ」が、実際に直接接続された隣人である必要でないかもしれないように、見えます--内部のルータは示すことができます、例えば、境界ルータにループバックインタフェースを示してください。 これは「本当に不愉快に乱雑に」なることができます、そして、より短いマスクの発表を防ぐためにリストを分配しているaを使用するのが必要であるかもしれません。

        o Workaround for 9.0 or older software: create a
          "default subnet route": "ip route 39.x.y.0 <next-hop>"
          combined with "ip default-network 39.x.y.0", otherwise
          as the 9.1 fix.

o 9.0のための回避策か、より古いソフトウェア: 「デフォルトサブネットルート」を作成してください: 「ipルートの39.x. y.0の<の次のホップの>」は「そうでなければ、9.1フィックスとしてのipデフォルトネットワーク39.x. y.0"」に結合しました。

   Both of the latter solutions rely on manual configuration, and in the
   long run these will be impossible to maintain.  In some topologies
   the use of manual configuration can be a problem (e.g., if there is

後者のソリューションの両方が手動の構成を当てにします、そして、維持するのは結局これらが不可能になるでしょう。 手動の構成の使用がいくらかのtopologiesでは、問題であるかもしれない、(例えば、あります。

Manning                      Informational                      [Page 4]

RFC 1879               Class A Subnet Experiment            January 1996

サブネット実験1996年1月に情報[4ページ]のRFC1879のクラスを配置します。

   more than one possible exit point from the AS to choose from).

ASからのある可能なエキジットポイント選ぶ以上)

Recommendations:

推薦:

   The RFC 1797 experiment appears to have been a success. We believe it
   safe to start carving up "Class A" space, if the spaces are delegated
   according to normal IR conventions [7] and recommend the IANA
   consider this for future address delegations.

RFC1797実験は成功であったように見えます。 私たちは、「クラスA」スペースを分割し始めるのが安全であると信じています、空間が、正常なIRコンベンション[7]に応じて代表として派遣されて、IANAが将来のアドレス委譲のためにこれを考えることを勧めるなら。

Credits:

クレジット:

   Thanks to all the RFC 1797 participants. Particular thanks to Paul
   Vixie, Geert Jan de Groot, and the Staff of the IETF33 Terminal room.
   Other thanks to ACES, MCI, Alternet, IIJ, UUNET-Canada, Nothwestnet,
   BBN-Planet, cisco systems, RIPE, RIPE NCC, ESnet, Xlink, SURFnet,
   STUPI, Connect-AU, INBEnet, SUNET, EUnet, InterPath, VIX.COM,
   MindSpring.  Especial thanks to Suzanne Woolf for cleanup.

すべてのRFC1797関係者をありがとうございます。 ポールVixie、ヘールト・1月のdeグルートとIETF33 TerminalのStaffへの特定の感謝は同居します。 エイセス・大空の誓い、MCI、Alternet、IIJ、UUNET-カナダNothwestnet、BBN-惑星、コクチマスシステム、RIPE、RIPE NCC、ESnet、Xlink、SURFnet、STUPI、Connect-AU、INBEnet、SUNET、EUnet、InterPath、VIX.COM(MindSpring)への他の感謝。 クリーンアップのためのスザンヌ・ウルフへの特別な感謝。

References:

参照:

   [1] IANA, "Class A Subnet Experiment", RFC 1797, USC/Information
       Sciences Institute, April 1995.

[1] IANA、「サブネットが実験するクラス」、USC/情報科学が1995年4月に設けるRFC1797。

   [2] Eidnes, H., and G. J. de Groot, "Classless in-addr.arpa
       delegation", Work in Progress, SINTEF RUNIT, RIPE NCC, May 1995.

[2]Eidnes、H.、およびG.J.deグルート、「addr.arpaの階級のない委譲」、Progress、SINTEF RUNIT、RIPE NCC、1995年5月のWork。

   [3] Huston, G., "Observations on the use of Components of the Class A
       Address Space within the Internet", Work in Progress, AARnet, May
       1995.

[3] ヒューストン、G.、「インターネットの中のClass A Address SpaceのComponentsの使用の観測」、ProgressのWork、AARnet(1995年5月)。

   [4] Bates, T., et.al, "Representation of IP Routing Policies in a
       Routing Registry", RFC 1786, MCI, March 1995.

[4] ベイツ、T.、et.al、「ルート設定登録のIPルート設定方針の表現」、RFC1786、MCI、1995年3月。

   [5] http://info.ra.net/div7/ra/Ops.html, November 1995.

1995年11月の[5] http://info.ra.net/div7/ra/Ops.html 。

   [6] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
       1812, cisco systems, June 1995.

[6] ベイカー、F.、Editor、「IPバージョン4ルータのための要件」、RFC1812、コクチマスシステム、1995年6月。

   [7] Hubbard, K., Kosters, M., Conrad, D., and D. Karrenberg,
       "Internet Registry Guidelines", Work in Progress, InterNIC,
       APNIC, RIPE, November 1995.

[7] ハバード、K.、M.とコンラッド、D.とD.Karrenberg、「インターネット登録ガイドライン」というKostersは進行中で働いています、InterNIC、APNIC、熟します、1995年11月。

Manning                      Informational                      [Page 5]

RFC 1879               Class A Subnet Experiment            January 1996

サブネット実験1996年1月に情報[5ページ]のRFC1879のクラスを配置します。

Security Considerations

セキュリティ問題

   Security issues were not considered in this experiment.

安全保障問題はこの実験で考えられませんでした。

Editor's Address:

エディタのアドレス:

   Bill Manning
   Information Sciences Institute
   University of Southern California
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   USA

ビルマニング情報Sciences Institute南カリフォルニア大学4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695米国

   Phone: +1 310-822-1511 x387
   Fax:   +1 310-823-6714
   EMail: bmanning@isi.edu

以下に電話をしてください。 +1 310-822-1511 x387Fax: +1 310-823-6714 メールしてください: bmanning@isi.edu

Manning                      Informational                      [Page 6]

マニング、情報[6ページ]