RFC3789 日本語訳

Network Working Group                                      P. Nesser, II
Request for Comments: 3789                    Nesser & Nesser Consulting
Category: Informational                                A. Bergstrom, Ed.
                                              Ostfold University College
                                                               June 2004

ワーキンググループP.Nesser、コメントを求めるII要求をネットワークでつないでください: 3789年のNesser&Nesserコンサルティングカテゴリ: エド情報のA.ベルイストローム、エーストフォールユニバーシティ・カレッジ2004年6月

            Introduction to the Survey of IPv4 Addresses in
   Currently Deployed IETF Standards Track and Experimental Documents

IPv4の調査への紹介は現在配備されたIETFに標準化過程と実験ドキュメントを記述します。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

Abstract

要約

   This document is a general overview and introduction to the v6ops
   IETF workgroup project of documenting all usage of IPv4 addresses in
   IETF standards track and experimental RFCs.  It is broken into seven
   documents conforming to the current IETF areas.  It also describes
   the methodology used during documentation, which types of RFCs have
   been documented, and provides a concatenated summary of results.

このドキュメントは、IETF標準化過程にIPv4アドレスのすべての用法を記録するv6ops IETFワークグループプロジェクトへの概要と紹介と実験的なRFCsです。 現在のIETF領域に一致している7通のドキュメントがそれに細かく分けられます。 また、それはRFCsのそのタイプが記録されて、結果の連結された概要を提供するドキュメンテーションの間に使用される方法論について説明します。

Table of Contents

目次

   1.0.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
         1.1.  Short Historical Perspective . . . . . . . . . . . . .  2
         1.2.  An Observation on the Classification of Standards. . .  3
   2.0.  Methodology. . . . . . . . . . . . . . . . . . . . . . . . .  4
         2.1.  Scope. . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.0.  Summary of Results . . . . . . . . . . . . . . . . . . . . .  5
         3.1.  Application Area Specifications. . . . . . . . . . . .  5
         3.2.  Internet Area Specifications . . . . . . . . . . . . .  5
         3.3.  Operations and Management Area Specifications. . . . .  6
         3.4.  Routing Area Specifications. . . . . . . . . . . . . .  6
         3.5.  Security Area Specifications . . . . . . . . . . . . .  6
         3.6.  Sub-IP Area Specifications . . . . . . . . . . . . . .  6
         3.7.  Transport Area Specifications. . . . . . . . . . . . .  7
   4.0.  Discussion of "Long Term" Stability of Addresses on
         Protocols. . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.0.  Security Considerations. . . . . . . . . . . . . . . . . . .  8
   6.0.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  8

1.0. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 短い歴史観. . . . . . . . . . . . . 2 1.2。 規格の分類の観測。 . . 3 2.0. 方法論。 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 範囲。 . . . . . . . . . . . . . . . . . . . . . . . . 4 3.0. 結果. . . . . . . . . . . . . . . . . . . . . 5 3.1の概要。 アプリケーション領域仕様。 . . . . . . . . . . . 5 3.2. インターネット領域仕様. . . . . . . . . . . . . 5 3.3。 操作と管理領域仕様。 . . . . 6 3.4. 領域仕様を発送します。 . . . . . . . . . . . . . 6 3.5. セキュリティ領域仕様. . . . . . . . . . . . . 6 3.6。 サブIP領域仕様. . . . . . . . . . . . . . 6 3.7。 領域仕様を輸送してください。 . . . . . . . . . . . . 7 4.0. プロトコルについてのアドレスの「長期」の安定性の議論。 . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.0. セキュリティ問題。 . . . . . . . . . . . . . . . . . . 8 6.0. 承認. . . . . . . . . . . . . . . . . . . . . . 8

Nesser II & Bergstrom        Informational                      [Page 1]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[1ページ]情報のRFC Introduction

   7.0.  References . . . . . . . . . . . . . . . . . . . . . . . . .  8
         7.1.  Normative References . . . . . . . . . . . . . . . . .  8
   8.0.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
   9.0.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 10

7.0. 参照. . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1。 引用規格. . . . . . . . . . . . . . . . . 8 8.0。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 9 9.0。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 10

1.0.  Introduction

