[要約] RFC 3789は、IETFの標準トラックと実験的なドキュメントで現在展開されているIPv4アドレスの調査に関する紹介です。このRFCの目的は、IETFのドキュメントに含まれるIPv4アドレスの使用状況を把握し、将来のIPv4アドレスの割り当てに関する意思決定を支援することです。
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）The Internet Society（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]、運用と管理[3]、ルーティング[4]、セキュリティに準拠して、7つのドキュメントに分割されています。[5]、Sub-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.
ネットワークレイヤーへの最初の「最新の」移行は、1980年代初頭に発生し、ネットワーク制御プロトコル（NCP）からIPv4に移行しました。これは1983年1月1日の有名な「旗の日」に頂点に達しました。IPバージョン4は、RFC 760に記録されているように、元々8ビットネットワークと24ビットホストアドレスを指定しました。A、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の最初のバージョンは、1989年にRFC 1105で文書化されました。
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月までに、クラスBスペースの45％以上が割り当てられました。1993年初頭、RFC 1466が公開され、クラスBの代わりにクラス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.
「コア」ルーティングテーブルのエントリの数は、RFC 1466の結果として指数関数的に成長し始めました。これにより、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.
1980年代半ば以降のインターネットホストの人口の増加は、業界がネットワークアドレス翻訳者（NAT）の形で回転を提供していなかった場合、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.
この点を例示するために、61の完全な基準があり、そのうち4つだけが歴史的に再分類されています。65のドラフト基準、611の提案された基準、150の実験RFCがあり、そのうち66は歴史的として再分類されています。これは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によって定義される一部のプロトコルは、ドキュメントのさまざまなスポットでカバーされていることに注意してください。同様に、他の自然なグループ（つまり、MIBS、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の最初の調査では、合計877の173の陽性が特定され、次のように分類されました。
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％の提案基準：597または16.42％の実験RFCS：144または20.14％のうち29
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.
さらに、更新する必要がある標準の多くのインスタンスがありますが、更新されていない場合は、運用上の影響（たとえばSTD 3/RFCS 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:
RFCSの最初の調査では、合計257のうち34の陽性が特定され、次のように分類されました。
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または5.00％のドラフト標準のうち1つの基準：25または16.00％のうち4つの提案された基準：155または12.26％の実験RFCS：57または17.54％のうち10
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の最初の調査では、合計186のうち52の陽性が特定され、次のように分類されました。
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または19.91％の実験RFCS：31または22.58％のうち7つまたは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の最初の調査では、合計153の36の陽性が特定され、次のように分類されました。
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または23.21％の実験RFCS：11または0.00％のうち0
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:
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または44.83％の実験RFCS：11または54.54％のうち6つまたは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の最初の調査では、合計124のうち4つの肯定的なものが特定され、次のように分類されました。
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％の提案標準：102または0.98％の実験RFCS：18または11.11％のうち2
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の最初の調査では、合計7のうち0の陽性が特定され、次のように分類されました。
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または0.00％ドラフト標準：0または0.00％の提案標準：6または0.00％実験RFCS：1または0.00％の0のうち0または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:
RFCSの最初の調査では、合計104のうち24の陽性が特定され、次のように分類されました。
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％提案された基準：82または20.73％の実験RFCS：15または26.67％のうち4
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）の記載されている目標の1つは、「自動」および「簡単」アドレスの変更でした。追加の目標は、「Stateless Autoconfiguration」です。これらの目的のために、かなりの量の作業が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.
ほとんどのプロトコル設計は、現在ネットワークに存在する特定の基礎となる原則を暗黙的にカウントします。たとえば、パケットスイッチされたネットワークの設計により、上位レベルのプロトコルはパケットルートの根本的な安定性を無視できます。パスがネットワーク内で変更されると、より高いレベルのプロトコルは通常、気づかずに気にかけられません。これは、パケットがA-B-C-D-E-FになるかA-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）が「迅速な」レートで変化する世界では、プロトコル開発者の新しいモデルを考慮する必要があります。論理的な開発は、輸送層プロトコルの動作の変化になると思われます。現在のモデルは、基本的にTCPとUDPの間の選択であり、ネットワークエンドポイント（IP）が変更された場合、接続の整然としたハンドオフのメカニズムはどちらも提供しません。おそらく、3番目の主要な輸送層プロトコルを開発するか、この機能を含む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・ネッサーIIは、あらゆる点で彼のパートナー、ウェンディ・M・ネッサーに感謝したいと思います。
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.
編集者のアンドレアス・バーグストロムは、このドキュメントの編集に関するコメントのガイダンスとコレクションについて、Pekka 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] Sofia、R。およびP. Nesser、II、「現在展開されているIETFアプリケーションエリア標準におけるIPv4アドレスの調査」、RFC 3795、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.、Editor and P. Nesser、II、「現在展開されているIETFインターネットエリア標準におけるIPv4アドレスの調査」、RFC 3790、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. Bergstrom、編集者、「現在展開されているIETFオペレーションおよび管理エリア規格におけるIPv4アドレスの調査」、RFC 3796、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] Olvera、C。およびP. Nesser、II、「現在展開されているIETFルーティングエリア標準におけるIPv4アドレスの調査」、RFC 3791、2004年6月。
[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. Bergstrom、編集者、「現在展開されているIETFセキュリティエリア標準におけるIPv4アドレスの調査」、RFC 3792、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. Bergstrom、編集者、「現在展開されているIETFサブIPエリア標準におけるIPv4アドレスの調査」、RFC 3793、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. Bergstrom、編集者、「現在展開されているIETF輸送エリア規格におけるIPv4アドレスの調査」、RFC 3794、2004年6月。
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.ネッサーIIプリンシパルネッサー＆ネッサーコンサルティング13501 100th Ave NE、＃5202 Kirkland、WA 98034
Phone: +1 425 481 4303
Fax: +1 425 482 9721
EMail: phil@nesser.com
Andreas Bergstrom, Editor Ostfold University College Rute 503 Buer N-1766 Halden Norway
Andreas Bergstrom、編集者Ostfold University College Rute 503 Buer N-1766 Halden Norway
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。