RFC2101 日本語訳

Network Working Group                                       B. Carpenter
Request for Comments: 2101                                  J. Crowcroft
Category: Informational                                       Y. Rekhter
                                                                     IAB
                                                           February 1997

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

                      IPv4 Address Behaviour Today

今日のIPv4アドレスのふるまい

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

要約

   The main purpose of this note is to clarify the current
   interpretation of the 32-bit IP version 4 address space, whose
   significance has changed substantially since it was originally
   defined.  A short section on IPv6 addresses mentions the main points
   of similarity with, and difference from, IPv4.

この注意の主な目的は32ビットのIPバージョン4アドレス空間の現在の解釈をはっきりさせることです。(それが元々定義されて以来、アドレス空間の意味は実質的に変化しています)。 IPv6の上のセクションがメインが類似性を指す言及、および違いを扱うショート、IPv4。

Table of Contents

目次

     1. Introduction.................................................1
     2. Terminology..................................................2
     3. Ideal properties.............................................3
     4. Overview of the current situation of IPv4 addresses..........4
       4.1. Addresses are no longer globally unique locators.........4
       4.2. Addresses are no longer all temporally unique............6
       4.3. Multicast and Anycast....................................7
       4.4. Summary..................................................8
     5. IPv6 Considerations..........................................8
     ANNEX: Current Practices for IPv4 Address Allocation & Routing..9
     Security Considerations........................................10
     Acknowledgements...............................................11
     References.....................................................11
     Authors' Addresses.............................................13

1. 序論…1 2. 用語…2 3. 理想的な特性…3 4. IPv4アドレスの現在の状況の概要…4 4.1. アドレスはもうグローバルにユニークなロケータではありません…4 4.2. アドレスはもうすべて時間的にユニークではありません…6 4.3. マルチキャストとAnycast…7 4.4. 概要…8 5. IPv6問題…8別館: IPv4のための現在の実務は配分とルート設定を扱います。9 セキュリティ問題…10の承認…11の参照箇所…11人の作者のアドレス…13

1. Introduction

1. 序論

   The main purpose of this note is to clarify the current
   interpretation of the 32-bit IP version 4 address space, whose
   significance has changed substantially since it was originally
   defined in 1981 [RFC 791].

この注意の主な目的は32ビットのIPバージョン4アドレス空間の現在の解釈をはっきりさせることです。(それが1981年[RFC791]に元々定義されて以来、アドレス空間の意味は実質的に変化しています)。

Carpenter, et. al.           Informational                      [Page 1]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[1ページ]のRFC2101IPv4アドレスの振舞い

   This clarification is intended to assist protocol designers, product
   implementors, Internet service providers, and user sites. It aims to
   avoid misunderstandings about IP addresses that can result from the
   substantial changes that have taken place in the last few years, as a
   result of the Internet's exponential growth.

この明確化がプロトコルデザイナー、製品作成者、インターネット接続サービス業者、およびユーザの現場を補助することを意図します。 それは、ここ数年間で起こった大きな変化から生じることができるIPアドレスに関して誤解を避けることを目指します、インターネットの急激な増加の結果、。

   A short section on IPv6 addresses mentions the main points of
   similarity with, and difference from, IPv4.

IPv6の上のセクションがメインが類似性を指す言及、および違いを扱うショート、IPv4。

2. Terminology

2. 用語

   It is well understood that in computer networks, the concepts of
   directories, names, network addresses, and routes are separate and
   must be analysed separately [RFC 1498].  However, it is also
   necessary to sub-divide the concept of "network address" (abbreviated
   to "address" from here on) into at least two notions, namely
   "identifier" and "locator". This was perhaps less well understood
   when RFC 791 was written.

コンピュータネットワークでは、ディレクトリ、名前、ネットワーク・アドレス、およびルートの概念を別々であり、別々に分析しなければならないのが[RFC1498]よく理解されています。 しかしながら、また、「ネットワーク・アドレス」(これから「アドレス」に簡略化されている)の概念を少なくとも2つの概念、すなわち、「識別子」、および「ロケータ」に細分するのも必要です。 これは恐らくRFC791が書かれたならよく理解されていた状態で、より少なかったです。

   In this document, the term "host" refers to any system originating
   and/or terminating IPv4 packets, and "router" refers to any system
   forwarding IPv4 packets from one host or router to another.

本書では、「ホスト」という用語はIPv4パケットを溯源する、そして/または、終えるどんなシステムも示します、そして、「ルータ」は1つのホストかルータから別のルータまでパケットをIPv4に送りながら、どんなシステムも示します。

   For the purposes of this document, an "identifier" is a bit string
   which is used throughout the lifetime of a communication session
   between two hosts, to identify one of the hosts as far as the other
   is concerned. Such an identifier is used to verify the source of
   incoming packets as being truly the other end of the communication
   concerned, e.g. in the TCP pseudo-header [RFC 793] or in an IP
   Security association [RFC 1825].  Traditionally, the source IPv4
   address in every packet is used for this.

このドキュメントの目的のために、「識別子」は2人のホストの間のコミュニケーションセッションの生涯の間中もう片方に関する限り、ホストのひとりを特定するのに使用されるしばらくストリングです。 そのような識別子は、本当に例えば、TCP疑似ヘッダー[RFC793]かIP Security協会[RFC1825]で関するコミュニケーションのもう一方の端であることを入って来るパケットの源について確かめるのに使用されます。 伝統的に、あらゆるパケットのソースIPv4アドレスはこれに使用されます。

   Note that other definitions of "identifier" are sometimes used; this
   document does not claim to discuss the general issue of the semantics
   of end-point identifiers.

「識別子」の他の定義が時々使用されることに注意してください。 このドキュメントは、エンドポイント識別子の意味論の一般答弁について議論すると主張しません。

   For the purposes of this document, a "locator" is a bit string which
   is used to identify where a particular packet must be delivered, i.e.
   it serves to locate the place in the Internet topology where the
   destination host is attached. Traditionally, the destination IPv4
   address in every packet is used for this. IP routing protocols
   interpret IPv4 addresses as locators and construct routing tables
   based on which routers (which have their own locators) claim to know
   a route towards the locators of particular hosts.

「ロケータ」が特定のパケットをどこに提供しなければならないかを特定するのに使用されるものを少し結ぶことである、このドキュメントの目的のために、すなわち、それはあて先ホストが付属しているインターネットトポロジーで場所の場所を見つけるのに役立ちます。 伝統的に、あらゆるパケットの送付先IPv4アドレスはこれに使用されます。 ロケータと構造物経路指定テーブルが特定のホストのロケータに向かったルートをどのルータ(それら自身のロケータを持っている)クレームを知ったらよいかに基礎づけて、IPルーティング・プロトコルはIPv4アドレスを解釈します。

   Both identifiers and locators have requirements of uniqueness, but
   these requirements are different. Identifiers must be unique with
   respect to each set of inter-communicating hosts. Locators must be

