RFC1671 日本語訳

Network Working Group                                       B. Carpenter
Request for Comments: 1671                                          CERN
Category: Informational                                      August 1994

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

        IPng White Paper on Transition and Other Considerations

変遷と他の問題に関するIPng白書

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

要約

   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.

RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。

Summary

概要

   This white paper outlines some general requirements for IPng in
   selected areas. It identifies the following requirements for stepwise
   transition:

この白書は選択された領域にIPngのためのいくつかの一般的な要件について概説します。 それは徐々に変遷のための以下の要件を特定します:

   A) Interworking at every stage and every layer.
   B) Header translation considered harmful
   C) Coexistence.
   D) IPv4 to IPng address mapping.
   E) Dual stack hosts.
   F) DNS.
   G) Smart dual-stack code.
   H) Smart management tools.

a) あらゆるステージとあらゆる層では、織り込みます。 B) 有害なC)であると考えられたヘッダー翻訳 共存。 D) IPngへのIPv4はマッピングを扱います。 E) デュアルスタックホスト。 F) DNS。 G) 賢いデュアルスタックコード。 H) 賢い管理ツール。

   Some remarks about phsysical and logical multicast follow, and it is
   suggested that a model of how IPng will run over ATM is needed.

phsysicalに関するいくつかの所見と論理的なマルチキャストは従います、そして、IPngがどうATMをひくかに関するモデルが必要であることが提案されます。

   Finally, the paper suggests that the requirements for policy routing,
   accounting, and security firewalls will in turn require all IPng
   packets to carry a trace of the type of transaction involved as well
   as of their source and destination.

最終的に、紙は、方針ルーティング、会計学、およびセキュリティファイアウォールのための要件がまた、それらのソースと目的地の時点でかかわったトランザクションのタイプの跡を運ぶために順番にすべてのIPngパケットを必要とするのを示します。

Transition and deployment

変遷と展開

   It is clear that the transition will take years and that every site
   will have to decide its own staged transition plan. Only the very
   smallest sites could envisage a single step ("flag day") transition,

変遷が何年もかかって、あらゆるサイトがそれ自身の上演された変遷プランについて決めなければならないのは、明確です。 非常に最も小さいサイトだけがシングルステップ(「旗の日」)変遷を考えるかもしれません。

Carpenter                                                       [Page 1]

RFC 1671          IPng White Paper on Transition, etc.       August 1994

変遷などに関する大工[1ページ]RFC1671IPng白書 1994年8月

   presumably under pressure from their Internet service providers.
   Furthermore, once the IPng decision is taken, the next decade (or
   more) of activity in the Internet and in all private networks using
   the Internet suite will be strongly affected by the process of IPng
   deployment. User sites will look at the decision whether to change
   from IPv4 in the same way as they have looked in the past at changes
   of programming language or operating system. It may not be a foregone
   conclusion that what they change to is IPng.  Their main concern will
   be to minimise the cost of the change and the risk of lost
   production.

それらのインターネット接続サービス業者からのおそらく圧力の下で。 その上、いったんIPng決定を取ると、インターネットとすべての私設のネットワークにおける、インターネットスイートを使用する活動の次の10年間(さらに)はIPng展開のプロセスで強く影響を受けるでしょう。 ユーザの現場は同様に、過去にプログラミング言語かオペレーティングシステムの変化を調べたようにIPv4から変化するかどうかという決定を見るでしょう。 彼らが何に変化するかが、IPngであることは当然の結果でないかもしれません。 彼らの主な関心事は変化の費用と無くなっている生産の危険を最小とならせることでしょう。

   This concern immediately defines strong constraints on the model for
   transition and deployment of IPng. Some of these constraints are
   listed below, with a short explanation of each one.

この関心はすぐに、IPngの変遷と展開のためにモデルの上で強い規制を定義します。 これらの規制のいくつかが以下にそれぞれの短い説明によって記載されます。

   Terminology: an "IPv4 host" is a host that runs exactly what it runs
   today, with no maintenance releases and no configuration changes. An
   "IPng host" is a host that has a new version of IP, and has been
   reconfigured.  Similarly for routers.

用語: 「IPv4ホスト」はまさにそれが今日実行することを実行するホストです、メンテナンスリリースにもかかわらず、どんな構成変更なしでもそうしません。 「IPngホスト」はIPの新しいバージョンを持って、再構成されたホストです。 同様である、ルータのために。

   A) Interworking at every stage and every layer.