1.0. 序論

   This document is the introduction to a document set aiming to
   document all usage of IPv4 addresses in IETF standards.  In an effort
   to have the information in a manageable form, it has been broken into
   7 documents, conforming to the current IETF areas (Application [1],
   Internet [2], Operations and Management [3], Routing [4], Security
   [5], Sub-IP [6], and Transport [7]).  It also describes the
   methodology used during documentation, which types of RFCs that have
   been documented, and provides a concatenated summary of results.

このドキュメントはIETF規格でIPv4アドレスのすべての用法を記録することを目指す文献集合への紹介です。 処理しやすいフォームに情報を持つための努力では、それは7通のドキュメントに壊れています、現在のIETF領域に従って。(Sub-IPのアプリケーション[1]、インターネット[2]、Operations、Management[3]、ルート設定[4]、Security[5]、[6]、およびTransport[7])。 また、それはそうしたRFCsのそのタイプが記録されて、結果の連結された概要を提供するドキュメンテーションの間に使用される方法論について説明します。

1.1.  Short Historical Perspective

1.1. 短い歴史観

   There are many challenges that face the Internet Engineering
   community.  The foremost of these challenges has been the scaling
   issue: how to grow a network that was envisioned to handle thousands
   of hosts to one that will handle tens of millions of networks with
   billions of hosts.  Over the years, this scaling problem has been
   managed, with varying degrees of success, by changes to the network
   layer and to routing protocols.  (Although largely ignored in the
   changes to network layer and routing protocols, the tremendous
   advances in computational hardware during the past two decades have
   been of significant benefit in management of scaling problems
   encountered thus far.)

インターネットEngineering共同体に面している多くの挑戦があります。 これらの挑戦の最前はスケーリング問題です: 何千人もの何十億人のホストと共に何千万ものネットワークを扱うものホストを扱うために思い描かれたネットワークを育てる方法。 数年間、このスケーリング問題は管理されています、異なった度の成功で、ネットワーク層と、そして、ルーティング・プロトコルへの変化で。 (ネットワーク層とルーティング・プロトコルへの変化で主に無視されますが、過去20年間の間のコンピュータのハードウェアにおける物凄い進歩はこれまでのところ行きあたられたスケーリング問題の管理で、重要な利益のものです。)

   The first "modern" transition to the network layer occurred during
   the early 1980's, moving from the Network Control Protocol (NCP) to
   IPv4.  This culminated in the famous "flag day" of January 1, 1983.
   IP Version 4 originally specified an 8 bit network and 24 bit host
   addresses, as documented in RFC 760.  A year later, IPv4 was updated
   in RFC 791 to include the famous A, B, C, D, and E class system.

ネットワーク層への最初の「現代」の変遷は1980年代前半の間、起こりました、Network Controlプロトコル(NCP)からIPv4まで動いて。 これは1983年1月1日の有名な「旗の日」のときに南中しました。 IPバージョン4は元々、RFC760に記録されるように8ビットのネットワークと24ビットのホスト・アドレスを指定しました。 1年後に、有名なA、B、C、D、およびEクラスシステムを含むようにRFC791でIPv4をアップデートしました。

   Networks were growing in such a way that it was clear that a
   convention for breaking networks into smaller pieces was needed.  In
   October of 1984 RFC 917 was published formalizing the practice of
   subnetting.

ネットワークはネットワークをより小さい断片に細かく分けるためのコンベンションが必要であったのが、明確であったような方法で成長していました。 1984年10月に、RFC917は、サブネッティングの習慣を正式にしながら、発行されました。

   By the late 1980's, it was clear that the current exterior routing
   protocol used by the Internet (EGP) was insufficiently robust to
   scale with the growth of the Internet.  The first version of BGP was
   documented in 1989 in RFC 1105.

1980年代後半までには、インターネット(EGP)によって使用される現在の外のルーティング・プロトコルがインターネットの成長でスケーリングするために不十分に強健であったのは、明確でした。 BGPの最初のバージョンは1989年にRFC1105に記録されました。

Nesser II & Bergstrom        Informational                      [Page 2]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[2ページ]情報のRFC Introduction

   Yet another scaling issue, exhaustion of the class B address space
   became apparent in the early 1990s.  The growth and commercialization
   of the Internet stimulated organisations requesting IP addresses in
   alarming numbers.  By May of 1992, over 45% of the Class B space had
   been allocated.  In early 1993 RFC 1466 was published, directing
   assignment of blocks of Class C's be given out instead of Class B's.
   This temporarily circumvented the problem of address space
   exhaustion, but had a significant impact of the routing
   infrastructure.