識別子とロケータの両方には、ユニークさの要件がありますが、これらの要件は異なっています。 識別子はそれぞれのセットについて相互ホストを伝えることに関してユニークであるに違いありません。 ロケータはそうであるに違いありません。

Carpenter, et. al.           Informational                      [Page 2]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[2ページ]のRFC2101IPv4アドレスの振舞い

   unique with respect to each set of inter-communicating routers (which
   we will call a routing "realm"). While locators must be unique within
   a given routing realm, this uniqueness (but not routability) could
   extend to more than one realm.  Thus we can further distinguish
   between a set of realms with unique locators versus a set of realms
   with non-unique (overlapping) locators.

それぞれのセットの相互交信ルータ(私たちがルーティング「分野」と呼ぶつもりである)に関して、ユニークです。 ロケータが与えられたルーティング分野の中でユニークであるに違いない間、このユニークさ(しかし、routabilityでない)は1つ以上の分野に達するかもしれません。 したがって、私たちはユニークなロケータがある1セットの分野で対非ユニークな(重なること)がある1セットの分野間さらにロケータを区別できます。

   Both identifiers and locators have requirements of lifetime, but
   these requirements are different. Identifiers must be valid for at
   least the maximum lifetime of a communication between two hosts.
   Locators must be valid only as long as the routing mechanisms so
   require (which could be shorter or longer than the lifetime of a
   communication).

識別子とロケータの両方には、生涯の要件がありますが、これらの要件は異なっています。 識別子は少なくとも2人のホストのコミュニケーションの最大の生涯、有効であるに違いありません。 単にルーティングメカニズムがそう必要である(コミュニケーションの生涯よりさらに短いか、または長いかもしれません)限り、ロケータは有効であるに違いありません。

   It will be noted that it is a contingent fact of history that the
   same address space and the same fields in the IP header (source and
   destination addresses) are used by RFC 791 and RFC 793 for both
   identifiers and locators, and that in the traditional Internet a
   host's identifier is identical to its locator, as well as being
   spatially unique (unambiguous) and temporally unique (constant).

空間的にユニークであって(明白な)、時間的にユニークであること(一定の)と同様にそれが同じアドレス空間と同じ分野が識別子とロケータの両方にIPヘッダー(ソースと送付先アドレス)でRFC791とRFC793によって使用されて、伝統的なインターネットが、ホストの識別子はロケータと同じであるという歴史の偶然な事実であることに注意されるでしょう。

   These uniqueness conditions had a number of consequences for design
   assumptions of routing (the infrastructure that IPv4 locators enable)
   and transport protocols (that which depends on the IP connectivity).
   Spatial uniqueness of an address meant that it served as both an
   interface identifier and a host identifier, as well as the key to the
   routing table.  Temporal uniqueness of an address meant that there
   was no need for TCP implementations to maintain state regarding
   identity of the far end, other than the IP address. Thus IP addresses
   could be used both for end-to-end IP security and for binding upper
   layer sessions.

これらのユニークさの状態に、ルーティング(IPv4ロケータが可能にするインフラストラクチャ)とトランスポート・プロトコル(IPの接続性に依存するそれ)のデザイン仮定のための多くの結果がありました。 アドレスの空間的なユニークさは、それがインタフェース識別子とホスト識別子の両方として機能したことを意味しました、経路指定テーブルのキーと同様に。 アドレスの時のユニークさは、TCP実装が遠端のアイデンティティに関して状態を維持する必要は全くなかったことを意味しました、IPアドレスを除いて。 したがって、終わりから終わりへのIPセキュリティと拘束力がある終わる層のセッションにIPアドレスを使用できました。

   Generally speaking, the use of IPv4 addresses as locators has been
   considered more important than their use as identifiers, and whenever
   there has been a conflict between the two uses, the use as a locator
   has prevailed. That is, it has been considered more useful to deliver
   the packet, then worry about how to identify the end points, than to
   provide identity in a packet that cannot be delivered. In other
   words, there has been intensive work on routing protocols and little
   concrete work on other aspects of address usage.

概して、ロケータとしてのIPv4アドレスの使用は彼らの使用より識別子として重要であると考えられました、そして、2つの用途の間には、闘争があったときはいつも、ロケータとしての使用は広がっていました。 すなわち、パケットを提供するために、より役に立ちます、ポイントがその時どう終わりを特定するかを心配すると考えられました、提供できないパケットにアイデンティティを提供するより。 言い換えれば、プロトコルとコンクリートがアドレス用法の他の局面でほとんど扱わないルーティングに対する徹底的な仕事がありました。

3. Ideal properties.

3. 理想的な特性。

   Whatever the constraints mentioned above, it is easy to see the ideal
   properties of identifiers and locators. Identifiers should be
   assigned at birth, never change, and never be re-used. Locators
   should describe the host's position in the network's topology, and
   should change whenever the topology changes.

規制が何でもに上に言及したとしても、識別子とロケータの理想的な特性を見るのは簡単です。 識別子は、出生で割り当てられて、決して変化しないで、決して再使用されるべきではありません。 ロケータは、ネットワークのトポロジーでホストの地位について説明するべきであり、トポロジーが変化するときはいつも、変化するはずです。

Carpenter, et. al.           Informational                      [Page 3]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[3ページ]のRFC2101IPv4アドレスの振舞い

   Unfortunately neither of the these ideals are met by IPv4 addresses.
   The remainder of this document is intended as a snapshot of the
   current real situation.

残念ながらどちらもこれらの理想はIPv4アドレスによって満たされます。 このドキュメントの残りは現在の現実の状況のスナップとして意図します。

4. Overview of the current situation of IPv4 addresses.

4. IPv4アドレスの現在の状況の概要。

   It is a fact that IPv4 addresses are no longer all globally unique
   and no longer all have indefinite lifetimes.

それはIPv4アドレスがすべて、もうグローバルにすべてユニークでなく、またもう無期生涯を持っていないという事実です。

   4.1 Addresses are no longer globally unique locators

4.1のアドレスはもうグローバルにユニークなロケータではありません。

      [RFC 1918] shows how corporate networks, a.k.a. Intranets, may if
      necessary legitimately re-use a subset of the IPv4 address space,
      forming multiple routing realms. At the boundary between two (or
      more) routing realms, we may find a spectrum of devices that
      enables communication between the realms.

