IPNG用インターネットルーティングとアドレッシングの新案

広告

広告

原文

最終更新
2006-11-01T00:00:00+09:00
この記事のURI参照
https://www.7key.jp/rfc/1955/rfc1955.html#source

IPNG用インターネットルーティングとアドレッシングの新案(和訳)

最終更新
2006-11-01T00:00:00+09:00
この記事のURI参照
https://www.7key.jp/rfc/1955/rfc1955.html#translation

当文書の位置付け

   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.

当メモはインターネットコミュニティに役立つであろう情報を提供するものであり、これによって標準的なインターネット像をでっちあげようとするものではない。また、当メモは配布に関しての制限を設けていない。

概要

   This document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the big-internet@munnari.oz.au mailing list.

   This memo describes a proposal made to to the Routing and Addressing
   group [ROAD] January 1992 by Robert Hinden.  It was originally sent
   as an email message.  It proposes a medium term solution to the
   Internet's routing and addressing problems.

当文書は、RFC1550に応じてIETF IPngの範囲に提出された。当文書の発行によって、ある考えのIPngの範囲を全て受理することを示すものではない。コメントがあれば、メーリングリストbig-internet@munnari.oz.auまで。

当メモは、Robert Hinden氏によるルーティング及びアドレッシンググループ[ROAD](1992年1月)への提案が記述されている。これは電子メールメッセージとして送信されたものが元であり、インターネットにおけるルーティング及びアドレッシング問題の中期的な解決策について提案をするものである。

序論

   I would like to propose a new scheme which I believe is a good medium
   term solution to the routing and address problems of the internet.
   It has the following positive attributes:

      - No Changes to Hosts
      - No Changes to Most Routers
      - No New Routing Protocols
      - No New Internet Protocols
      - No Translation of Addresses in Packets
      - Reduces the Routing Table Size in All Routers
      - Uses the Current Internet Address Structure

私は、インターネットにおけるルーティング及びアドレス問題の中期的な解決策と思われる新案を提案したい。提案は以下の肯定的となり得る側面をもつ:

   It is not a solution good for all time, because it does impose some
   size limits and does not support new internet services such as
   guaranteed bandwidth, delay, etc.  It does require border routers to
   do additional processing, but does not require any packet
   translation.  I believe that this scheme will give us enough time to
   put into place a long term solution (i.e. pick one or more of CLNP,
   *NAT, IDPR, IDRP, Nimrod, Unified, NewIP, etc.)

サイズ制限を行ったり帯域幅の保証や遅延などのように新しいインターネットサービスを支援したりしないので、これは常に良い解決策ではない。これは追加の処理をを境界のルータに要求するが、パケットの変換は要求しない。私は、この案が適所に長期的な解決策(つまり、CLNPの1つ以上、*NAT、IDPR、IDRP、Nimrod、Unified、NewIPなど)がなされるまでの時間稼ぎに十分な時間を与えてくれると想定する。

   This scheme is based on the ideas presented by Deborah Estrin (route
   on ADs), Martha Steenstrup (encapsulation), and probably steals from
   ideas put forward by Noel Chiappa, Van Jacobson , Ross Callon, Dave
   Oran, and everyone else in the ROAD group.

この案は、Deborah Estrin氏(AD上の経路)、Martha Steenstrup氏(カプセル化)によって示された考えに基づき、Noel Chiappa氏、Van Jacobson氏、Ross Callon氏、Dave Ora氏、ROADグループ内の他の全ての方の提言した考えから若干借用したものである。

背景

   I think that we (the ROAD group) agree that in the short term we need
   to make better use of the IP address space.  I think we also (mostly)
   agree that in the long term we need a solution that can deal with a
   very large number of end points and routes, as well as support new
   services such as guarantees of service, source selected routes, etc.
   We do not agree on any of the details of this but do agree that we
   can not figure out a long term solution before March.  We do agree
   that we should start working on a long term solution(s).

短期ではIPアドレス空間をよりよく利用する必要があることに、ROADグループは賛成するはずである。長期では、サービスや発信元選択経路などの保証のような新しいサービスを支援するのと同様に、非常に多くの終端及び経路のに対処することができる解決策が必要であることにも、ROADグループは(殆ど)賛成するはずである。我々はこの詳細のいずれにも賛成をしないが、3月までに長期に渡る解決策がなされないことには賛成するものである。我々は、長期に渡る解決策に取り組み始めるべきであるとの意見に賛成する。

   What this leaves is the need for a good medium term solution which
   can keep the Internet going until we can design and deploy a long
   term solution.  The medium term solution wants to be the most "cost
   effective".  It should buy us the most time to develop a long term
   solution and do it with as little change to the existing Internet as
   possible.