a) あらゆるステージとあらゆる層では、織り込みます。

   This is the major constraint. Vendors of computer systems, routers,
   and applications software will certainly not coordinate their product
   release dates. Users will go on running their old equipment and
   software.  Therefore, any combination of IPv4 and IPng hosts and
   routers must be able to interwork (i.e., participate in UDP and TCP
   sessions). An IPv4 packet must be  able to find its way from any IPv4
   host, to any other IPv4 or IPng host, or vice versa, through a
   mixture of IPv4 and IPng routers, with no (zero, null) modifications
   to the IPv4 hosts. IPv4 routers must need no modifications to
   interwork with IPng routers.  Additionally, an application package
   which is "aware" of IPv4 but still "unaware" of IPng must be able to
   run on a computer system which is running IPv4, but communicating
   with an IPng host.  For example an old PC in Europe should be able to
   access a NIC server in the USA, even if the NIC server is running
   IPng and the transatlantic routing mechanisms are only partly
   converted.  Or a Class C network in one department of a company
   should retain full access to corporate servers which are running
   IPng, even though nothing whatever has been changed inside the Class
   C network.

これは主要な規制です。 確かに、コンピュータ・システム、ルータ、およびアプリケーションソフトウェアのベンダーは彼らの製品公開日を調整しないでしょう。 ユーザは、彼らの古い設備とソフトウェアを動かし続けるでしょう。 したがって、ホストとルータが織り込むことができなければならない(すなわち、UDPとTCPセッションのときに、参加します)IPv4とIPngのどんな組み合わせ。 IPv4パケットはどんなIPv4ホストからも届くことができなければなりません、いかなる他のIPv4かIPngホストにも、逆もまた同様です、IPv4の混合物とIPv4ホストへの(ゼロ、ヌル)変更のないIPngルータを通して。 IPv4ルータは、IPngと共にルータを織り込むために変更を全く必要としてはいけません。 さらに、IPngにIPv4にもかかわらず、まだ「気づきません」を「意識している」アプリケーションパッケージはIPv4を実行しますが、IPngホストとコミュニケートしているコンピュータ・システムで動くことができなければなりません。 例えば、ヨーロッパの古いPCは米国でNICサーバにアクセスするはずであることができます、NICサーバが実行しているIPngである、大西洋横断のルーティングメカニズムが一部変換されるだけであっても。 または、実行しているIPngである法人のサーバ無さですが、Class Cネットワークの中で何を変えたとしても、会社の1つの部のClass Cネットワークは完全なアクセスを保有するべきです。

   (This does NOT require an IPv4-only application to run on an IPng
   host; thus we accept that some hosts cannot be upgraded until all
   their applications are IPng-compatible. In other words we accept that
   the API may change to some extent. However, even this relaxation is
   debatable and some vendors may want to strictly preserve the IPv4 API
   on an IPng host.)

(これはIPngホストで走るためにIPv4だけアプリケーションを必要としません。 したがって、私たちは、彼らのすべてのアプリケーションがIPng互換性があるまで何人かのホストがアップグレードできないと受け入れます。 言い換えれば、私たちは、APIがある程度変化するかもしれないと受け入れます。 しかしながら、この緩和さえ論争の余地があって、IPngホストの上に厳密にIPv4APIを保存したがっているベンダーもあるかもしれません。)

Carpenter                                                       [Page 2]

RFC 1671          IPng White Paper on Transition, etc.       August 1994

変遷などに関する大工[2ページ]RFC1671IPng白書 1994年8月

   B) Header translation considered harmful.

B) 有害であると考えられたヘッダー翻訳。

   This author believes that any transition scenario which REQUIRES
   dynamic header translation between IPv4 and IPng packets will create
   almost insurmountable practical difficulties:

この作者は、IPv4とIPngパケットの間のREQUIRESのダイナミックなヘッダー翻訳がそうするどんな変遷シナリオもほとんど打ち勝ちがたい実用的な困難を作成すると信じています:

     B1) It is taken for granted for the purposes of this paper that
         IPng functionality will be a superset of IPv4 functionality.
         However, successful translation between protocols requires
         that the functionalities of the two protocols which are to be
         translated are effectively identical. To achieve this,
         applications will need to know when they are interworking,
         via the IPng API and a translator somewhere in the network,
         with an IPv4 host, so as to use only IPv4 functionality. This
         is an unrealistic constraint.