[RFC1918]は必要なら、企業ネットワーク(通称イントラネット)がどう合法的にIPv4アドレス空間の部分集合を再使用するかもしれないかを示しています、複数のルーティング分野を形成して。2つ(さらに)のルーティング分野の間の境界では、私たちは分野のコミュニケーションを可能にするデバイスのスペクトルを見つけるかもしれません。

      At one end of the spectrum is a pure Application Layer Gateway
      (ALG). Such a device acts as a termination point for the
      application layer data stream, and is visible to an end-user.  For
      example, when an end-user Ua in routing realm A wants to
      communicate with an end-user Ub in routing realm B, Ua has first
      to explicitly establish communication with the ALG that
      interconnects A and B, and only via that can Ua establish
      communication with Ub. We term such a gateway a "non-transparent"
      ALG.

スペクトルの片端に、純粋なApplication Layerゲートウェイ(ALG)があります。 そのようなデバイスは、応用層データ・ストリームのための終了ポイントとして機能して、エンドユーザにとって、目に見えます。 ルーティング分野AのエンドユーザUaがルーティング分野BでエンドユーザUbとコミュニケートしたがっているとき、例えば、Uaは最初に、明らかにAとBとインタコネクトするALGとのコミュニケーションを確立しなければなりません、そして、それを通してだけ、UaはUbとのコミュニケーションを確立できます。 私たち、そのようなゲートウェイ「非透過」ALGという用語。

      Another form of ALG makes communication through the ALG
      transparent to an end user. Using the previous example, with a
      "transparent" ALG, Ua would not be required to establish explicit
      connectivity to the ALG first, before starting to communicate with
      Ub. Such connectivity will be established transparently to Ua, so
      that Ua would only see connectivity to Ub.

ALGの別のフォームはエンドユーザにとって、透明なALGを通してコミュニケーションを作ります。 「透明な」ALGと共に前の例を使用して、Uaは最初に明白な接続性をALGに確立する必要はないでしょう、Ubとコミュニケートし始める前に。 そのような接続性は、UaがUbにおいて接続性を見るだけであるように、透過的にUaに確立されるでしょう。

      For completeness, note that it is not necessarily the case that
      communicating via an ALG involves changes to the network header.
      An ALG could be used only at the beginning of a session for the
      purpose of authentication, after which the ALG goes away and
      communication continues natively.

完全性によって、ALGを通って交信するのがネットワークヘッダーへの変化にかかわるのが、必ず事実であるというわけではないことに注意してください。 単にセッションの始めに認証の目的にALGを使用できました。(その時、ALGは遠ざかって、コミュニケーションはネイティブに続きました後)。

      Both non-transparent and transparent ALGs are required (by
      definition) to understand the syntax and semantics of the
      application data stream.  ALGs are very simple from the viewpoint
      of network layer architecture, since they appear as Internet hosts
      in each realm, i.e. they act as origination and termination points
      for communication.

非透過のものと同様に透明なALGsはアプリケーションデータ・ストリームの構文と意味論を理解しなければなりません(定義上)。 ALGsがネットワーク層アーキテクチャの観点から非常に簡単である、インターネット・ホストとして各分野に現れるので、創作と終了がコミュニケーションのために指すとき、すなわち、彼らは行動します。

Carpenter, et. al.           Informational                      [Page 4]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[4ページ]のRFC2101IPv4アドレスの振舞い

      At the other end of the spectrum is a Network Address Translator
      (NAT) [RFC 1631]. In the context of this document we define a NAT
      as a device that just modifies the network and the transport layer
      headers, but does not understand the syntax/semantics of the
      application layer data stream (using our terminology what is
      described in RFC1631 is a device that has both the NAT and ALG
      functionality).

範囲内で対照的に一方の側に、Network Address Translatorは(NAT)[RFC1631]ですか? このドキュメントの文脈では、私たちはただネットワークとトランスポート層ヘッダーを変更しますが、応用層データ・ストリームの構文/意味論を理解していないデバイスとNATを定義します(私たちの用語を使用して、RFC1631で説明されることはNATとALGの機能性の両方を持っているデバイスです)。

      In the standard case of a NAT placed between a corporate network
      using private addresses [RFC 1918] and the public Internet, that
      NAT changes the source IPv4 address in packets going towards the
      Internet, and changes the destination IPv4 address in packets
      coming from the Internet.  When a NAT is used to interconnect
      routing realms with overlapping addresses, such as a direct
      connection between two intranets, the NAT may modify both
      addresses in the IP header.  Since the NAT modifies address(es) in
      the IP header, the NAT also has to modify the transport (e.g.,
      TCP, UDP) pseudo-header checksum.  Upon some introspection one
      could observe  that  when interconnecting routing realms with
      overlapping addresses, the set of operations on the network and
      transport header performed by a NAT forms a (proper) subset of the
      set of operations on the network and transport layer performed by
      a transparent ALG.

プライベート・アドレス[RFC1918]を使用する企業ネットワークと公共のインターネットの間に置かれたNATの一般的な場合では、そのNATは、インターネットから来にインターネット、および目的地IPv4がパケットで扱う変化に向かって行きながら、パケットでソースIPv4アドレスを変えます。 NATが2つのイントラネットの間のダイレクト関係などのアドレスを重ね合わせるのにルーティング分野とインタコネクトするのに使用されるとき、NATはIPヘッダーで両方のアドレスを変更するかもしれません。 NATがIPヘッダーでアドレス(es)を変更するので、NATも輸送(例えば、TCP、UDP)疑似ヘッダーチェックサムを変更しなければなりません。 何らかの内省のときに、人は、アドレスを重ね合わせるのにルーティング分野とインタコネクトするとき、NATによって実行されたネットワークと輸送ヘッダーにおける操作のセットが操作のセットの(適切)の部分集合を透明なALGによって実行されたネットワークとトランスポート層に形成するのを観測できました。

      By definition a NAT does not understand syntax and semantics of an
      application data stream. Therefore, a NAT cannot support
      applications that carry IP addresses at the application layer
      (e.g., FTP with PORT or PASV command [RFC 959]). On the other
      hand, a NAT can support any application, as long as such an
      application does not carry IP addresses at the application layer.
      This is in contrast with an ALG that can support only the
      applications coded into the ALG.