しかし、別のものが問題をスケーリングして、クラスBアドレス空間の疲労困憊は1990年代前半に明らかになりました。 成長とインターネットの商用化は驚くべき数におけるIPアドレスを要求する機構を刺激しました。 1992年5月までには、Class Bスペースの45%以上を割り当てました。 1993年前半にRFC1466を発行して、ブロックのClassの課題を指示して、Classビーズの代わりにCを配りました。 これは、一時アドレス空間疲労困憊の問題を回避しましたが、ルーティングインフラストラクチャの重要な影響を与えました。

   The number of entries in the "core" routing tables began to grow
   exponentially as a result of RFC 1466.  This led to the
   implementation of BGP4 and CIDR prefix addressing.  This may have
   circumvented the problem for the present, but they continue to pose
   potential scaling issues.

「コア」経路指定テーブルのエントリーの数はRFC1466の結果、指数関数的に成長し始めました。 これはBGP4とCIDR接頭語アドレシングの実現に通じました。 これは当分問題を回避したかもしれませんが、彼らは、潜在的スケーリング問題を引き起こし続けています。

   Growth in the population of Internet hosts since the mid-1980s would
   have long overwhelmed the IPv4 address space if industry had not
   supplied a circumvention in the form of Network Address Translators
   (NATs).  To do this, the Internet has watered down the underlying
   "End-to-End" principle.

産業がNetwork Address Translators(NATs)の形で欺くことを供給しなかったなら、1980年代の半ばからのインターネット・ホストの人口における成長は長い間、IPv4アドレス空間を圧倒したでしょうに。 これをするために、インターネットは基本的な「終わりから終わり」原則を水で薄めました。

   In the early 1990's, the IETF was aware of these potential problems
   and began a long design process to create a successor to IPv4 that
   would address these issues.  The outcome of that process was IPv6.

IETFは、これらの問題を記述するIPv4の後継者を創造するためにこれらの潜在的な問題を意識していて、1990年代前半に長いデザイン過程を始めました。 その過程の結果はIPv6でした。

   The purpose of this document is not to discuss the merits or problems
   of IPv6.  That debate is still ongoing and will eventually be decided
   on how well the IETF defines transition mechanisms and how industry
   accepts the solution.  The question is not "should," but "when."

このドキュメントの目的はIPv6の長所か問題について議論しないことです。 その討論は、まだ進行中であり、IETFが変遷メカニズムをどれくらいよく定義するか、そして、産業がどのように解決策を受け入れるかに関して結局、決められるでしょう。 質問がそうでない、「」 「いつ」はそうするべきであるか。

1.2.  An Observation on the Classification of Standards

1.2. 規格の分類の観測

   It has become clear during the course of this investigation that
   there has been little management of the status of standards over the
   years.  Some attempt has been made by the introduction of the
   classification of standards into Full, Draft, Proposed, Experimental,
   and Historic.  However, there has not been a concerted effort to
   actively manage the classification for older standards.  Standards
   are only classified as Historic when either a newer version of the
   protocol is deployed and it is randomly noticed that an RFC describes
   a long dead protocol, or a serious flaw is discovered in a protocol.
   Another issue is the status of Proposed Standards.  Since this is the
   entry level position for protocols entering the standards process,
   many old protocols or non-implemented protocols linger in this status
   indefinitely.  This problem also exists for Experimental RFCs.
   Similarly, the problem exists for the Best Current Practices (BCP)
   and For You Information (FYI) series of documents.

規格の状態の管理が数年間ほとんどないのはこの調査のコースの間、明確になっています。 規格の分類の導入で何らかの試みをFull、Draft、Proposed、Experimental、およびHistoricにしました。 しかしながら、活発により古い規格のための分類を管理するための協力がありませんでした。 プロトコルの、より新しいバージョンが配備されて、RFCが長い死んでいるプロトコルについて説明するのに手当たりしだいに気付かれているときだけ、規格がHistoricとして分類されるか、または重大な欠陥はプロトコルで発見されます。 別の問題はProposed Standardsの状態です。 これが標準化過程に入るプロトコルのための入社の段階位置であるので、多くの古いプロトコルか非実行されたプロトコルがこの状態に無期限に長居しています。 また、この問題はExperimental RFCsのために存在しています。 同様に、問題がBest Current Practices(BCP)とForのために存在している、あなた、ドキュメントの情報(FYI)シリーズ。

