Network Working Group P. Nesser, II
Request for Comments: 3789 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents
現在展開IETF標準化過程と実験ドキュメントでのIPv4アドレスの調査の概要
Status of this 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).
著作権（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標準トラックと実験的RFCでIPv4アドレスのすべての使用を文書化するv6ops IETFワークグループプロジェクトへの一般的な概要と紹介です。これは、現在IETFの領域に準拠した7つの文書に分割されます。また、RFCの種類が文書化されているドキュメントの中に使用する方法を、説明し、結果の連結要約を提供します。
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
7.0. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . 8
8.0. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
9.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
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アドレスのすべての使用を文書化することを目指し、ドキュメントセットの紹介です。管理可能な形式で情報を持たせる努力において、現在のIETF領域（アプリケーション[1]、インターネット[2]、運用および管理に準拠し、7つのドキュメントに分割されている[3]、ルーティング[4]、セキュリティ[5]、サブIP [6]、交通[7]）。また、文書中に使用される方法論、文書化されているRFCのタイプについて説明し、結果の連結要約を提供します。
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.)
インターネット技術コミュニティに直面する多くの課題があります。これらの課題の第一は、スケーリングの問題となっている：ホスト億と数十のネットワークの何百万ものを処理するものにホストの数千人を処理するために想定されたネットワークを成長させる方法。長年にわたり、このスケーリングの問題は、ネットワーク層へとルーティングプロトコルへの変更によって、成功の程度の差で、管理されています。 （主にネットワーク層およびルーティングプロトコルへの変更では無視ものの、過去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.
ネットワーク層への最初の「現代」の移行は、IPv4のネットワーク制御プロトコル（NCP）から移動し、1980年代初頭の間に発生しました。一年後のRFC 760で文書化されているよう。これは、1月1日の有名な「旗の日」に結実し、1983 IPバージョン4は元々、8ビットのネットワークと24ビットのホストアドレスを指定し、IPv4のは有名なを含めるようにRFC 791に更新されました、B、C、D、およびEクラスシステム。
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月にRFC 917は、サブネットの練習を正式発表されました。
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の最初のバージョンは、RFC 1105で、1989年に記載されていました。
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年の月では、クラスBのスペースの45％以上が割り当てられていました。初期の1993年にRFC 1466は、クラスCのブロックの割り当てではなく、クラスBさんから出て与えられる指示、公表されました。これは一時的なアドレス空間の枯渇の問題を回避しますが、ルーティングインフラストラクチャの重要な影響を与えました。
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.
「コア」ルーティングテーブルのエントリ数は、これは、BGP4とCIDR接頭辞のアドレッシングの実装につながったRFC 1466の結果として、指数関数的に成長し始めました。これは、本のための問題を回避しているかもしれないが、彼らは潜在的なスケーリングの問題を提起し続けています。
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.
業界は、翻訳者（NATのを）アドレス、ネットワークの形で迂回を供給していなかった場合は、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.
1990年代初頭には、IETFは、これらの潜在的な問題を知っていたし、これらの問題に対処するだろうIPv4の後継を作成するために、長い設計プロセスを開始しました。そのプロセスの結果は、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が移行メカニズムを定義し、どの産業がソリューションを受け入れどれだけ上決定いたします。質問は、「いつ」「すべき」ではないですが、
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.
これは、長年にわたって標準の状態の少し管理があったことを、この調査の過程で明らかになりました。いくつかの試みがフル、ドラフト、提案、実験、そして歴史的に規格の分類を導入することにより行われています。しかし、積極的に古い規格の分類を管理するための協調努力がなされていませんでした。プロトコルの新しいバージョンのいずれかが配置されている場合の基準は唯一の歴史として分類され、ランダムにRFCが長い死んプロトコルを記述し、または重大な欠陥がプロトコルで発見されたことに気づいています。もう一つの問題は、提案された標準の状態です。これは標準化プロセスに入るプロトコルのためのエントリーレベルの位置であるので、多くの古いプロトコルまたは非実装プロトコルは、無期限にこの状態で残ります。この問題は、実験的RFCのために存在します。同様に、問題が最も良い現在のプラクティス（BCP）のためにとあなたの情報書類の（FYI）シリーズのために存在します。
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そのうち61件のフル規格は、あります。 65のドラフト規格、611の提案された標準、そして唯一の66は歴史的に再分類された150件の実験的RFCは、あります。すなわち、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です。再分類する必要がありそうでない場合は、分類RFCの数百人が潜在的にあります。
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標準の各クラスは、成熟度の順に調査されています。情報およびBCP RFCが対処されていません。いずれかの新しいバージョンによって廃止されているか、彼らは標準化プロセスを通じて移行したため、RFCがカバーされていません。歴史的に分類されているRFCにも含まれていません。
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の一連の定義されているいくつかのプロトコルが、文書内の別のスポットで覆われているということであることに注意してください。同様に、他の自然なグループ（すなわち、MIBは、SMTPの拡張、などFOO、PPP、DNS、オーバーIP）を容易に想像することができます。
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のを網羅読書です。このタスクは、プロトコル仕様の約25,000ページを読み込む必要。これを化合物に、それは簡単な読書のプロセスよりも多かったです。 IPv4の信頼性の適切な決意を行うために、各プロトコルの目的と機能を理解しようとする必要がありました。著者は、可能な限り完全なドキュメントセットを生成するためにあらゆる努力をしてきたが、いくつかの微妙な（あるいはそう微妙なない）依存性が失われた可能性が高いです。著者は、適切なセクションをレビューやコメントを作るために任意のプロトコルで、それらのおなじみの（デザイナー、実装者や親密な知識を持っている人）を奨励しています。
In the initial survey of RFCs, 173 positives were identified out of a total of 877, broken down as follows:
RFCの最初の調査では、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%
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のMIB）によって更新されている間、特定されたもののうち、多くは、何のアクションを必要としません。
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.
さらに、そこに更新すべき基準の多くのインスタンスがありますが、それらが更新されていない場合は任意の業務への影響（例えばSTD 3 /のRFC 1122および1123）を引き起こしません。
In this statistical survey, a positive is defined as a RFC containing an IPv4 dependency, regardless of context.
この統計調査では、ポジティブに関係なく、コンテキストの、IPv4の依存性を含むRFCとして定義されます。
In the initial survey of RFCs, 34 positives were identified out of a total of 257, broken down as follows:
RFCの最初の調査では、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%
For more information, please look at [1].
詳細については、[1]をご覧ください。
In the initial survey of RFCs, 52 positives were identified out of a total of 186, broken down as follows:
RFCの最初の調査では、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%
For more information, please look at [2].
詳細については、[2]をご覧ください。
In the initial survey of RFCs, 36 positives were identified out of a total of 153, broken down as follows:
RFCの最初の調査では、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%
For more information, please look at [3].
詳細については、[3]をご覧ください。
In the initial survey of RFCs, 23 positives were identified out of a total of 46, broken down as follows:
RFCの最初の調査では、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%
For more information, please look at [4].
詳細については、[4]をご覧ください。
In the initial survey of RFCs, 4 positives were identified out of a total of 124, broken down as follows:
RFCの最初の調査では、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%
For more information, please look at [5].
詳細については、[5]をご覧ください。
In the initial survey of RFCs, 0 positives were identified out of a total of 7, broken down as follows:
RFCの最初の調査では、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%
For information about the Sub-IP Area standards, please look at [6].
サブIPエリア規格の詳細については、[6]をご覧ください。
In the initial survey of RFCs, 24 positives were identified out of a total of 104, broken down as follows:
RFCの最初の調査では、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%
For more information, please look at [7].
詳細については、[7]をご覧ください。
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のさまざまな分野の観点から議論をフレームに、より適切な場合があります。
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）の述べた目標の一つは、「自動」と「簡単な」アドレスリナンバリングしました。追加の目標は、「ステートレス自動設定」です。これらの端に、仕事のかなりの量は、DHCPとダイナミック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.
ほとんどのプロトコルの設計は、暗黙的に現在のネットワーク内に存在する特定の基本原則を頼りにしています。例えば、パケット交換ネットワークの設計は、上位レベルのプロトコルは、パケットの経路の基礎となる安定性を無視することを可能にします。パスがネットワークに変更すると、より高いレベルのプロトコルは、典型的には気付かないと思いやりです。これは、パケットが-B-C-D-E-Fを移行または-B-X-Y-Z-E-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 major transport layer protocol should be developed, or perhaps updated TCP and UDP specifications that include this function might be a better solution.
「迅速な」速度で世界中どこエンドポイント（上記の例では、すなわち、AおよびF）の変化では、プロトコルの開発のための新しいモデルが考慮されるべきです。論理的な開発は、トランスポート層プロトコルの動作の変化であろうと思われます。現在のモデルは、基本的にネットワークエンドポイント（IP）が変更に対処したときにあれば、接続の秩序ハンドオフのための任意のメカニズムを提供どちらもTCPとUDPの間の選択、です。おそらく、第三の主要なトランスポート層プロトコルは、この関数は、よりよい解決策かもしれませんが含ま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のみに、エンドポイントが移動するようオーバーラップ期間。パスなどのルーティングの再計算による遅延...
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモは、仕様のIPv6対応の準備を調べます。これは、それ自体ではセキュリティ上の配慮を持っていません。
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.ひげ、ジム、ブライアン・カーペンター、およびいとぢゅんに感謝したいと思います。
[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を、RFC 3795、2004年6月 "のIPv4の調査は、現在展開IETFアプリケーション領域の標準のアドレス"。
[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を、RFC 3790、2004年6月 "のIPv4の調査は、現在展開IETFインターネットエリア標準のアドレス"。
[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.ベルイストローム、エディタを、RFC 3796、2004年6月 "のIPv4の調査は、現在展開IETF操作と管理領域の標準のアドレス"。
[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は、RFC 3791、2004年6月 "のIPv4の調査は、現在展開IETF標準ルーティングエリア内のアドレス"。
[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.ベルイストローム、エディタを、RFC 3792、2004年6月 "のIPv4の調査は、現在展開IETFセキュリティエリア標準のアドレス"。
[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.ベルイストローム、エディタを、RFC 3793、2004年6月 "のIPv4の調査は、現在展開IETFサブIPエリア標準のアドレス"。
[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.ベルイストローム、エディタを、RFC 3794、2004年6月 "のIPv4の調査は、現在展開IETF交通エリア標準のアドレス"。
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第百アヴェNE、＃5202カークランド、WA 98034
Phone: +1 425 481 4303 Fax: +1 425 482 9721 EMail: phil@nesser.com
電話：+1 425 481 4303ファックス：+1 425 482 9721 Eメール：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
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。