定義上、NATはアプリケーションデータ・ストリームの構文と意味論を理解していません。 したがって、NATは応用層(例えば、PORTがあるFTPかPASVコマンド[RFC959])にIPアドレスを載せるアプリケーションをサポートすることができません。 他方では、NATはどんなアプリケーションもサポートすることができます、そのようなアプリケーションが応用層にIPアドレスを載せない限り。 これはALGにコード化されたアプリケーションだけをサポートすることができるALGと比べています。

      One can conclude that both NATs and ALGs have their own
      limitations, which could constrain their usefulness. Combining NAT
      and ALG functionality in a single device could be used to overcome
      some, but not all, of these limitations.  Such a device would use
      the NAT functionality for the applications that do not carry IP
      addresses, and would resort to the ALG functionality when dealing
      with the applications that carry IP addresses. For example, such a
      device would use the NAT functionality to deal with the FTP data
      connection, but would use the ALG functionality to deal with the
      FTP control connection.  However, such a device will fail
      completely handling an application that carries IP addresses, when
      the device does not support the application via the ALG
      functionality, but rather handles it via the NAT functionality.

人は、NATsとALGsの両方にはそれら自身の制限があると結論を下すことができます。(制限はそれらの有用性を抑制できました)。 すべてではなく、これらの限界のいくつかを克服するのに単一のデバイスでNATとALGの機能性を結合するのを使用できました。 そのようなデバイスは、IPアドレスを載せないアプリケーションにNATの機能性を使用して、IPアドレスを載せるアプリケーションに対処するとき、ALGの機能性に訴えるでしょう。 例えば、そのようなデバイスは、FTPデータ接続に対処するのにNATの機能性を使用するでしょうが、FTPコントロール接続に対処するのにALGの機能性を使用するでしょう。 しかしながら、そのようなデバイスは、デバイスがALGの機能性でアプリケーションをサポートしないとIPアドレスを載せるアプリケーションを完全に扱いながら失敗しますが、NATの機能性でそれをむしろ扱います。

Carpenter, et. al.           Informational                      [Page 5]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[5ページ]のRFC2101IPv4アドレスの振舞い

      Communicating through either ALGs or NATs involves changes to the
      network header (and specifically source and destination
      addresses), and to the transport header. Since IP Security
      authentication headers assume that the addresses in the network
      header are preserved end-to-end, it is not clear how one could
      support IP Security-based authentication between a pair of hosts
      communicating through either an ALG or a NAT. Since IP Security,
      when used for confidentiality, encrypts the entire transport layer
      end-to-end, it is not clear how an ALG or NAT could modify
      encrypted packets as they require to.  In other words, both ALGs
      and NATs are likely to force a boundary between two distinct IP
      Security domains, both for authentication and for confidentiality,
      unless specific enhancements to IP Security are designed for this
      purpose.

ALGsかNATsのどちらかを通って交信するのはネットワークヘッダー(そして、明確にソースと送付先アドレス)と、そして、輸送ヘッダーへの変化にかかわります。 IP Security認証ヘッダーが、ネットワークヘッダーのアドレスが保存された終わりから終わりであると仮定するので、1つがどうしたらALGかNATのどちらかを通って交信する1組のホストの間のIPのSecurityベースの認証をサポートすることができたかは、明確ではありません。 秘密性に使用されるとIP Securityが全体のトランスポート層の終わりからエンドを暗号化するので、それは暗号化します。ALGかNATが必要であるようにどうしたら暗号化されたパケットを変更できたかが明確ではありません。 言い換えれば、ALGsとNATsの両方が2つの異なったIP Securityドメインの間の境界を強制しそうです、認証と秘密性のための両方、IP Securityへの特定の増進がこのために設計されない場合。

      Interconnecting routing realms via either ALGs or NATs relies on
      the DNS [RFC 1035].  Specifically, for a given set of
      (interconnected) routing realms, even if network layer addresses
      are no longer unique across the set, fully qualified domain names
      would need to be unique across the set. However, a site that is
      running a NAT or ALG probably needs to run two DNS servers, one
      inside and one outside the NAT or ALG, giving different answers to
      identical queries. This is discussed further in [kre].  DNS
      security [RFC 2065] and some dynamic DNS updates [dns2] will
      presumably not be valid across a NAT/ALG boundary, so we must
      assume that the external DNS server acquires at least part of its
      tables by some other mechanism.

ALGsかNATsのどちらかを通してルーティング分野とインタコネクトすると、DNS[RFC1035]は当てにされます。 明確に、ネットワーク層アドレスがもうセットの向こう側にユニークでなくても、与えられたセットの(インタコネクトされる)のルーティング分野に、完全修飾ドメイン名は、セットの向こう側に特有である必要があるでしょう。 しかしながら、NATかALGを実行しているサイトは、たぶん2つのDNSサーバ、1、およびNATか同じ質問の異なった答えを与えるALGの外の1つを実行する必要があります。 [kre]で、より詳しくこれについて議論します。 DNSセキュリティ[RFC2065]といくつかのダイナミックなDNSアップデート[dns2]がおそらくNAT/ALG境界の向こう側に有効にならないので、私たちは、外部のDNSサーバがある他のメカニズムで少なくともテーブルの一部を取得すると思わなければなりません。

      To summarize, since RFC 1918, we have not really changed the
      spatial uniqueness of an address, so much as recognized that there
      are multiple spaces. i.e.  each space is still a routing realm
      such as an intranet, possibly connected to other intranets, or the
      Internet, by NATs or ALGs (see above discussion). The temporal
      uniqueness of an address is unchanged by RFC 1918.

RFC1918、私たちは本当にアドレスの空間的なユニークさを変えていなくて、複数の空間があると認めさえしました。NATsかALGs(議論を超えて見る)ですなわち、各スペースがそれでもことによると他のイントラネットにつなげられたイントラネットなどのルーティング分野かインターネットであるのでまとめるために。 アドレスの時のユニークさはRFC1918で変わりがありません。

   4.2. Addresses are no longer all temporally unique

4.2. アドレスはもうすべて時間的にユニークではありません。

      Note that as soon as address significance changes anywhere in the
      address space, it has in some sense changed everywhere. This has
      in fact already happened.

アドレス空間でどこでも、それが何らかの意味で持っているアドレス意味変化がいたる所で変化するとすぐに、それに注意してください。 事実上、これは既に起こりました。

      IPv4 address blocks were for many years assigned chronologically,
      i.e.  effectively at random with respect to network topology.
      This led to constantly growing routing tables; this does not
      scale. Today, hierarchical routing (CIDR [RFC 1518], [RFC 1519])
      is used as a mechanism to improve scaling of routing within a
      routing realm, and especially within the Internet (The Annex goes
      into more details on CIDR).