長期的な解決策を設計し展開するまでインターネットを運用しつづけることができる中期的な解決策の必要性が、これによって示されている。最も有効なコストが中期的な解決策には望まれる。そのコストで我々は長期解決策を開発する最多の時間を買うべきであり、且つ既存のインターネットへのできるだけ少ない変更でそれ行うべきである。

   I propose this scheme as a new medium term solution.

私は中期的な解決策としてこの案を提案する。

新案

   The basic idea is that inter-domain routing be done by routing on
   autonomous domains (AD).  The key is how this is done.  The mechanism
   to do this is for the border routers to encapsulate the original IP
   datagrams with another IP header.  The source and destination
   addresses in the new header (I will call it the AD-Header from here
   on) represent the source and destination ADs.

ドメイン間ルーティングが自立領域(AD)上のルーティングによってなされるということが考えの基本である。肝はこれがどのようになされているかである。これを行うメカニズムは、境界ルータが別のIPヘッダをもつカプセルにオリジナルIPデータグラムを入れることである。新しいヘッダ(ここではこれをADヘッダと呼ぶ)の発信元と宛先アドレスは、発信元及び宛先ADを表す。

   When the first (entrance) border router receives a datagram from a
   host or router without an AD-Header it looks at the source and
   destination address and does a DNS lookup to get the addresses for
   the AD-Header.  It then adds an AD-Header and forwards the
   encapsulated datagram to its proper destination AD.

最初の(入り口の)境界ルータがホスト又はルータからADヘッダのないデータグラムを受信した際、それは発信元及び宛先アドレスを見て、ADヘッダのアドレスを得るためにDNSを参照する。その後、そのデータグラムにADヘッダを加え、適切な宛先ADへカプセル化されたデータグラムを転送する。

   The border routers would compute AD routes by running a routing
   protocol between themselves.  BGP or even IS-IS or OSPF for that
   matter, would work fine.  As you will see later, they might even be
   better.

境界ルータは、それら自身の間のルーティングプロトコルの実行によってAD経路を計算する。BGPやIS-IS、OSPFのそれは素晴らしい機能である。この文書を読んだ後であればさらに素晴らしいと思えるだろう。

   The addresses I propose to use for the AD addresses are plain old IP
   addresses.  A small number of Class A and Class B addresses would be
   reserved for this purpose.  The network number of the address would
   indicate that it was an AD identifier.  The local part of the address
   would indicate the actual AD.  This would allow for many ADs to be
   supported.  For example, 10 Class-A and 10 Class-B addresses could
   accommodate (10*2^24 + 10*2^16) 168,427,500 ADs.  We clearly don't
   need that many for a long time.

ADアドレスに用いると私が提案するアドレスは、平易な古いIPアドレスである。少数のクラスA及びクラスBアドレスは、この目的のために予約されるだろう。アドレスのネットワーク番号は、AD識別子を示すだろう。アドレスのローカル部分は、実際のADを示すだろう。これは、多くのADのサポートを認めるだろう。例えば、10のクラスAと10のクラスBアドレスは、168,427,500(10*2^24 + 10*2^16)のADを提供することができる。我々は明らかに、長い間そのような数を必要としない。

   The reason why I would chose to get more than one network number to
   use to represent the AD address is I would use them to organize the
   ADs.  Let's call them commonwealths.  Each commonwealth would only
   have to know the detail of it's own ADs.

ADアドレスを表すために用いるネットワークの数を1以上とした理由は、ADを組織化するためにそれらを用いるだろうとのことからである。これを共通財産(commonwealths)と呼ぶこととする。各共通財産は、自身のADの詳細を単に知るだけである。

   Next I would have the border routers inject these AD addresses into
   the Intra-AD routing of transit ADs.  They would tell the routers
   inside of the transit AD that they (the border routers) were the
   route to each appropriate AD network.  Commonwealths that have
   multiple interconnects (probably the common case) could by the use of
   careful assignment of the AD addresses use subnetting to support
   reasonable routing between the commonwealths.  This is where OSPF or
   IS-IS might be better than BGP.  Also, IS-IS, with its ability to
   route on actual end points might be the best.

次に、境界ルータは通過ADのイントラADルーティングにこれらのADアドレスを導入させることとする。それにより、境界ルータが各適切なADネットワークへの経路であると通過ADの内部でルータに伝えるだろう。複数の相互接続をもつ共通の財産(おそらく共通の場合)は、共通の財産間の合理的なルーティングのサポートをするために、サブネッティングを用いるADアドレスの注意深い割り当てを用いることができる。これは、OSPF又はIS-ISの方が、BGPよりよいことを表す。同様に、実際の終端の経路決定能力をもつIS-ISが最も良いかもしれない。

   The motivation behind injecting the AD addresses into the Intra-AD
   routing of the transit ADs, is that the routers in these ADs can
   forward the AD-Headers without knowing that they are special.  Only
   the entrance and exit border routers are required to do anything
   different.