B1) この紙の目的のために、IPngの機能性がIPv4の機能性のスーパーセットになるのが当然のことと思われます。 しかしながら、プロトコルの間のうまくいっている翻訳は、事実上、翻訳されることである2つのプロトコルの機能性が同じであることを必要とします。 アプリケーションは、ネットワークにおけるどこかでいつ彼らがIPng APIを通した織り込むのと翻訳者であるかを知る必要があるでしょう、IPv4ホストと共に、これを達成するならIPv4の機能性だけを使用するために。 これは非現実的な規制です。

     B2) Administration of translators will be quite impracticable for
         large sites, unless the translation mechanism is completely
         blind and automatic. Specifically, any translation mechanism
         that requires special tags to be maintained manually for each
         host in tables (such as DNS tables or router tables) to
         indicate the need for translation will be impossible to
         administer. On a site with thousands of hosts running many
         versions and releases of several operating systems, hosts
         move forwards and even backwards between software releases in
         such a way that continuously tracking the required state of
         such tags will be impossible. Multiplied across the whole
         Internet, this will lead to chaos, complex failure modes, and
         difficult diagnosis. In particular, it will make the
         constraint of paragraph B1) impossible to respect.

B2) 変換メカニズムが完全に盲目であって自動でない場合、翻訳者の政権は大きいサイトに十分実行不可能になるでしょう。 明確に、管理するのはテーブル(DNSテーブルかルータテーブルなどの)の各ホストが翻訳の必要性を示すように特別なタグが手動で維持されるのを必要とするどんな変換メカニズムも不可能になるでしょう。 何千人ものホストが数個のオペレーティングシステムの多くのバージョンとリリースを実行しているサイトでは、ホストはソフトウェアリリースの間で絶え間なくそのようなタグの必要な状態を追跡するのが不可能であるような方法で前方と後方にさえ移行します。 全体のインターネットの向こう側に掛けられて、これはカオス、複雑な故障モード、および難しい診断に通じるでしょう。 それはパラグラフの規制を尊敬するのが不可能であるB1に特に、するでしょう。

         In practice, the knowledge that translation is needed should
         never leak out of the site concerned if chaos is to be
         avoided, and yet without such knowledge applications cannot
         limit themselves to IPv4 functionality when necessary.

実際には、翻訳が必要であるという知識は、カオスが避けられることであるなら関するサイトから決して漏れるべきではありませんが、必要であるときに、そのような知識アプリケーションなしで自分たちをIPv4の機能性に制限できません。

   To avoid confusion, note that header translation, as discussed here,
   is not the same thing as address translation (NAT). This paper does
   not discuss NAT.

混乱を避けるには、ここで議論するヘッダー翻訳がアドレス変換(NAT)と同じものでないことに注意してください。 この論文はNATについて議論しません。

   This paper does not tackle performance issues in detail, but clearly
   another disadvantage of translation is the consequent overhead.

この紙は詳細に性能問題に取り組みませんが、明確に、翻訳の別の不都合は結果のオーバーヘッドです。

   C) Coexistence.

C) 共存。

   The Internet infrastructure (whether global or private) must allow
   coexistence of IPv4 and IPng in the same routers and on the same

インターネット基盤(グローバルであるか、または個人的であることにかかわらず)は同じルータと同じくらい上にIPv4とIPngの共存を許容しなければなりません。

Carpenter                                                       [Page 3]

RFC 1671          IPng White Paper on Transition, etc.       August 1994

変遷などに関する大工[3ページ]RFC1671IPng白書 1994年8月

   physical paths.

物理的な経路。

   This is a necessity, in order that the network infrastructure can be
   updated to IPng without requiring hosts to be updated in lock step
   and without requiring translators.

これは必要性です、ロックステップでホストをアップデートするのが必要であることなしで翻訳者を必要とすることなしでネットワークインフラをIPngにアップデートできるように。

   Note that this requirement does NOT impose a decision about a common
   or separate (ships-in-the-night) approach to routing.  Nor does it
   exclude encapsulation as a coexistence mechanism.

この要件がルーティングへの一般的であるか別々(夜の船)のアプローチに関する決定を課さないことに注意してください。 また、それは共存メカニズムとしてカプセル化を除きません。

   D) IPv4 to IPng address mapping.