IPv4あて先ブロックがネットワーク形態に関して年代順にすなわち、有効に無作為に割り当てられた何年間もありました。 これは、絶えず経路指定テーブルを育てるのに通じました。 これは比例しません。 今日、階層型ルーティング(CIDR[RFC1518]、[RFC1519])は、ルーティング分野以内とインターネットの特に中でルーティングのスケーリングを改良するのにメカニズムとして使用されます(AnnexはCIDRに関するその他の詳細に入ります)。

Carpenter, et. al.           Informational                      [Page 6]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[6ページ]のRFC2101IPv4アドレスの振舞い

      Scaling capabilities of CIDR are based on the assumption that
      address allocation reflects network topology as much as possible,
      and boundaries for aggregation of addressing information are not
      required to be fully contained within a single organization - they
      may span multiple organizations (e.g., provider with its
      subscribers).  Thus if a subscriber changes its provider, then to
      avoid injecting additional overhead in the Internet routing
      system, the subscriber may need to renumber.

アドレス指定情報の集合のための境界は単純組織の中に完全に含まれるのに必要ではありません--CIDRのスケーリング能力はアドレス配分がネットワーク形態をできるだけ反映するという仮定に基づいています、そして、それらは複数の組織(例えば、加入者がいるプロバイダー)にかかるかもしれません。 その結果、加入者がプロバイダーを変えるなら、インターネット・ルーティングシステムにおける追加オーバーヘッドを注入するのを避けるのに、加入者は必要があるかもしれません。番号を付け替えるのが必要です。

      Changing providers is just one possible reason for renumbering.
      The informational document [RFC 1900] shows why renumbering is an
      increasingly frequent event.  Both DHCP [RFC 1541] and PPP [RFC
      1661] promote the use of dynamic address allocation.

プロバイダーを変えるのは、番号を付け替えることのちょうど1つの可能な理由です。 情報のドキュメント[RFC1900]は、番号を付け替えるのがなぜますます頻繁なイベントであるかを示します。 DHCP[RFC1541]とPPP[RFC1661]の両方がダイナミックなアドレス配分の使用を促進します。

      To summarize, since the development and deployment of DHCP and
      PPP, and since it is expected that renumbering is likely to become
      a common event, IP address significance has indeed been changed.
      Spatial uniqueness should be the same, so addresses are still
      effective locators. Temporal uniqueness is no longer assured. It
      may be quite short, possibly shorter than a TCP connection time.
      In such cases an IP address is no longer a good identifier. This
      has some impact on end-to-end security, and breaks TCP in its
      current form.

本当に、DHCPとPPPの開発と展開、番号を付け替えるのが一般的なイベントになりそうであると予想されて以来のIPアドレス意味をまとめるのを変えました。 空間的なユニークさが同じであるべきであるので、アドレスはまだ有効なロケータです。 時のユニークさはもう保証されません。 それは、かなり短くて、ことによるとTCP接続時間より短いかもしれません。 そのような場合IPアドレスはもう良い識別子ではありません。 これは、終わらせる終わりの何らかの影響セキュリティを持って、現在のフォームでTCPを壊します。

   4.3. Multicast and Anycast

4.3. マルチキャストとAnycast

      Since we deployed multicast [RFC 1112], we must separate the
      debate over meaning of IP addresses into meaning of source and
      destination addresses.  A destination multicast address (i.e. a
      locator for a topologically spread group of hosts) can traverse a
      NAT, and is not necessarily restricted to an intranet (or to the
      public Internet).  Its lifetime can be short too.

マルチキャストが[RFC1112]であると配布したので、私たちはソースと送付先アドレスの意味にIPアドレスの意味に関する討論を切り離さなければなりません。 送付先マルチキャストアドレス(すなわち、ホストの位相的に広げられたグループのためのロケータ)は、NATを横断できて、必ずイントラネットに制限されるというわけではありません(または公共のインターネットに)。 また、寿命は短い場合があります。

      The concept of an anycast address is of an address that
      semantically locates any of a group of systems performing
      equivalent functions. There is no way such an address can be
      anything but a locator; it can never serve as an identifier as
      defined in this document, since it does not uniquely identify
      host.  In this case, the effective temporal uniqueness, or useful
      lifetime, of an IP address can be less than the time taken to
      establish a TCP connection.

anycastアドレスの概念は意味的に同等な機能を実行するシステムのグループのいずれも場所を見つけるアドレスのものです。 そのようなアドレスがロケータどころでないかもしれない方法が全くありません。 それは唯一ホストを特定しないので本書では定義される識別子として決して機能できません。 この場合有効な時のユニークさの、または、役に立つ生涯、IPでは、アドレスはわざわざTCP接続が証明された以下であるかもしれません。

      Here we have used TCP simply to illustrate the idea of an
      association - many UDP based applications (or other systems
      layered on IP) allocate state after receiving or sending a first
      packet, based on the source and/or destination. All are affected
      by absence of temporal uniqueness whereas only the routing
      infrastructure is affected by spatial uniqueness changes.

ここで、私たちは単に協会の考えを例証するのにTCPを使用しました--最初のパケットを受けるか、または送った後に多くのUDPのベースのアプリケーション(他のシステムはIPで層にされた)が状態を割り当てます、ソース、そして/または、目的地に基づいて。 すべてが時のユニークさの欠如で影響を受けますが、ルーティングインフラストラクチャだけが空間的なユニークさの変化で影響を受けます。

Carpenter, et. al.           Informational                      [Page 7]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[7ページ]のRFC2101IPv4アドレスの振舞い

   4.4. Summary

4.4. 概要

      Due to dynamic address allocation and increasingly frequent
      network renumbering, temporal uniqueness of IPv4 addresses is no
      longer globally guaranteed, which puts their use as identifiers
      into severe question.  Due to the proliferation of Intranets,
      spatial uniqueness is also no longer guaranteed across routing
      realms; interconnecting routing realms could be accomplished via
      either ALGs or NATs. In principle such interconnection will have
      less functionality than if those Intranets were directly
      connected. In practice the difference in functionality may or may
      not matter, depending on individual circumstances.

ダイナミックなアドレス配分とますます頻繁なネットワークの番号を付け替えるため、IPv4アドレスの時のユニークさ(識別子として厳しい質問に彼らの使用を置く)はもうグローバルに保証されません。 イントラネットの増殖のため、また、空間的なユニークさはもうルーティング分野の向こう側に保証されません。 ALGsかNATsのどちらかを通してルーティング分野とインタコネクトするのを達成できました。 原則として、そのようなインタコネクトには、イントラネットがそれらであるなら直接接続されたより少ない機能性があるでしょう。 個々の事情によって、実際には、機能性の違いは重要であるかもしれません。