通過ADのイントラADルーティングにADアドレスを導入させる更なる理由は、これらAD内のルータがADヘッダを特別なものと認識することなく転送することができるからである。入り口及び出口での境界ルータのみが、通常とは異なる要求をなされることとなる。

   Finally when a AD-Header is received at the last (exit) border router
   it strips off the AD-Header and sends the datagram to the final
   destination.

最後に、ADヘッダが最後(出口)の境界ルータで受信された場合、ADヘッダを取られ、最終の宛先へデータグラムを送信する。

   This scheme is based around the idea that IP addresses are globally
   unique.  I think that we will not actually run out of IP addresses
   for a long time and that we can live with the current addressing
   until we can deploy a long term solution.

この案は、IPアドレスが世界的に一意であるとの考えに基づく。我々は実際に長い間IPアドレスを使い果たさず、長期解決策が展開されるまで現在のアドレッシングを用いることができると想定する。

   This scheme could be extended to not require globally unique IP
   address.  Effectively the combination of AD-Address and IP-Address is
   the globally unique address.  To use this scheme without globally
   unique IP-Addresses and without changing in the hosts would require a
   NAT mechanism in the border routers.  I think it would be preferable
   to change the hosts to have them do the DNS query and add the AD-
   header.  This could be the basis for the long term solution.

世界的に一意なIPアドレスを要求しないよう、この案を拡張することができるかもしれない。実際ADアドレスとIPアドレスの組は、世界的に一意なアドレスである。ホストの変更なしで且つ世界的に一意なIPアドレスなしでこのスキームを用いることは、境界ルータにNATメカニズムを要求するだろう。それらにDNSクエリを行わせ、それらにADヘッダを加えさせるホストを変更することは望ましいと思う。これは長期的な解決策の根拠となり得る。

   Another interesting aspect of this scheme is that if we were to relax
   the current architecture where one IP-Address is always in only one
   AD, to allow an IP-Address to be in more than one AD, it would
   provide a solution to the issue of allowing a IP entity to get
   service from more than one service provider.

この案の更に興味深い点として、1つのIPアドレスが常にただ1つのADとなる現在の体系を緩めれば、つまり1つのIPアドレスが1つ以上のADとなることを認めることによって、IPエンティティが1つ以上のサービスプロバイダからサービスを得られるとの解決策を提供することが挙げられる。

要求変更の要約

   The DNS needs to be extended to add an AD-Address entry for each
   name.  These will be used by the entry and exit border routers to get
   the AD-Addresses to use when building the AD-Headers.

DNSは、各名前のADアドレスエントリを加える拡張を必要とする。これらは、ADヘッダを構築する際に用いるADアドレスを得るために入り口及び出口の境界ルータによって用いられるだろう。

   Border routers need to be extended to do the DNS lookup, perform AD-
   Header encapsulation, run an inter-AD routing algorithm using AD-
   Addresses, and be able to AD-Header de-encapsulation.

境界ルータは、DNSを検査し、ADヘッダのカプセル化を行い、ADアドレスを用いてAD間ルーティングアルゴリズムを実行し、ADヘッダのカプセル化解除が可能なように拡張されなければならない。

結論

   I believe that this scheme has may advantages.  These are:

      - Only border routers and the DNS need change.  No changes are
        required in hosts or non-border routers.

      - No performance impact on datagram forwarding except at entry
        and exit border routers.

      - Only a small impact on bandwidth utilization on transit
        networks due the addition of a 20 byte IP header to each
        datagram.

      - Removes the Inter-AD routing from Intra-AD routing and as a
        result solves the routing load (table size and computation)
        problem for the foreseeable future.

      - The routing load on the border routers is manageable because
        border routers only need to know the detail of the routing
        commonwealth they are a member of.  Other commonwealths appear
        as single addresses.

      - No requirement for new routing protocols to be designed or
        deployed.

      - No translation of packets from one address scheme to another.

      - Uses the current IP addressing structure.

      - It scales well even if there is on the order of one AD per IP
        network, because the AD-Addresses can be assigned logically.

この案は利点を持つと私は信じている:

   It does have some disadvantages.  These are (at least):

      - It is not a long term solution in its initial form.

      - It assumes that the current IP-Addresses can remain globally
        unique for a long time.

不利点もある:

参照文献

   [ROAD] Gross, P., and P. Almquist, "IESG Deliberations on Routing
          and Addressing", RFC 1380, ANS, Stanford University,
          November 1992.

安全性への配慮

   Security issues are not discussed in this memo.

安全性の問題は、当メモで議論されない。

著者の連絡先

   Robert M. Hinden
   Ipsilon Networks, Inc.
   2191 East Bayshore Road
   Suite 100
   Palo Alto, CA 94303
   USA

   EMail: hinden@ipsilon.com
   Phone: +1 (415) 846-4604

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年11月01日 最終更新:2006年11月01日