D) IPngへのIPv4はマッピングを扱います。

   Human beings will have to understand what is happening during
   transition. Although auto-configuration of IPng addresses may be a
   desirable end point, management of the transition will be greatly
   simplified if there is an optional simple mapping, on a given site,
   between IPv4 and IPng addresses.

人間は、何が変遷の間、起こっているかを理解しなければならないでしょう。 IPngアドレスの自動構成は望ましいエンドポイントであるかもしれませんが、任意の簡単なマッピングがあると、変遷の管理は大いに簡素化されるでしょう、与えられたサイトで、IPv4とIPngアドレスの間で。

   Therefore, the IPng address space should include a mapping for IPv4
   addresses, such that (if a site or service provider wants to do this)
   the IPv4 address of a system can be transformed mechanically into its
   IPng address, most likely by adding a prefix.  The prefix does not
   have to be the same for every site; it is likely to be at least
   service-provider specific.

したがって、IPngアドレス空間はIPv4アドレスのためのマッピングを含むべきです、機械的にシステムの(サイトかサービスプロバイダーがこれをしたいなら)IPv4アドレスをIPngアドレスに変えることができるように、たぶん接頭語を加えることによって。 あらゆるサイトに、接頭語は同じである必要はありません。 それはサービスプロバイダー少なくとも特有である傾向があります。

   This does not imply that such address mapping will be used for
   dynamic translation (although it could be) or to embed IPv4 routing
   within IPng routing (although it could be). Its main purpose is to
   simplify transition planning for network operators.

これは、ダイナミックな翻訳(それはそうであるかもしれませんが)かIPngルーティングの中でIPv4ルーティングを埋め込むためにそのようなアドレス・マッピングが使用されるのを含意しません(それがそうであるかもしれませんが)。 主な目的はネットワーク・オペレータの計画を立てる変遷を簡素化することです。

   By the way, this requirement does not actually assume that IPv4
   addresses are globally unique.

ところで、この要件は、実際にIPv4アドレスがグローバルにユニークであると仮定しません。

   Neither does it help much in setting up the relationship, if any,
   between IPv4 and IPng routing domains and hierarchies. There is no
   reason to suppose these will be in 1:1 correspondence.

どちらも、それは、IPv4と、IPng経路ドメインと階層構造の間でもしあれば関係をセットアップするのをあまり手伝いません。 1:1通信にはこれらがあると思う理由が全くありません。

   E) Dual stack hosts.

E) デュアルスタックホスト。

   Stepwise transition without translation is hard to imagine unless a
   large proportion of hosts are simultaneously capable of running IPng
   and IPv4.  If A needs to talk to B (an IPng host) and to C (an IPv4
   host) then either A or B must be able to run both IPv4 and IPng. In
   other words, all hosts running IPng must still be able to run IPv4.
   IPng-only hosts are not allowed during transition.

ホストの大プロポーションは同時に実行しているIPngとIPv4ができない場合、翻訳のない徐々に変遷は想像しにくいです。 Aが、B(IPngホスト)と、そして、C(IPv4ホスト)と話す必要があるなら、AかBのどちらかがIPv4とIPngの両方を実行できなければなりません。 言い換えれば、IPngを実行するすべてのホストがまだIPv4を実行できなければなりません。 IPngだけホストは変遷の間、許容されていません。

   This requirement does not imply that IPng hosts really have two
   completely separate IP implementations (dual stacks and dual APIs),

この要件は、IPngホストには2つの完全に別々のIP実装(デュアルスタックと二元的なAPI)が本当にあるのを含意しません。

Carpenter                                                       [Page 4]

RFC 1671          IPng White Paper on Transition, etc.       August 1994

変遷などに関する大工[4ページ]RFC1671IPng白書 1994年8月

   but just that they behave as if they did.  It is compatible with
   encapsulation (i.e., one of the two stacks encapsulates packets for
   the other).

まさしく、彼らはまるで振る舞うかのように振る舞います。 それはカプセル化と互換性があります(すなわち、2つのスタックの1つはもう片方のためにパケットをカプセルに入れります)。

   Obviously, management of dual stack hosts will be simplified by the
   address mapping just mentioned. Only the site prefix has to be
   configured (manually or dynamically) in addition to the IPv4 address.