Nesser II & Bergstrom        Informational                      [Page 3]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[3ページ]情報のRFC Introduction

   To exemplify this point, there are 61 Full Standards, only 4 of which
   have been reclassified to Historic.  There are 65 Draft Standards,
   611 Proposed Standards, and 150 Experimental RFCs, of which only 66
   have been reclassified as Historic.  That is a rate of less than 8%.
   It should be obvious that in the more that 30 years of protocol
   development and documentation, there should be at least as many (if
   not a majority of) protocols that have been retired compared to the
   ones that are currently active.

このポイントを例示するために、4つのそれだけがHistoricに分類し直された61Full Standardsがあります。 それに関する66だけがHistoricとして分類し直された65Draft Standards、611Proposed Standards、および150Experimental RFCsがあります。 それは8%未満のレートです。 30年間、そんなに中に、プロトコル開発とドキュメンテーションには、少なくとも同じくらい多くがさらにあるのが、明白であるべきである、(まして、大部分、)、回収されたプロトコルは現在アクティブなものと比較されました。

   Please note that there is occasionally some confusion of the meaning
   of a "Historic" classification.  It does NOT necessarily mean that
   the protocol is not being used.  A good example of this concept is
   the Routing Information Protocol(RIP) version 1.  There are many
   thousands of sites using this protocol even though it has Historic
   status.  There are potentially hundreds of otherwise classified RFC's
   that should be reclassified.

「歴史的な」分類の意味の何らかの混乱が時折あります。 それは、必ずプロトコルが使用されていないことを意味するというわけではありません。 この概念の好例はルーティング情報プロトコル(RIP)バージョン1です。 それにはHistoric状態がいますが、このプロトコルを使用する何千ものサイトがあります。 潜在的に分類し直されるべきであるそうでなければ、分類されたRFCのものの数百があります。

2.0.  Methodology

2.0. 方法論

   To perform this study, each class of IETF standards are investigated
   in order of maturity:  Full, Draft, and Proposed, as well as
   Experimental.  Informational and BCP RFCs are not addressed.  RFCs
   that have been obsoleted by either newer versions or because they
   have transitioned through the standards process are not covered.
   RFCs which have been classified as Historic are also not included.