5. IPv6 Considerations

5. IPv6問題

   As far as temporal uniqueness (identifier-like behaviour) is
   concerned, the IPv6 model [RFC 1884] is very similar to the current
   state of the IPv4 model, only more so.  IPv6 will provide mechanisms
   to autoconfigure IPv6 addresses on IPv6 hosts. Prefix changes,
   requiring the global IPv6 addresses of all hosts under a given prefix
   to change, are to be expected. Thus, IPv6 will amplify the existing
   problem of finding stable identifiers to be used for end-to-end
   security and for session bindings such as TCP state.

時のユニークさ(識別子のようなふるまい)に関する限り、IPv6モデル[RFC1884]はIPv4モデルの現状と非常に同様です、よりそうであるだけです。 IPv6は、IPv6がIPv6でホストに演説するのを自動構成するためにメカニズムを提供するでしょう。 与えられた接頭語の下におけるすべてのホストのグローバルなIPv6アドレスが変化するのが必要であることで、接頭語変化は予想されることになっています。 したがって、IPv6は終わりから終わりへのセキュリティとTCP状態などのセッション結合に使用されるために安定した識別子を見つけるという既存の問題を増幅するでしょう。

   The IAB feels that this is unfortunate, and that the transition to
   IPv6 would be an ideal occasion to provide upper layer end-to-end
   protocols with temporally unique identifiers. The exact nature of
   these identifiers requires further study.

IABは、層の終わりから終わりへの上側のプロトコルに時間的にユニークな識別子を提供するためにこれが不幸であり、IPv6への変遷が理想的な時であると感じます。 これらの識別子の正確な本質はさらなる研究を必要とします。

   As far as spatial uniqueness (locator-like behaviour) is concerned,
   the IPv6 address space is so big that a shortage of addresses,
   requiring an RFC 1918-like approach and address translation, is
   hardly conceivable.  Although there is no shortage of IPv6 addresses,
   there is also a well-defined mechanism for obtaining link-local and
   site-local addresses in IPv6 [RFC 1884, section 2.4.8].  These
   properties of IPv6 do not prevent separate routing realms for IPv6,
   if so desired (resulting in multiple security domains as well).
   While at the present moment we cannot identify a case in which
   multiple IPv6 routing realms would be required, it is also hard to
   give a definitive answer to whether there will be only one, or more
   than one IPv6 routing realms.  If one hypothesises that there will be
   more than one IPv6 routing realm, then such realms could be
   interconnected together via ALGs and NATs. Considerations for such
   ALGs and NATs appear to be identical to those for IPv4.

空間的なユニークさ(ロケータのようなふるまい)に関する限り、IPv6アドレス空間が非常に大きいので、アドレスの不足(RFCの1918のようなアプローチを必要として、アドレス変換)は、ほとんど想像できません。 IPv6アドレスの不足が全くありませんが、また、リンク地方の、そして、サイトローカルのアドレスを得るための明確なメカニズムがIPv6[RFC1884、セクション2.4.8]にあります。 IPv6のこれらの特性はIPv6のために別々のルーティング分野を防ぎません、そう望まれているなら(また、複数のセキュリティー領域をもたらします)。 現時点で私たちは複数のIPv6ルーティング分野が必要である場合を特定できませんが、また、1つしかないかどうか決定的な答え、または1つ以上のIPv6ルーティング分野に与えにくいです。1つが、1つ以上のIPv6ルーティング分野があるのを仮定するなら、そのような分野はALGsとNATsを通して一緒にインタコネクトされるかもしれません。 そのようなALGsとNATsのための問題はIPv4にそれらと同じであるように見えます。

Carpenter, et. al.           Informational                      [Page 8]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[8ページ]のRFC2101IPv4アドレスの振舞い

ANNEX: Current Practices for IPv4 Address Allocation & Routing

以下を付加してください。 IPv4アドレス配分とルート設定のための現在の実務

   Initially IP address structure and IP routing were designed around
   the notion of network number classes (Class A/B/C networks) [RFC
   790].  In the earlier 90s growth of the Internet demanded significant
   improvements in both the scalability of the Internet routing system,
   as well as in the IP address space utilization.  Classful structure
   of IP address space and associated with it classful routing turned
   out to be inadequate to meet the demands, so during 1992 - 1993
   period the Internet adopted Classless Inter-Domain Routing (CIDR)
   [RFC 1380], [RFC 1518], [RFC 1519].  CIDR  encompasses a new address
   allocation architecture, new routing protocols,  and a new structure
   of IP addresses.

初めは、IPアドレス構造とIPルーティングはネットワーク・ナンバーのクラス(クラスA/B/Cネットワーク)[RFC790]の概念の周りで設計されました。 以前の90年代では、インターネットのスケーラビリティがシステムを発送して、IPアドレス空間利用で要求して、インターネットの成長は両方でかなりの改善を要求しました。 それにアドレス空間の、そして、関連しているIPのClassful構造が外に需要にこたえるために不十分になるようにターンされたルーティングをclassfulするので、1992--1993の期間、インターネットはClassless Inter-ドメインルート設定(CIDR)[RFC1380]を採用しました、[RFC1518]、[RFC1519。] CIDRは新しいアドレス配分アーキテクチャ、新しいルーティング・プロトコル、およびIPアドレスの新しい構造を包含します。

   CIDR improves scalability of the Internet routing system by extending
   the notion of hierarchical routing beyond the level of individual
   subnets and networks, to allow routing information aggregation not
   only at the level of individual subnets and networks, but at the
   level of individual sites, as well as at the level of Internet
   Service Providers.  Thus an organization (site) could act as an
   aggregator for all the destinations within the organization.
   Likewise, a provider could act as an aggregator for all the
   destinations within its subscribers (organizations directly connected
   to the provider).

CIDRは、個々のサブネットとネットワークのレベルだけではなく、個々のサイトのレベル、およびインターネットサービスプロバイダのレベルで情報集合を発送するのを許容するために階層型ルーティングの概念について個々のサブネットとネットワークのレベルを超えたところまで敷衍することによって、インターネット・ルーティングシステムのスケーラビリティを改良します。 したがって、組織(サイト)は組織の中のすべての目的地へのアグリゲータとして機能できました。 同様に、プロバイダーは加入者の中のすべての目的地へのアグリゲータとして機能できました(組織は直接プロバイダーに接続しました)。

   Extending the notion of hierarchical routing to the level of
   individual sites and providers, and allowing sites and providers to
   act as aggregators of routing information, required changes both to
   the address allocation procedures, and to the routing protocols.
   While in pre-CIDR days address allocation to sites was done without
   taking into consideration the need to aggregate the addressing
   information above the level of an individual network numbers, CIDR-
   based  allocation recommends that address allocation be done in such
   a way as to enable sites and providers to act as aggregators of
   addressing information - such allocation is called "aggregator
   based". To benefit from the "aggregator based" address allocation,
   CIDR introduces an inter-domain routing protocol (BGP-4) [RFC 1771,
   RFC 1772] that provides capabilities for routing information
   aggregation at the level of individual sites and providers.