明らかに、デュアルスタックホストの管理はただ言及されたアドレス・マッピングによって簡素化されるでしょう。 サイト接頭語だけがIPv4アドレスに加えて構成されなければなりません(手動かダイナミックに)。

   In a dual stack host the IPng API and the IPv4 API will be logically
   distinguishable even if they are implemented as a single entity.
   Applications will know from the API whether they are using IPng or
   IPv4.

デュアルスタックホストでは、それらが単一体として実装されても、IPng APIとIPv4APIは論理的に区別可能になるでしょう。 アプリケーションは、APIからそれらがIPngかIPv4を使用しているかどうかを知るでしょう。

   F) DNS.

F) DNS。

   The dual stack requirement implies that DNS has to reply with both an
   IPv4 and IPng address for IPng hosts, or with a single reply that
   encodes both.

デュアルスタック要件は、DNSがIPngホストのためのIPv4とIPngアドレスの両方、または両方をコード化するただ一つの回答で返答しなければならないのを含意します。

   If a host is attributed an IPng address in DNS, but is not actually
   running IPng yet, it will appear as a black hole in IPng space - see
   the next point.

ホストはaであるなら結果と考えられます。実際にIPngを実行しますしかし、IPngスペースのブラックホールとして見える--次の点はわからないのを除いたDNSでのIPng演説。

   G) Smart dual-stack code.

G) 賢いデュアルスタックコード。

   The dual-stack code may get two addresses back from DNS; which does
   it use?  During the many years of transition the Internet will
   contain black holes. For example, somewhere on the way from IPng host
   A to IPng host B there will sometimes (unpredictably) be IPv4-only
   routers which discard IPng packets.  Also, the state of the DNS does
   not necessarily correspond to reality. A host for which DNS claims to
   know an IPng address may in fact not be running IPng at a particular
   moment; thus an IPng packet to that host will be discarded on
   delivery.  Knowing that a host has both IPv4 and IPng addresses gives
   no information about black holes. A solution to this must be proposed
   and it must not depend on manually maintained information.  (If this
   is not solved, the dual stack approach is no better than the packet
   translation approach.)

デュアルスタックコードはDNSから2つのアドレスを取り戻すかもしれません。 それはどれを使用しますか? 何年も変遷の間、インターネットはブラックホールを含むでしょう。 例えば、どこかのIPngホストAからIPngホストへの途中では、そこのBは時々(予想外に)IPv4だけルータになるでしょうIPngパケットを捨てる。 また、DNSの州は必ず現実と一致しているというわけではありません。 事実上、DNSがIPngアドレスを知ると主張するホストは特定の瞬間にIPngを実行しないかもしれません。 したがって、そのホストへのIPngパケットは配送のときに捨てられるでしょう。 ホストにはIPv4とIPngアドレスの両方があるのを知っているのがブラックホールの情報を全く教えません。 これへのソリューションを提案しなければなりません、そして、それは手動で維持された情報によってはいけません。 (これが解決されていないなら、デュアルスタックアプローチはパケット翻訳アプローチより良いというわけではありません。)

   H) Smart management tools.

H) 賢い管理ツール。

   A whole set of management tools is going to be needed during the
   transition. Why is my IPng route different from my IPv4 route?  If
   there is translation, where does it happen?  Where are the black
   holes? (Cosmologists would like the same tool :-) Is that host REALLY
   IPng-capable today?...