この研究を実行するために、それぞれのクラスのIETF規格は円熟の順に調査されます: 完全、Draft、Proposed、およびExperimental。 そして、情報、BCP RFCsは記述されません。 それがRFCsであったのは、より新しいバージョンによって時代遅れにされるか、または標準化過程で移行したので、覆われていません。 また、Historicとして分類されたRFCsは含まれていません。

   Please note that a side effect of this choice of methodology is that
   some protocols that are defined by a series of RFC's that are of
   different levels of standards maturity are covered in different spots
   in the document.  Likewise, other natural groupings (i.e., MIBs, SMTP
   extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined.

方法論のこの選択の副作用は異なったレベルの規格円熟のものであるRFCのもののシリーズによって定義されるいくつかのプロトコルがドキュメントの異なった場所でカバーされているということです。 同様に、容易に、他の自然な組分け(すなわち、MIBs、SMTP拡張子、FOOの上のIP、PPP、DNSなど)を想像できました。

2.1.  Scope

2.1. 範囲

   The procedure used in this investigation is an exhaustive reading of
   the applicable RFC's.  This task involves reading approximately
   25,000 pages of protocol specifications.  To compound this, it was
   more than a process of simple reading.  It was necessary to attempt
   to understand the purpose and functionality of each protocol in order
   to make a proper determination of IPv4 reliability.  The author has
   made every effort to produce as complete a document set as possible,
   but it is likely that some subtle (or perhaps not so subtle)
   dependence was missed.  The author encourages those familiar
   (designers, implementers or anyone who has an intimate knowledge)
   with any protocol to review the appropriate sections and make
   comments.

この調査における実行した手順は適切なRFCのものの徹底的な読みです。 このタスクは、およそ2万5000ページのプロトコル仕様を読むことを伴います。 これを合成するために、それは簡単な読書の過程より多かったです。 IPv4の適切な決断を信頼性にするようにそれぞれのプロトコルの目的と機能性を理解しているのを試みるのが必要でした。 作者はできるだけ完全な文献集合を生産するためのあらゆる努力をしましたが、何らかの微妙で(恐らくあまりに微妙でない)の依存が逃されそうでした。 作者は、どんなプロトコルにも詳しい(詳細な知識を持っているデザイナー、implementersまたはだれも)ものが相当区を見直して、コメントをするよう奨励します。

Nesser II & Bergstrom        Informational                      [Page 4]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[4ページ]情報のRFC Introduction

3.0.  Summary of Results

3.0. 結果の概要

   In the initial survey of RFCs, 173 positives were identified out of a
   total of 877, broken down as follows:

RFCsの初期の調査では、173の正数が合計以下の通り破壊された877から特定されました:

         Standards:                        30 out of  68 or 44.12%
         Draft Standards:                  16 out of  68 or 23.53%
         Proposed Standards:               98 out of 597 or 16.42%
         Experimental RFCs:                29 out of 144 or 20.14%

規格: 68%か44.12%のうちの30は規格を作成します: 68%か23.53%のうちの16は規格を提案しました: 597のうちの98か16.42%の実験的なRFCs: 29 144%か20.14%から

   Of those identified, many require no action because they document
   outdated and unused protocols, while others are active document
   protocols being updated by the appropriate working groups (SNMP MIBs
   for example).

彼らが時代遅れの、そして、未使用のプロトコルを記録するので、多くが動作を全く必要としません、他のものは適切なワーキンググループ(例えば、SNMP MIBs)によってアップデートされる作業中の文書プロトコルですが特定されたものでは。

   Additionally, there are many instances of standards that should be
   updated but do not cause any operational impact (STD 3/RFCs 1122 and
   1123 for example) if they are not updated.

さらに、彼らをアップデートしないなら、アップデートするべきですが、どんな操作上の衝撃も引き起こさない規格(STD3/RFCs1122と例えば、1123)の多くの例があります。

   In this statistical survey, a positive is defined as a RFC containing
   an IPv4 dependency, regardless of context.

この統計調査では、正数は文脈にかかわらずIPv4の依存を含むRFCと定義されます。

3.1.  Application Area Specifications

3.1. アプリケーション領域仕様

   In the initial survey of RFCs, 34 positives were identified out of a
   total of 257, broken down as follows:

RFCsの初期の調査では、34の正数が合計以下の通り破壊された257から特定されました:

         Standards:                         1 out of  20 or  5.00%
         Draft Standards:                   4 out of  25 or 16.00%
         Proposed Standards:               19 out of 155 or 12.26%
         Experimental RFCs:                10 out of  57 or 17.54%

規格: 20のうちの1か5.00%が規格を作成します: 25%か16.00%のうちの4は規格を提案しました: 155のうちの19か12.26%の実験的なRFCs: 10 57%か17.54%から

   For more information, please look at [1].

詳しくは、[1]を見てください。

3.2.  Internet Area Specifications

3.2. インターネット領域仕様

   In the initial survey of RFCs, 52 positives were identified out of a
   total of 186, broken down as follows:

RFCsの初期の調査では、52の正数が合計以下の通り破壊された186から特定されました:

         Standards:                        17 out of  24 or 70.83%
         Draft Standards:                   6 out of  20 or 30.00%
         Proposed Standards:               22 out of 111 or 19.91%
         Experimental RFCs:                 7 out of  31 or 22.58%

規格: 24%か70.83%のうちの17は規格を作成します: 20%か30.00%のうちの6は規格を提案しました: 111のうちの22か19.91%の実験的なRFCs: 7 31%か22.58%から

   For more information, please look at [2].

詳しくは、[2]を見てください。

Nesser II & Bergstrom        Informational                      [Page 5]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[5ページ]情報のRFC Introduction

3.3.  Operations and Management Area Specifications

3.3. 操作と管理領域仕様

   In the initial survey of RFCs, 36 positives were identified out of a
   total of 153, broken down as follows:

RFCsの初期の調査では、36の正数が合計以下の通り破壊された153から特定されました:

         Standards:                         6 out of  15 or 40.00%
         Draft Standards:                   4 out of  15 or 26.67%
         Proposed Standards:               26 out of 112 or 23.21%
         Experimental RFCs:                 0 out of  11 or  0.00%

規格: 15%か40.00%のうちの6は規格を作成します: 15%か26.67%のうちの4は規格を提案しました: 112のうちの26か23.21%の実験的なRFCs: 0 11%か0.00%から

   For more information, please look at [3].

詳しくは、[3]を見てください。

3.4.  Routing Area Specifications

3.4. ルート設定領域仕様

   In the initial survey of RFCs, 23 positives were identified out of a
   total of 46, broken down as follows:

RFCsの初期の調査では、23の正数が合計以下の通り破壊された46から特定されました:

         Standards:                         3 out of  3 or 100.00%
         Draft Standards:                   1 out of  3 or  33.33%
         Proposed Standards:               13 out of 29 or  44.83%
         Experimental RFCs:                 6 out of 11 or  54.54%

規格: 3%か100.00%のうちの3は規格を作成します: 3%か33.33%のうちの1は規格を提案しました: 29のうちの13か44.83%の実験的なRFCs: 6 11%か54.54%から

   For more information, please look at [4].

詳しくは、[4]を見てください。

3.5.  Security Area Specifications

3.5. セキュリティ領域仕様

   In the initial survey of RFCs, 4 positives were identified out of a
   total of 124, broken down as follows:

RFCsの初期の調査では、4つの正数が合計以下の通り破壊された124から特定されました:

         Standards:                         0 out of   1 or  0.00%
         Draft Standards:                   1 out of   3 or 33.33%
         Proposed Standards:                1 out of 102 or  0.98%
         Experimental RFCs:                 2 out of  18 or 11.11%

規格: 1%か0.00%のうちの0は規格を作成します: 3%か33.33%のうちの1は規格を提案しました: 102%か0.98%の実験的なRFCsからの1: 2 18%か11.11%から

   For more information, please look at [5].

詳しくは、[5]を見てください。

3.6.  Sub-IP Area Specifications

3.6. サブIP領域仕様

   In the initial survey of RFCs, 0 positives were identified out of a
   total of 7, broken down as follows:

RFCsの初期の調査では、0つの正数が合計以下の通り破壊された7から特定されました:

         Standards:                         0 out of  0 or  0.00%
         Draft Standards:                   0 out of  0 or  0.00%
         Proposed Standards:                0 out of  6 or  0.00%
         Experimental RFCs:                 0 out of  1 or  0.00%

規格: 0%か0.00%のうちの0は規格を作成します: 0%か0.00%のうちの0は規格を提案しました: 6つのうちの0か0.00%の実験的なRFCs: 0 1%か0.00%から

   For information about the Sub-IP Area standards, please look at [6].

Sub-IP Area規格の情報がないかどうか、[6]を見てください。

Nesser II & Bergstrom        Informational                      [Page 6]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[6ページ]情報のRFC Introduction

3.7.  Transport Area Specifications

3.7. 輸送領域仕様

   In the initial survey of RFCs, 24 positives were identified out of a
   total of 104, broken down as follows:

RFCsの初期の調査では、24の正数が合計以下の通り破壊された104から特定されました:

         Standards:                         3 out of  5 or 60.00%
         Draft Standards:                   0 out of  2 or  0.00%
         Proposed Standards:               17 out of 82 or 20.73%
         Experimental RFCs:                 4 out of 15 or 26.67%

規格: 5%か60.00%のうちの3は規格を作成します: 2%か0.00%のうちの0は規格を提案しました: 82のうちの17か20.73%の実験的なRFCs: 4 15%か26.67%から

   For more information, please look at [7].

詳しくは、[7]を見てください。

4.0.  Discussion of "Long Term" Stability of Addresses on Protocols

4.0. プロトコルについてのアドレスの「長期」の安定性の議論

   In attempting this analysis, it was determined that a full scale
   analysis is well beyond the scope of this document.  Instead, a short
   discussion is presented on how such a framework might be established.

この分析を試みる際に、完全な尺度分析がかなりこのドキュメントの範囲を超えているのは、決定していました。 代わりに、そのような枠組みがどう確立されるかもしれないかに関して短い議論は提示されます。

   A suggested approach would be to do an analysis of protocols based on
   their overall function, similar (but not strictly) to the OSI network
   reference model.  It might be more appropriate to frame the
   discussion in terms of the different Areas of the IETF.

提案されたアプローチはそれらの総括的機能(OSIと同様(厳密でない)のネットワーク規範モデル)に基づくプロトコルの分析をするだろうことです。 IETFの異なったAreasに関して議論を縁どるのは、より適切であるかもしれません。

   The problem is fundamental to the overall architecture of the
   Internet and its future.  One of the stated goals of the IPng (now
   IPv6) was "automatic" and "easy" address renumbering.  An additional
   goal is "stateless autoconfiguration."  To these ends, a substantial
   amount of work has gone into the development of such protocols as
   DHCP and Dynamic DNS.  This goes against the Internet age-old "end-
   to-end principle."

問題はインターネットとその未来の総合的な構造に基本的です。 IPng(現在のIPv6)の述べられた目標の1つは「自動で」「簡単な」アドレスの番号を付け替えることでした。 追加目標は「国がない自動構成」です。 これらの終わりまで、かなりの仕事量がDHCPとDynamic DNSのようなプロトコルの開発に入りました。 これはインターネット時代老人に対して「終わりまでの原則を終わり」に行きます。

   Most protocol designs implicitly count on certain underlying
   principles that currently exist in the network.  For example, the
   design of packet switched networks allows upper level protocols to
   ignore the underlying stability of packet routes.  When paths change
   in the network, the higher level protocols are typically unaware and
   uncaring.  This works well since whether the packet goes A-B-C-D-E-F
   or A-B-X-Y-Z-E-F is of little consequence.

ほとんどのプロトコルデザインがそれとなく現在ネットワークで存在するある基本的な原則を頼りにします。 例えば、パケット交換網のデザインは、パケットルートの基本的な安定性を無視するために上側の平らなプロトコルを許容します。 経路がネットワークで変化するとき、より高い平らなプロトコルは、通常気づかなくて、冷淡です。 これは、パケットが行くか否かに関係なく、A B C D電子FかA B-X-Y-Z電子Fが小さい結果のものであるので、うまくいきます。

   In a world where endpoints (i.e., A and F in the example above)
   change at a "rapid" rate, a new model for protocol developers should
   be considered.  It seems that a logical development would be a change
   in the operation of the Transport layer protocols.  The current model
   is essentially a choice between TCP and UDP, neither of which
   provides any mechanism for an orderly handoff of the connection if
   and when the network endpoint (IP) addresses change.  Perhaps a third

終点(上記の例のすなわち、AとF)が「急速な」速度で変化する世界では、プロトコル開発者のための新しいモデルが考えられるべきです。 論理的な開発がTransport層のプロトコルの操作で変化であるように思えます。 現在のモデルは本質的にはTCPとUDPの選択です。ネットワーク終点(IP)が変化を記述するなら、そのどちらも接続の規則的な移管にどんなメカニズムも提供しません。 恐らく3分の1

Nesser II & Bergstrom        Informational                      [Page 7]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[7ページ]情報のRFC Introduction

   major transport layer protocol should be developed, or perhaps
   updated TCP and UDP specifications that include this function might
   be a better solution.

主要なトランスポート層プロトコルは開発されたか、または恐らくアップデートされたTCPであるべきです、そして、この機能を含んでいるUDP仕様は、より良い解決策であるかもしれません。

   There are many, many variables that would need to go into a
   successful development of such a protocol.  Some issues to consider
   are: timing principles; overlap periods as an endpoint moves from
   address A, to addresses A and B (answers to both), to only B; delays
   due to the recalculation of routing paths, etc...

そのようなプロトコルのうまくいっている開発に入る必要がある多くの変数があります。 考えるいくつかの問題は以下の通りです。 タイミング原則。 終点がアドレスAからアドレスAとB(両方に対応する)まで動くBだけへのオーバラップの期間。 遅れはルーティング経路などの再計算がそうします。

5.0.  Security Considerations

5.0. セキュリティ問題

   This memo examines the IPv6-readiness of specifications; this does
   not have security considerations in itself.

このメモは仕様のIPv6-準備を調べます。 これには、本来、セキュリティ問題がありません。

6.0.  Acknowledgements

6.0. 承認

   The authors would like to acknowledge the support of the Internet
   Society in the research and production of this document.
   Additionally the author, Philip J. Nesser II, would like to thanks
   his partner in all ways, Wendy M. Nesser.

作者は研究における、インターネット協会のサポートとこのドキュメントの生産を承諾したがっています。 さらに、作者(フィリップJ.Nesser II)はありがとうございますたがっています。すべての方法で彼のパートナー、ウェンディーM.Nesser。

   The editor, Andreas Bergstrom, would like to thank Pekka Savola for
   guidance and collection of comments for the editing of this document.
   He would further like to thank Alan E. Beard, Jim Bound, Brian
   Carpenter, and Itojun for valuable feedback on many points of this
   document.

エディタ(アンドレアス・ベルイストローム)はこのドキュメントの編集のためのコメントの指導と収集についてペッカSavolaに感謝したがっています。 彼はこのドキュメントの多くの先の有益なフィードバックについてさらにアランE.Beard、ジムBound、ブライアンCarpenter、およびItojunに感謝したがっています。

7.0.  References

7.0. 参照

7.1.  Normative References

7.1. 引用規格

   [1]  Sofia, R. and P. Nesser, II, "Survey of IPv4 Addresses in
        Currently Deployed IETF Application Area Standards", RFC 3795,
        June 2004.

[1] ソフィア、R.、およびP.Nesser、II、「IPv4の調査は現在配備されたIETFにアプリケーション領域規格を記述します」、RFC3795、2004年6月。

   [2]  Mickles, C., Editor and P. Nesser, II, "Survey of IPv4 Addresses
        in Currently Deployed IETF Internet Area Standards", RFC 3790,
        June 2004.

[2]Mickles、C.、エディタ、およびP.Nesser、II、「IPv4の調査は現在配備されたIETFにインターネット領域規格を記述します」、RFC3790、2004年6月。

   [3]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
        Addresses in Currently Deployed IETF Operations & Management
        Area Standards", RFC 3796, June 2004.

[3] Nesser、II、P.、およびA.ベルイストローム、エディタ、「IPv4の調査は現在配備されたIETF操作と管理領域に規格を記述します」、RFC3796、2004年6月。

   [4]  Olvera, C. and P. Nesser, II, "Survey of IPv4 Addresses in
        Currently Deployed IETF Routing Area Standards", RFC 3791, June
        2004.

[4] オルベラ、C.、およびP.Nesser、II、「IPv4の調査は現在配備されたIETFにルート設定領域規格を記述します」、RFC3791、2004年6月。

Nesser II & Bergstrom        Informational                      [Page 8]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[8ページ]情報のRFC Introduction

   [5]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
        Addresses in Currently Deployed IETF Security Area Standards",
        RFC 3792, June 2004.

[5] Nesser、II、P.、およびA.ベルイストローム、エディタ、「IPv4の調査は現在配備されたIETFにセキュリティ領域規格を記述します」、RFC3792、2004年6月。

   [6]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
        Addresses in Currently Deployed IETF Sub-IP Area Standards", RFC
        3793, June 2004.

[6] Nesser、II、P.、およびA.ベルイストローム、エディタ、「IPv4の調査は現在配備されたIETFにサブIP領域規格を記述します」、RFC3793、2004年6月。

   [7]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
        Addresses in Currently Deployed IETF Transport Area Standards",
        RFC 3794, June 2004.

[7] Nesser、II、P.、およびA.ベルイストローム、エディタ、「IPv4の調査は現在配備されたIETFに輸送領域規格を記述します」、RFC3794、2004年6月。

8.0.  Authors' Addresses

8.0. 作者のアドレス

   Please contact the authors with any questions, comments or
   suggestions at:

いずれをもっている作者のために以下で質問、コメントまたは提案に連絡してください。

   Philip J. Nesser II
   Principal
   Nesser & Nesser Consulting
   13501 100th Ave NE, #5202
   Kirkland, WA 98034

ワシントン フィリップJ.Nesser IIのNesser校長とNesserコンサルティング13501第100Ave Ne、#5202カークランド、98034

   Phone:  +1 425 481 4303
   Fax:    +1 425 482 9721
   EMail:  phil@nesser.com

以下に電話をしてください。 +1 425 481、4303Fax: +1 9721年の425 482メール: phil@nesser.com

   Andreas Bergstrom, Editor
   Ostfold University College
   Rute 503 Buer
   N-1766 Halden
   Norway

アンドレアス・エディタエーストフォールユニバーシティ・カレッジルーテ503・ビュールN-1766ハルデンベルイストローム(ノルウェー)

   EMail: andreas.bergstrom@hiof.no

メール: andreas.bergstrom@hiof.no

Nesser II & Bergstrom        Informational                      [Page 9]

RFC 3789      Introduction to the IPv4 Address in the IETF     June 2004

IETF2004年6月のIPv4アドレスへのNesser IIと3789年のベルイストローム[9ページ]情報のRFC Introduction

9.0.  Full Copyright Statement

9.0. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Nesser II & Bergstrom        Informational                     [Page 10]

Nesser IIとベルイストロームInformationalです。[10ページ]