[要約] RFC 6217は、地域放送に大気リンク層を使用するためのプロトコルを提案しています。その目的は、地域コミュニティにおける低コストで効果的な放送通信を実現することです。
Independent Submission T. Ritter
Request for Comments: 6217 1 April 2011
Category: Experimental
ISSN: 2070-1721
Regional Broadcast Using an Atmospheric Link Layer
Abstract
概要
Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment.
ブロードキャストは、主にマルチキャストのような技術の賛成で破棄された技術です。この文書は、RFC 919の上に構築され、代替リンク層を使用して、複数のローカルエリアネットワーク（LANs）または都市間ネットワーク（MANs）宛てのブロードキャストパケットのためのより効率的なルーティングメカニズムを説明しています。これは、大幅にネットワーク機器の輻輳を軽減し、追加の物理的なインフラ投資を必要としません。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6217.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6217で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Limitations .....................................................2
4. Physical Layer ..................................................3
5. Frame Format in the OSI Model ...................................3
5.1. Data Link Layer ............................................3
5.2. Network Layer ..............................................3
5.3. Transport Layer ............................................4
6. Reception .......................................................6
7. Datagram Transmission ...........................................6
7.1. Chemical Approach to the Atmospheric Link Layer ............6
7.2. Location ...................................................7
7.3. Physical Layer Conditions ..................................7
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
RFC 919 [1] defines a method for broadcasting packets to a local network. It assumes that data link layers support efficient broadcasting. In the years since RFC 919 was written, Local Area Networks have grown exponentially in size, and frequently they are not geographically local.
RFC 919 [1]は、ローカルネットワークにパケットをブロードキャストするための方法を定義します。これは、データリンク層は、効率的な放送をサポートしていることを前提としています。 RFC 919が書き込まれてから数年では、ローカルエリアネットワークのサイズが指数関数的に成長している、と頻繁に彼らは地理的にローカルではありません。
This RFC proposes a new data link layer that scales efficiently to a geographically local network and, depending on visibility, to an entire Metropolitan Area Network. By using a different transmission medium, the broadcast traffic does not impact current inter- or intra-network routed traffic. It also makes use of a widely available infrastructure that is in use in all major cities and, surprisingly, rural and under-developed locations as well.
このRFCは、全体のメトロポリタン・エリア・ネットワークに、可視性に応じて、地理的にローカルネットワークに効率的にスケーリングし、新しいデータリンク層を提案しています。異なる伝送媒体を用いて、ブロードキャストトラフィックは、現在相互に影響を与えないか、イントラネットワークトラフィックをルーティング。それはまた、同様に、すべての主要都市と、驚くべきことに、農村部やアンダー開発した場所で使用されて広く利用可能なインフラストラクチャを利用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This RFC does not propose solutions to all problems. Just as RFC 919 was unconcerned with reliability, we also do not guarantee that hosts receive datagrams sent. Hosts may not receive packets for a variety of reasons, among them weather conditions, line of sight, sleep patterns, and distraction. A best-effort delivery approach is taken.
このRFCは、すべての問題の解決策を提案していません。 RFC 919を確実に無関心だったのと同じように、我々はまた、ホストが送信されたデータグラムを受信することを保証するものではありません。ホストは、それらの気象条件、視線、睡眠パターン、および気晴らしの中で、さまざまな理由でパケットを受信できない場合があります。ベストエフォート型の配信アプローチがとられています。
These limitations do impact the usefulness of the proposal, but organizations serious about distributing information in this fashion can overcome these obstacles with relatively little difficulty.
これらの制限は、提案の有用性に影響を与えませんが、この方法で情報を配布することについて深刻組織は比較的少ない難しさと、これらの障害を克服することができます。
The physical layer used is made up primarily of nitrogen and oxygen, at a pressure of 101.3 kilopascal at sea level, but dropping to about half that pressure at operating altitudes. Microscopic residue or trace elements may exist in the transmission medium, depending on local formation properties.
使用される物理層は、海面で101.3キロパスカルの圧力で、主として窒素及び酸素からなるが、動作高度で約半分の圧力に低下されます。微視的残基または微量元素は、ローカル形成特性に応じて、伝送媒体に存在してもよいです。
This residue may include argon, carbon dioxide, neon, helium, chloride anions, sulfur dioxide, and other molecules occurring at very low mixtures. It is common for there to be some degree of gaseous dihydrogen monoxide present. These trace molecules usually do not impede the broadcast, although further details on datagram transmission follow.
この残渣を、アルゴン、二酸化炭素、ネオン、ヘリウム、塩化物アニオン、二酸化硫黄、および非常に低いの混合物で発生する他の分子を含むことができます。気体二水素一酸化炭素の存在ある程度があることが一般的です。データグラムの送信の詳細が続くが、これらの微量分子は通常、放送を妨げません。
It is always a challenge to design a protocol that allows enough flexibility for future adaptation while keeping it efficient in size -- and for this medium, size and complexity of the header are of particular concern. For this reason, this RFC proposes recommendations for the Data Link, Network, and Transport Layers.
特に懸念されていると、ヘッダのこの中、大きさや複雑さのために - いつものサイズで効率的な、それを維持しながら、将来の適応のための十分な柔軟性を可能にするプロトコルを設計するための挑戦です。このため、このRFCはデータリンク、ネットワーク、およびトランスポート層のための勧告を提案しています。
Implementations MAY use any protocol that fits their needs for the Network and Transport Layers. They SHOULD consider how different protocols may be interpreted by recipients of the message and choose the most effective protocol available. The protocols defined have been designed to allow maximum ease of interpretation, so their use is encouraged.
実装はネットワーク層とトランスポート層のための彼らのニーズに合った任意のプロトコルを使用してもよいです。彼らは、メッセージの受信者によって解釈され、利用できる最も効果的なプロトコルを選択することができる方法の異なるプロトコルを検討してください。定義されたプロトコルは、解釈の最大やすさを許可するように設計されているので、その使用は推奨されています。
The Data Link Layer is primarily concerned with transmitting datagrams between adjacent nodes, and it is unnecessary here since we only support broadcast transmission. Implementers MUST NOT encapsulate packets in a link layer protocol.
データリンク層は、隣接ノード間でデータグラムを送信すると、主に懸念している、そして我々が唯一の同報送信をサポートするため、ここでは不要です。実装者は、リンク層プロトコルでパケットをカプセル化してはなりません。
When designing a protocol for the Network Layer, it makes sense to consider existing protocols in this layer and reference their strengths and weaknesses. Looking at IPv4/6, we can see their header structures include several fields unnecessary for our purposes:
ネットワーク層のプロトコルを設計するとき、それはこの層では、既存のプロトコルを検討し、その長所と短所を参照するために理にかなっています。 IPv4の/ 6を見ると、我々は彼らのヘッダ構造が我々の目的のために不必要ないくつかのフィールドを含める見ることができます：
Destination, TTL (Time to Live), DSCP (Diffserv Code Point), ECN (Explicit Congestion Notification), Hop Limits, and so on. We can design a much more compact protocol thusly:
デスティネーション、TTL（生存時間）、DSCP（Diffservのコードポイント）、ECN（明示的輻輳通知）、その上のホップ制限、および。私たちは、thuslyはるかにコンパクトなプロトコルを設計することができます。
+-------------------------------+-----------------------------+
| Content | Source |
+-------------------------------+-----------------------------+
Figure 1: Layout of the Datagram
図1：データグラムのレイアウト
Content - A variable-length field containing the encapsulation of higher-level protocols.
コンテンツ - より高いレベルのプロトコルのカプセル化を含む可変長フィールド。
Source - The sender of the message. A transmission MUST choose one of the following representations of the source: - IPv4 address in dot-decimal notation (e.g., 192.168.1.1) - IPv6 address in standard notation (RFC 5952 [2]) - telephone number in E.123 notation - electronic mail address in E.123 notation - Uniform Resource Identifier (RFC 3986 [3]) - geographic address
ソース - メッセージの送信者。送信元の以下の表現のいずれかを選択しなければならない： - ドット進数（例えば、192.168.1.1）にIPv4アドレス - E.123表記の電話番号 - - 標準的な記法（RFC 5952 [2]）でIPv6アドレスをE.123表記の電子メールアドレス - ユニフォームリソース識別子（RFC 3986 [3]） - 地理的なアドレス
The Source field MUST be present -- to send a message anonymously, a sender MUST use one of the reserved entries of the different types. Reserved Entries for telephone numbers vary by region; for example, in North America they are 555-0100 to 555-0199. Reserved entries for IPv4 (RFC 5735 [4]), IPv6 (RFC 5156 [5]), and URIs (RFC 2606 [6]) may be found in their respective RFCs. The concept of a region defined by homogeneous communication characteristics has been put forward already in [7], so geographic addressing ambiguities may be resolved by community standards.
匿名でメッセージを送信するために、送信者は、異なる種類の予約されたエントリのいずれかを使用しなければならない - ソースフィールドが存在しなければなりません。電話番号の予約エントリが領域によって異なります。例えば、北米では、彼らは555から0199に555から0100までです。 IPv4の予約エントリ（RFC 5735 [4]）はIPv6（RFC 5156 [5]）、およびURIを（RFC 2606 [6]）それぞれのRFCに見出すことができます。均質な通信特性によって定義される領域の概念は、[7]ですでに進められているので、地理的なアドレッシングの曖昧さは、コミュニティの規格によって解決することができます。
Because the message is sent to a specific geographical region, more leniency is available in source addressing, but requirements may be imposed by higher-level protocols.
メッセージが特定の地理的領域に送信されるため、より寛大アドレッシングソースで利用可能であるが、必要条件は、より高いレベルのプロトコルによって課されてもよいです。
We call this protocol the Asynchronous Dumb Visual Exchange of Raw Transmissions or ADVERT.
私たちは、生のトランスミッションや広告の非同期ダムビジュアル取引所、このプロトコルを呼び出します。
Similar to the Network Layer, a Transport Layer protocol is able to omit several constructs that are used in existing Transport Layer protocols. Consider TCP -- sequence, acknowledgement, and many of the flags are discarded as there will be no SYN, SYN/ACK, or ACK handshake in a broadcast message. Likewise, fields such as Window Size and Urgent -- created primarily as a benefit to router manufacturers -- are unnecessary in this medium.
ネットワーク層と同様に、トランスポート層プロトコルは、既存のトランスポート層プロトコルで使用されるいくつかの構成要素を省略することができます。シーケンス、承認、およびブロードキャストメッセージにはSYN、SYN / ACK、またはACKハンドシェークがないだろうとのフラグの多くが破棄される - TCPを考えてみましょう。同様に、ウィンドウサイズや緊急などの分野 - 主にルータのメーカーに利益として作成された - は、この中では不要です。
In fact, in the event of a plain text message, content SHOULD be embedded directly in the ADVERT Protocol without the need of a transport protocol. Consider the following packet:
実際には、プレーンテキストメッセージの場合には、コンテンツは、トランスポートプロトコルを必要とせずに広告プロトコルに直接埋め込まれるべきです。次のパケットを考えてみます。
Content Source
+------------------------------------------------------------+
| Lobster Dinner - only $14.99 500 Boardwalk, Pt Pleasant |
+------------------------------------------------------------+
Figure 2: Example ADVERT Datagram
図2：例広告データグラム
For UTF-encoded payloads, one SHOULD use the default UTF-encoding so the packet is human-readable. This will minimize accidental misinterpretation. This transmission structure lends itself most easily to human-parsable messages.
パケットは、人間が読めるように、UTF-エンコードされたペイロードの場合は、1がデフォルトのUTF-encodingを使用すべきです。これは偶然の誤解を最小限に抑えることができます。この伝送構造は、人間が解析可能なメッセージに最も簡単に自分自身を貸します。
For messages intended to be responded to by a computer (for example, binary content), a Transport Layer protocol MUST be used, and an implementer SHOULD use UDP, as it is one of the more compact protocols available in this layer. An implementer SHOULD encode the UDP ports, length, and checksum in base-10 (leading zeros omitted) and the data in Base64 encoding. The Base64 encoding, combined with the UDP checksum, resolves ambiguities with trailing whitespace or non-printable characters.
コンピュータ（例えば、バイナリコンテンツ）によって応答されることを意図したメッセージのために、トランスポート層プロトコルを使用しなければなりません、そして、それはこの層に利用可能なよりコンパクトなプロトコルの一つであるとして、実装者は、UDPを使用すべきです。実装は、UDPポート、長さ、及びベース10のチェックサム（先行ゼロは省略）とBase64エンコードのデータを符号化するべきです。 UDPチェックサムと組み合わせBase64エンコーディングは、空白または非印刷可能文字を末尾との曖昧さを解決します。
The usage of UDP or other protocols that compute a checksum over source and destination addresses necessitates the use of either an IPv4 or IPv6 address as the Source in the ADVERT Protocol. The Destination address 255.255.255.255 MUST be used in the calculation of an IPv4-based checksum, as it has already been specified as a local hardware broadcast that must not be forwarded (RFC 919). For IPv6, the All Nodes link-local multicast destination FF02:0:0:0:0:0:0:1 MUST be used, defined in RFC 4291 [8].
UDPまたはソースと宛先アドレス上のチェックサムを計算する他のプロトコルの使用は、広告プロトコルでソースとしてIPv4またはIPv6アドレスのいずれかの使用を必要とします。既に転送されてはならないローカルハードウェアブロードキャスト（RFC 919）として指定されたように宛先アドレス255.255.255.255は、IPv4ベースのチェックサムの計算に使用されなければなりません。 IPv6のすべてのノードのリンクローカルマルチキャスト宛先にFF02：0：0：0：0：0：0：1 [8] RFC 4291で定義され、使用されなければなりません。
ADVERT Datagram UDP Embedded Sample Data
+-----------------+ +--------+--------+ +--------+--------+
| | |Src Port|Dst Port| | 0 | 80 |
| | +--------+--------+ +--------+--------+
| | | Length |Checksum| | 24 | 62670 |
| UDP Packet | +--------+--------+ +--------+--------+
| | | | | R0VUIC8gSFRUUC8 |
| | | Data | | xLjENCg0K |
| | | | | |
+-----------------+ +-----------------+ +-----------------+
| Source Address | | Source Address | | 203.0.113.8 |
+-----------------+ +-----------------+ +-----------------+
Figure 3: Example of Encapsulating Binary Data in an ADVERT Datagram
図3：広告データグラムでカプセル化バイナリデータの例
Upon receipt, the datagram should be optically scanned into an electronically transmittable form, similar to the methods used in RFC 1149 [9]. If present, any checksums SHOULD be computed and compared with supplied values. If the checksum does not match, the packet MUST be discarded.
受信すると、データグラムは、光学的、電子的に送信可能形式にスキャンしなければならない、RFC 1149で使用される方法に類似する[9]。存在する場合、任意のチェックサムが計算され、供給された値と比較されるべきです。チェックサムが一致しない場合、パケットは捨てなければなりません。
Physical layers always have advantages and disadvantages depending on their condition, maintenance, prevalence, and economic factors; the atmosphere is no different. The protocols defined herein do not specify a TTL specifically because it is often out of their control, and dependent on the conditions present. The intrinsic TTL produces a curve of error rates where, after time, meaning cannot be deciphered from the datagram either because of a non-matching checksum or, in the absence of a checksum (such as the ADVERT protocol), because of an unintelligible transmission. If the Source field is sufficiently distinguishable, the recipient MAY contact the sender for message clarification. RFC 919 is in agreement in stating that broadcasts MUST NOT be assumed to have been reliably delivered.
物理層は常に長所と短所、その状況に応じて、メンテナンス、有病率、および経済的要因を持っています。雰囲気は違いはありません。それは彼らのコントロール外しばしばであり、本条件に依存するので、本明細書に定義されたプロトコルは、具体的にはTTLを指定しないでください。真性TTL時間後、意味がデータグラムから解読のいずれかであるため、非マッチングチェックサムまたは、（例えば広告プロトコルとして）チェックサムの非存在下で、なぜなら不明瞭送信することができず、エラー率の曲線を生成します。ソースフィールドが十分に識別可能である場合、受信者はメッセージの明確化のために、送信者に連絡することができます。 RFC 919は、ブロードキャストが確実に配信されていると想定してはならないことを示すに一致しています。
Reconsidering Figure 3, a broadcast HTTP Request is sent, and recipients should return the request from each of their computer systems that are listening on the requisite port. It is important to remember the security implications of the systems' acceptance of data from unknown senders. It is the responsibility of each organization to utilize host-protection mechanisms and egress filtering to avoid exposing their systems to undue risk or exposing internal or NAT-ed devices.
図3再考、放送のHTTPリクエストが送信され、受信者は、必要なポートで待機している自分のコンピュータ・システムのそれぞれからの要求を返す必要があります。未知の送信者からのデータのシステム受け入れのセキュリティへの影響を覚えておくことが重要です。これは、過度のリスクに自分のシステムを暴露するか、内部またはNAT-EDデバイスの公開を回避するために、ホスト・保護メカニズムと出口フィルタリングを利用する各組織の責任です。
Although it may be easy for an operator to silently discard the packet, it would be inappropriate for a network operator to unilaterally discard data, in the absence of policy. RFC 1087 [10] classifies an action that destroys the integrity of computer-based information as unethical and unacceptable; and the Code of Ethics of SAGE, USENIX, and LOPSA recognize the important of maintaining integrity, reliability, and availability.
操作者が静かにパケットを廃棄することが容易であるかもしれないが、ネットワークオペレータが一方的ポリシーが存在しない場合に、データを破棄することは不適切であろう。 RFC 1087 [10]などの非倫理的および許容できないコンピュータベースの情報の完全性を破壊する作用を分類します。そして、SAGE、USENIX、およびLOPSAの倫理規定は、完全性、信頼性、および可用性を維持するための重要性を認識する。
Information is sent by transmitters producing a specialized form of smoke, most often by emitting a specialized oil onto the exhaust manifold. The oil, held in a pressurized container, is vaporized in a thick white smoke, producing readable display. The makeup of the smoke is often subject to patents, and any organization interested should consult with their attorneys. Further details on transmission on the Physical Layer is beyond the scope of this RFC, but implementers MAY refer to references for help. It is by design that the broadcast mechanism does not result in incompatibilities if implementers choose different Physical Layer implementations.
情報は、排気マニホールドに特化した油を放出することにより、ほとんどの場合、煙の特殊な形態を生成する送信機によって送信されます。加圧容器内に保持された油は、読み取り可能なディスプレイを製造、厚い白煙に気化されます。煙のメイクは、多くの場合、特許権の対象となり、そして関心をお持ちの組織は、彼らの弁護士に相談してください。物理層での送信に関する詳細については、このRFCの範囲を超えていますが、実装者は助けを参照を参照してもよいです。これは、実装が異なる物理層の実装を選択した場合、ブロードキャストメカニズムは非互換性を生じない設計です。
The datagram MUST be displayed in the atmosphere, at an altitude of 7000 to 17000 feet (2133 to 5181 meters). It SHOULD be written using a "skytyping" method, similar to dot-matrix printing (Figure 4). This method will provide better persistence of the datagram in the presence of air currents. Additionally, it provides the ability for parallelism by using additional avionic instruments.
データグラムは7000 17000フィート（2133 5181メートル）の高度で、大気中に表示されなければなりません。これは、ドットマトリックス印刷（図4）と同様、「skytyping」方法を使用して記述する必要があります。この方法では、気流の存在下で、データグラムの優れた持続性を提供します。さらに、それは追加の航空電子機器を使用して、並列処理のための機能を提供します。
####### ####### ####### #######
# # # #
# # # #
# #### # ####
# # # #
# # # #
####### ####### # #
Figure 4: Skytyping Method in the Sky
図4：天空のSkytypingメソッド
The most efficient method for broadcasting a datagram on this link layer is the hire of specialized companies that perform this service on a regular basis. For a large organization interested in using this method frequently, it may be more cost-effective to develop one's own methods.
このリンク層でデータグラムを放送するための最も効率的な方法は、定期的にこのサービスを行う専門企業の雇用です。頻繁にこの方法を使用することに興味を持って大規模な組織の場合は、より費用対効果の自分の方法を開発することであってもよいです。
Transmission ability varies by atmospheric and regional conditions. Adverse conditions, such as an accumulation of moisture or ice crystals in the Physical Layer, may preclude transmission for a period of time. During these periods, it is suggested broadcasts be delayed, as higher-than-expected error rates may occur, and receivers may not be prepared to process the transmission immediately.
伝送能力が大気や地域の条件によって異なります。そのような物理層での水分や氷の結晶の蓄積などの悪条件は、一定期間送信を排除することができます。これらの期間中に、より高い予想よりも誤り率が発生することのように、放送が遅延することが示唆され、そして受信機は直ちに送信を処理するために用意されなくてもよいです。
Additionally, solar radiation conditions affect transmission in a predictable, cyclic manner. Depending on latitude, the medium may be unusable for a lengthy period, during which alternate arrangements must be made.
また、日射条件は、予測可能、周期的に送信に影響を与えます。緯度に応じて、媒体は、代替配置がなされなければならない時に長い期間、のために使用不能とすることができます。
Conditions may worsen before, during, or after a transmission, resulting in higher-than-expected transmission error rates. Regional operators should be familiar with their operating conditions and consider the feasibility of implementing a casual or robust infrastructure on this transmission medium. Some locales lend themselves better to regular operation than others.
条件は、より高い予想以上の伝送エラーレートが得られ、中、又は送信後に、前に悪化してもよいです。地域の事業者は、動作条件に精通していると、この伝送媒体上のカジュアルや堅牢なインフラストラクチャを実現するための実現可能性を検討すべきです。いくつかのロケールでは、他よりも通常の操作に、より良い自分自身を貸します。
[1] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, October 1984.
[1]モーグル、J.、 "放送インターネットデータグラム"、STD 5、RFC 919、1984年10月。
[2] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[2]川村、S.とM.川島、RFC 5952、2010年8月の "IPv6アドレスのテキスト表現のための勧告"。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[4] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[4]綿、M.およびL. Vegoda、 "特殊用途IPv4アドレス"、BCP 153、RFC 5735、2010年1月。
[5] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[5]ブランシェ、M.、 "特殊用途のIPv6アドレス"、RFC 5156、2008年4月。
[6] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[6]イーストレーク第3、D.とA. Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[7] Hooke, A., "Interplanetary Internet", GSAW 2003, <http://sunset.usc.edu/gsaw/gsaw2003/s3/hooke.pdf>.
[7]フック、A.、 "惑星間インターネット"、GSAW 2003、<http://sunset.usc.edu/gsaw/gsaw2003/s3/hooke.pdf>。
[8] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[8] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[9] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, April 1 1990.
[9] Waitzman、D.、 "鳥類キャリア上のIPデータグラムの送信のための基準"、RFC 1149、1990年4月1日に。
[10] Defense Advanced Research Projects Agency and Internet Activities Board, "Ethics and the Internet", RFC 1087, January 1989.
[10]米国防総省の国防高等研究計画庁やインターネット活動委員会、「倫理とインターネット」、RFC 1087、1989年1月。
Author's Address
著者のアドレス
Thomas Ritter PO Box 541 Hoboken, NJ 07030 USA
トーマス・リッター私書箱541ホーボーケン、NJ 07030 USA
EMail: tom@ritter.vg URI: http://ritter.vg
電子メール：URI tom@ritter.vg：http://ritter.vg