1つの全体集合の管理ツールが変遷の間、必要でしょう。 私のIPngルートはなぜ私のIPv4ルートと異なっていますか? 翻訳があれば、どこで、それは起こりますか? どこに、ブラックホールがありますか? (宇宙論者は同じツールが欲しいです(^o^) そのホストは今日、本当にIPngできますか?

Carpenter                                                       [Page 5]

RFC 1671          IPng White Paper on Transition, etc.       August 1994

変遷などに関する大工[5ページ]RFC1671IPng白書 1994年8月

Multicasts high and low

方々マルチキャスト

   It is taken for granted that multicast applications must be supported
   by IPng. One obvious architectural rule is that no multicast packet
   should ever travel twice over the same wire, whether it is a LAN or
   WAN wire. Failure to observe this would mean that the maximum number
   of simultaneous multicast transactions would be halved.

IPngがマルチキャストアプリケーションをサポートしなければならないのが当然のことと思われます。 1つの明白な建築規則はマルチキャストパケットが全く同じワイヤの上に二度移動するはずがないということです、それがLANかWANワイヤであることにかかわらず。 これが、同時のマルチキャストトランザクションの最大数が半分にされることを意味するのを観測しないこと。

   A negative feature of IPv4 on LANs is the cavalier use of physical
   broadcast packets by protcols such as ARP (and various non-IETF
   copycats).  On large LANs this leads to a number of undesirable
   consequences (often caused by poor products or poor users, not by the
   protcol design itself).  The obvious architectural rule is that
   physical broadcast should be replaced by unicast (or at worst,
   multicast) whenever possible.

LANのIPv4の否定的特徴はARP(そして、様々な非IETF模倣者)などのprotcolsによる物理的な放送パケットの尊大な使用です。 大きいLANでは、これは多くの望ましくない結果(しばしばprotcolデザイン自体ではなく、不十分な製品か貧しいユーザによって引き起こされる)に通じます。 明白な建築規則は可能であるときはいつも、物理的な放送をユニキャスト(または、最悪の場合はマルチキャスト)に取り替えるべきであるということです。

ATM

気圧

   The networking industry is investing heavily in ATM. No IPng proposal
   will be plausible (in the sense of gaining management approval)
   unless it is "ATM compatible", i.e., there is a clear model of how it
   will run over an ATM network. Although a fully detailed document such
   as RFC 1577 is not needed immediately, it must be shown that the
   basic model works.

ネットワーク産業は大いにATMを投資しています。 それは「ATM互換性がない」とどんなIPng提案ももっともらしくない(管理承認を獲得するという意味における)、すなわち、それがどうATMネットワークをひくかに関する明確なモデルがあります。 RFC1577などの完全に詳細なドキュメントはすぐに、必要ではありませんが、基本型が働いているのを示さなければなりません。

   Similar remarks could be made about X.25, Frame Relay, SMDS etc. but
   ATM is the case with the highest management hype ratio today.

X.25、SMDS Frame Relayなどに関して同様の所見を作ることができましたが、今日、ATMは最も高い管理誇大広告比があるケースです。

Policy routing and accounting

方針ルーティングと会計

   Unfortunately, this cannot be ignored, however much one would like
   to.  Funding agencies want traffic to flow over the lines funded to
   carry it, and they want to know afterwards how much traffic there
   was.  Accounting information can also be used for network planning
   and for back-charging.

残念ながら、非常に1つがどのようにそうしたくても、これを無視できません。 年金基金積立機関は、トラフィックがそれを運ぶために資金を供給された系列の上を流れて欲しいです、そして、それらはその後、どのくらいのトラフィックがあったかを知りたがっています。 また、ネットワーク計画と後部で充電するのに課金情報を使用できます。

   It is therefore necessary that IPng and its routing procedures allow
   traffic to be routed in a way that depends on its source and
   destination in detail. (As an example, traffic from the Physics
   department of MIT might be required to travel a different route to
   CERN than traffic from any other department.)

したがって、IPngとそのルーティング手順が、トラフィックが詳細にそのソースと目的地に頼る方法で発送されるのを許容するのが必要です。 (例として、MITのPhysics部からのトラフィックが異なったルートをCERNに旅行するのにいかなる他の部からのトラフィックよりも必要であるかもしれません。)

   A simple approach to this requirement is to insist that IPng must
   support provider-based addressing and routing.

この要件への簡潔な解決法はIPngがプロバイダーベースのアドレシングとルーティングをサポートしなければならないと主張することです。

   Accounting of traffic is required at the same level of detail (or
   more, for example how much of the traffic is ftp and how much is
   www?).

トラフィックの会計が同じレベルの詳細(トラフィックの多くは、ftpとまたは、以上、例えば、どう多くがどうwwwであるかということですか?)で必要です。

Carpenter                                                       [Page 6]

RFC 1671          IPng White Paper on Transition, etc.       August 1994

変遷などに関する大工[6ページ]RFC1671IPng白書 1994年8月

   Both of these requirements will cost time or money and may impact
   more than just the IP layer, but IPng should not duck them.

これらの要件の両方が、時間かお金がかかって、まさしくIP層より影響を与えるかもしれませんが、IPngはそれらをすくめるはずがありません。

Security Considerations

セキュリティ問題

   Corporate network operators, and campus network operators who have
   been hacked a few times, take this more seriously than many protocol
   experts.  Indeed many corporate network operators would see improved
   security as a more compelling argument for transition to IPng than
   anything else.

数回ハックされた法人のネットワーク・オペレータ、およびキャンパスネットワーク・オペレータは多くが専門家について議定書の中で述べるより真剣にこれを受け止めます。 本当に多くの企業ネットワークのオペレータがIPngへの変遷のための他の何よりも無視できない議論であると向上したセキュリティをみなすでしょう。

   Since IPng will presumably be a datagram protocol, limiting what can
   be done in terms of end-to-end security, IPng must allow more
   effective firewalls in routers than IPv4.  In particular efficient
   traffic barring based on source and destination addresses and types
   of transaction is needed.

終わりから終わりへのセキュリティでできることを制限して、IPngがおそらくデータグラムプロトコルになるので、IPngはIPv4よりルータにおける有効なファイアウォールを許容しなければなりません。 トランザクションのソース、送付先アドレス、およびタイプ以外の効率的なトラフィックが特に、必要です。

   It seems likely that the same features needed to allow policy routing
   and detailed accounting would be needed for improved firewall
   security.  It is outside the scope of this document to discuss these
   features in detail, but it seems unlikely that they are limited to
   implementation details in the border routers.  Packets will have to
   carry some authenticated trace of the (source, destination,
   transaction) triplet in order to check for unwanted traffic, to allow
   policy-based source routing, and/or to allow detailed accounting.
   Presumably any IPng will carry source and destination identifiers in
   some format in every packet, but identifying the type of transaction,
   or even the individual transaction, is an extra requirement.

同じ特徴が、方針ルーティングを許す必要がありそうであって、詳細な会計が向上したファイアウォールセキュリティに必要でしょう。 詳細にこれらの特徴について議論するために、このドキュメントの範囲の外にそれはありますが、それらが境界ルータにおける実装の詳細に制限されるのはありそうもなく見えます。 パケットは、求められていないトラフィックがないかどうかチェックするために(ソース、目的地、トランザクション)三つ子のいくらかの認証された跡を運んで、方針ベースのソースルーティングを許して、詳細な会計を許容しなければならないでしょう。 おそらくどんなIPngもあらゆるパケットで何らかの形式でソースと目的地識別子を運ぶでしょうが、トランザクションのタイプ、または個々のトランザクションさえ特定するのは、付加的な要件です。

Disclaimer and Acknowledgements

注意書きと承認

   This is a personal view and does not necessarily represent that of my
   employer.

これは、個人的な視点であり、必ず私の雇い主のものを表すというわけではありません。

   CERN has been through three network transitions in recent years (IPv4
   renumbering managed by John Gamble, AppleTalk Phase I to Phase II
   transition managed by Mike Gerard, and DECnet Phase IV to DECnet/OSI
   routing transition managed by Denise Heagerty).  I could not have
   written this document without having learnt from them. I have also
   benefitted greatly from discussions with or the writings of many
   people, especially various members of the IPng Directorate. Several
   Directorate members gave comments that helped clarify this paper, as
   did Bruce L Hutfless of Boeing.  However the opinions are mine and
   are not shared by all Directorate members.

近年、CERNが3つのネットワーク変遷でありました(IPv4の番号を付け替えるのは私がジョンGamble、AppleTalk Phaseによってマイク・ジェラードによって管理されたPhase II変遷に管理されて、デニーズHeagertyによって管理されたDECnet/OSIルーティング変遷にDECnet Phase IVを管理されました)。 それらから学んでいなくて、私はこのドキュメントを書くことができませんでした。 また、私が議論から大いに利益を得た、または、多くの人々、IPng Directorateの特に様々なメンバーの文章。 数人のDirectorateメンバーがボーイングのブルースL Hutflessのようにこの紙をはっきりさせるのを助けたコメントを与えました。 しかしながら、意見は、私のものであり、すべてのDirectorateメンバーによって共有されません。

Carpenter                                                       [Page 7]

RFC 1671          IPng White Paper on Transition, etc.       August 1994

変遷などに関する大工[7ページ]RFC1671IPng白書 1994年8月

Author's Address

作者のアドレス

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

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

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

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

Carpenter                                                       [Page 8]

大工[8ページ]