サイトとプロバイダーがルーティング情報のアグリゲータとして機能するのを個々のサイトとプロバイダーのレベルに階層型ルーティングの概念について敷衍していて、許容するのがアドレス配分手順と、そして、ルーティング・プロトコルに釣り銭がいました。 CIDRのベースの配分が、サイトへのアドレス配分が個々のネットワーク・ナンバーのレベルを超えてアドレス指定情報に集める必要性を考慮に入れないで行われたプレCIDR日にサイトとプロバイダーがアドレス指定情報のアグリゲータとして機能するのを可能にするほどアドレス配分がそのような方法で完了することを勧めますが、--そのような配分は「基づくアグリゲータ」と呼ばれます。 「アグリゲータに基づいている」アドレス配分の利益を得るために、CIDRは個々のサイトとプロバイダーのレベルにおけるルーティング情報集合に能力を提供する相互ドメインルーティング・プロトコル(BGP-4)[RFC1771、RFC1772]を紹介します。

   CIDR improves address space utilization by eliminating the notion of
   network classes,  and replacing it with the notion of contiguous
   variable size (power of 2) address blocks. This allows a better match
   between the amount of address space requested and the amount of
   address space allocated [RFC 1466]. It also facilitates "aggregator
   based" address allocation. Eliminating the notion of network classes
   requires new capabilities in the routing protocols (both intra and
   inter-domain), and IP forwarding. Specifically, the CIDR-capable

CIDRは、ネットワークのクラスの概念を排除して、それを隣接の可変サイズ(2のパワー)あて先ブロックの概念に取り替えることによって、アドレス空間利用を改良します。 これは要求されたアドレス空間の量と割り当てられたアドレス空間[RFC1466]の量との、より良いマッチを許容します。 また、それは「アグリゲータに基づいている」アドレス配分を容易にします。 ネットワークのクラスの概念を排除するのはルーティング・プロトコル(イントラと相互ドメインの両方)、およびIP推進における新しい能力を必要とします。 明確にCIDRできる

Carpenter, et. al.           Informational                      [Page 9]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[9ページ]のRFC2101IPv4アドレスの振舞い

   protocols are required to handle reachability (addressing)
   information expressed in terms of variable length address prefixes,
   and forwarding  is required to implement the "longest match"
   algorithm.  CIDR implications on routing protocols are described in
   [RFC 1817].

プロトコルが可変長アドレス接頭語で言い表された可到達性(扱う)情報を扱うのに必要です、そして、推進が、「最も長いマッチ」アルゴリズムを実装するのに必要です。 ルーティング・プロトコルに関するCIDR含意は[RFC1817]で説明されます。

   The scaling capabilities of CIDR are based on the assumption that
   address allocation reflects network topology as much as possible,
   especially at the level of sites, and their interconnection with
   providers, to enable sites and providers to act as aggregators. If a
   site changes its provider, then to avoid injecting additional
   overhead in the Internet routing system, the site may need to
   renumber. While CIDR does not require every site that changes its
   providers to renumber, it is important to stress that if none of the
   sites that change their providers will renumber, the Internet routing
   system might collapse due to the excessive amount of routing
   information it would need to handle.

CIDRのスケーリング能力はアドレス配分がサイトとプロバイダーがアグリゲータとして機能するのを可能にするためにできるだけ、そして、特にサイトのレベル、およびプロバイダーがあるそれらのインタコネクトでネットワーク形態を反映するという仮定に基づいています。 サイトがそして、ルーティングシステム、サイトが番号を付け替える必要があるかもしれないインターネットにおける追加オーバーヘッドを注入するのを避けるためにプロバイダーを変えるなら。 CIDRは番号を付け替えさせるプロバイダーを変えるあらゆるサイトを必要とするというわけではありませんが、それに圧力を加えるのはそれらのプロバイダーが番号を付け替えさせる変化、インターネットがシステムを発送する場合ルーティングの過量のためそれが扱う必要があるだろう情報を潰すかもしれないサイトのいずれでもあるなら重要ではありません。

   Maintaining "aggregator based" address allocation (to promote
   scalable routing), and the need to support the ability of sites to
   change their providers (to promote competition) demands practical
   solutions for renumbering sites.  The need to contain the  overhead
   in a rapidly growing Internet routing system is likely to make
   renumbering  more and more common [RFC 1900].

「アグリゲータを基づかせました」と主張して、配分(スケーラブルなルーティングを促進する)を扱ってください。そうすれば、サイトがそれらのプロバイダー(競争を促進する)を変える能力をサポートする必要性はサイトに番号を付け替えさせるための実際的な解決を要求します。 急速に成長しているインターネット・ルーティングシステムにおけるオーバーヘッドを含む必要性はますます多くに番号を付け替えさせるのを一般的に[RFC1900]しそうです。

   The need to scale the Internet routing system, and the use of CIDR as
   the primary mechanism for scaling, results in the evolution of
   address allocation and management policies for the Internet. This
   evolution results in adding the "address lending" policy as an
   alternative to the "address ownership" policy [RFC 2008].

インターネット・ルーティングシステムをスケーリングする必要性、および一次機構としてのCIDRのスケーリングの使用はインターネットへのアドレス配分と経営政策の発展をもたらします。 この発展は「アドレス所有権」方針[RFC2008]に代わる手段として「アドレスの貸す」方針を加えるのに結果として生じます。

   IP addressing and routing have been in constant evolution since IP
   was first specified [RFC 791]. Some of the addressing and routing
   principles have been deprecated, some of the principles have been
   preserved, while new principles have been introduced. Current
   Internet routing and addresses (based on CIDR) is an evolutionary
   step that extends the use of hierarchy to maintain a routable global
   Internet.

IPが最初に指定されて以来[RFC791]、一定の発展にはIPアドレシングとルーティングがあります。 アドレシングとルーティング原則のいくつかが推奨しない、原則のいくつかが保存されました、新しい原則は紹介されましたが。 現在のインターネット・ルーティングとアドレス(CIDRに基づいている)は発送可能世界的なインターネットを維持するために階層構造の使用を広げる進化論のステップです。

Security Considerations

セキュリティ問題

   The impact of the IP addressing model on security is discussed in
   sections 4.1 and 5 of this document.

このドキュメントのセクション4.1と5でセキュリティのIPアドレシングモデルの影響について議論します。

Carpenter, et. al.           Informational                     [Page 10]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[10ページ]のRFC2101IPv4アドレスの振舞い

Acknowledgements

承認

   This document was developed in the IAB. Constructive comments were
   received from Ran Atkinson, Jim Bound, Matt Crawford, Tony Li,
   Michael A. Patton, Jeff Schiller. Earlier private communications from
   Noel Chiappa helped to clarify the concepts of locators and
   identifiers.

このドキュメントはIABで開発されました。 Ranアトキンソン、ジムBound、マット・クロフォード・トニー・李、マイケル・A.パットン、ジェフ・シラーから建設的なコメントを受けました。 クリスマスChiappaからの以前の私信は、ロケータと識別子の概念をはっきりさせるのを助けました。

References

参照

   [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
   1981.

[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

   [RFC 790] Postel, J., "Assigned Numbers", September 1981.

[RFC790] ポステル、J.、「規定番号」、1981年9月。

   [RFC 959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD
   9, RFC 959, October 1985.

[RFC959] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
   Specification", STD 13, RFC 1035, November 1987.

Mockapetris、[RFC1035]P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   [RFC 1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
   RFC 1112, September 1989.

[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年9月。

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

[RFC1380] 1992年11月のグロス、P.とP.Almquist、「ルート設定とアドレシングにおけるIESG熟考」RFC1380。

   [RFC 1466] Gerich, E., "Guidelines for Management of IP Address
   Space", RFC 1466, May 1993.

[RFC1466] Gerich(E.、「IP管理アドレス空間のためのガイドライン」、RFC1466)は1993がそうするかもしれません。

   [RFC 1498] Saltzer, J., "On the Naming and Binding of Network
   Destinations", RFC 1498, August 1993 (originally published 1982).

[RFC1498] Saltzer、J. 「ネットワークの目的地の命名と結合」のRFC1498、1993(元々、1982を発行する)年8月。

   [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
   Allocation with CIDR", RFC 1518, September 1993.

[RFC1518] Rekhter、Y.、およびT.李、「CIDRとのIPアドレス配分のためのアーキテクチャ」、RFC1518、1993年9月。

   [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
   Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
   Strategy", RFC 1519, September 1993.

[RFC1519] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日

   [RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", RFC
   1541, October 1993.

[RFC1541] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC1541、1993年10月。

   [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
   RFC 1661, July 1994.

[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。

   [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
   (BGP-4)", RFC 1771, March 1995.

[RFC1771] Rekhter、Y.、および1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。

Carpenter, et. al.           Informational                     [Page 11]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[11ページ]のRFC2101IPv4アドレスの振舞い

   [RFC 1772] Rekhter, Y., and P. Gross, "Application of the Border
   Gateway Protocol in the Internet", RFC 1772, March 1995.

Rekhter、Y.、およびP.が利益を上げる[RFC1772]、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1772、1995年3月。

   [RFC 1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817,
   September 1995.

[RFC1817] Rekhterと、Y.と、「CIDRとClassfulルート設定」、RFC1817、9月1995日

   [RFC 1825] Atkinson, R., "Security Architecture for the Internet
   Protocol", RFC 1825, September 1995.

[RFC1825] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年9月。

   [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
   RFC 1900, February 1996.

[RFC1900] 大工、B.とY.Rekhter、「番号を付け替えるのは仕事を必要とである」RFC1900、1996年2月。

   [RFC 1918] Rekhter, Y.,  Moskowitz, B., Karrenberg, D., de Groot, G.
   J., and E. Lear, "Address Allocation for Private Internets", RFC
   1918, February 1996.

[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.J.とE.リア、「個人的なインターネットのためのアドレス配分」RFC1918(1996年2月)。

   [RFC 1933] Gilligan, R., and E. Nordmark, "Transition Mechanisms for
   IPv6 Hosts and Routers", RFC 1933, April 1996.

[RFC1933] ギリガン、R.、およびE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC1933、1996年4月。

   [RFC 2008] Rekhter, Y., and T. Li, "Implications of  Various Address
   Allocation Policies for Internet Routing", RFC 2008, October 1996.

[RFC2008] Rekhter、Y.、およびT.李、「インターネットルート設定のための様々なアドレス配分方針の含意」、RFC2008、1996年10月。

   [kre] Elz, R., et. al., "Selection and Operation of Secondary DNS
   Servers", Work in Progress.

[kre] et Elz、R.、アル、「セカンダリDNSサーバの選択と操作」、ProgressのWork。

   [RFC 2065] Eastlake, E., and C. Kaufman, "Domain Name System Security
   Extensions", RFC 2065, January 1997.

[RFC2065] イーストレーク、E.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。

   [dns2] Vixie, P., et. al., "Dynamic Updates in the Domain Name System
   (DNS UPDATE)", Work in Progress.

[dns2] et Vixie、P.、アル、「ドメインネームシステム(DNS UPDATE)におけるダイナミックなアップデート」、ProgressのWork。

Carpenter, et. al.           Informational                     [Page 12]

RFC 2101              IPv4 Address Behavior Today          February 1997

et大工、アル。 1997年2月の今日の情報[12ページ]のRFC2101IPv4アドレスの振舞い

Authors' Addresses

作者のアドレス

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

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

   EMail: brian@dxcoms.cern.ch

メール: brian@dxcoms.cern.ch

   Jon Crowcroft
   Dept. of Computer Science
   University College London
   London WC1E 6BT, UK

コンピュータサイエンスユニバーシティ・カレッジロンドンロンドンWC1E 6BTのジョンクロウクロフト部、イギリス

   EMail: j.crowcroft@cs.ucl.ac.uk

メール: j.crowcroft@cs.ucl.ac.uk

   Yakov Rekhter
   Cisco systems
   170 West Tasman Drive
   San Jose, CA, USA

ヤコフRekhterシスコシステム170の西タスマン・Driveサンノゼ(カリフォルニア)(米国)

   Phone: +1 914 528 0090
   Fax: +1 408 526-4952
   EMail: yakov@cisco.com

以下に電話をしてください。 +1 914 528、0090Fax: +1 408 526-4952 メールしてください: yakov@cisco.com

Carpenter, et. al.           Informational                     [Page 13]

et大工、アル。 情報[13ページ]