はじめに

この文書は RFC6217 を勉強と好奇心のため適当に訳したものです。
翻訳の正確さは全く保証しません。
誤字誤訳等の指摘はいつでも大歓迎です。

Regional Broadcast Using an Atmospheric Link Layer（大気リンク層による地域ブロードキャスト）

Independent Submission
Request for Comments: 6217
Category: Experimental
ISSN: 2070-1721

T. Ritter
1 April 2011

Abstract（要旨）

Broadcasting is a technology that has been largely discarded in favorof 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 を基に、代替リンク層を使用した複数のローカルエリアネットワーク (LAN) またはメトロポリタンエリアネットワーク (MAN) 向けのブロードキャストパケットのより効率的なルーティングメカニズムについて説明する。
ネットワーク機器の輻輳を大幅に軽減し、物理的なインフラの追加投資も必要ない。

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.

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.

この文書はインターネット標準化過程の仕様ではなく、情報提供の目的で発行されたものである。

この文書は、他のいかなるRFCストリームとも無関係に、RFC シリーズに貢献するものである。
RFC エディターは自らの裁量でこの文書の公開を選択し、実装や配備のための価値について何ら表明するものではない。
RFC エディターによって発行が承認された文書は、どのレベルのインターネット標準の候補にもならない；RFC 5741 の 2 章を参照のこと。

この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、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.

   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.

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

1. Introduction（序論）

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.

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 919 [1] は、ローカルネットワークにパケットをブロードキャストするための方法を定義している。
これは、データリンク層が効率的なブロードキャストをサポートすることを前提にしている。
RFC 919 が書かれてから数年の間に、ローカルエリアネットワークは指数関数的に大きくなり、地理的にローカルでないことも多くなっている。

この RFC は、地理的にローカルなネットワークや、可視性によってはメトロポリタンエリアネットワーク全体に効率的に拡張する新しいデータリンクレイヤーを提案している。
異なる伝送媒体を使用することにより、ブロードキャストトラフィックは、現在のネットワーク間またはネットワーク内のルーティングされたトラフィックに影響を与えない。
また、すべての主要都市や、意外にも地方や過疎地でも使用されている、広く利用可能なインフラを利用することができる。

2. Terminology（用語解説）

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 に記載されている通りに解釈されるものとする。

3. Limitations（制限事項）

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.

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.

この RFC は、すべての問題に対する解決策を提案するものではない。
RFC 919 が信頼性に無頓着であったように、私たちもホストが送信したデータグラムを受信することを保証していない。
ホストは、天候、視線、睡眠パターン、注意力散漫など、さまざまな理由でパケットを受信しないことがある。
そのため、ベストエフォート型の配信方法がとられている。

これらの制限は提案の有用性に影響を与えるが、この方法で情報を配信することに真剣な組織は、比較的小さな困難でこれらの障害を克服することができる。

4. Physical Layer（物理層）

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.

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.

使用される物理層は主に窒素と酸素で構成され、海面では101.3キロパスカルの圧力だが、使用高度ではその半分程度まで低下する。
伝送媒体には、局所的な形成特性により、微小な残留物や微量元素が存在することがある。

この残留物には、アルゴン、二酸化炭素、ネオン、ヘリウム、塩化物アニオン、二酸化硫黄、その他非常に低い混合率で発生する分子が含まれることがある。
ある程度のガス状の一酸化二窒素が存在するのが一般的である。
データグラム伝送の詳細は後述するが、これらの微量分子は通常、ブロードキャストに支障をきたすことはない。

5. Frame Format in the OSI Model（OSIモデルにおけるフレームフォーマット）

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.

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.

将来の適応のために十分な柔軟性を持ちながら、効率的なサイズを保つプロトコルを設計することは常に課題であり、この媒体では、ヘッダのサイズと複雑さが特に懸念されるところである。
このため、この RFC はデータリンク層、ネットワーク層、トランスポート層の推奨事項を提案している。

実装はネットワーク層とトランスポート層のために、彼らのニーズに合ったどのようなプロトコルを使ってもよい (MAY)。
異なるプロトコルがメッセージの受信者によってどのように解釈されるかを考慮し、利用可能な最も効果的なプロトコルを選択すべきである　(SHOULD)。
定義されたプロトコルは、解釈のしやすさを最大限に考慮し設計されているので、その使用が推奨される。

5.1. Data Link Layer（データリンク層）

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.

データリンク層は隣接するノード間のデータグラムの伝送に主に関係し、ここではブロードキャスト伝送のみをサポートするため不要である。
実装者はリンク層プロトコルでパケットをカプセル化してはならない(MUST NOT)。

5.2. Network Layer（ネットワーク層）

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: 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:

ネットワーク層のプロトコルを設計する場合、この層の既存のプロトコルを考慮し、その長所と短所を参照することは理にかなっている。
IPv4/6 を見ると、そのヘッダ構造には、今回の目的には不要なフィールドがいくつか含まれていることがわかる：Destination、TTL (Time to Live)、DSCP (Diffserv Code Point)、ECN (Explicit Congestion Notification)、Hop Limits、などである。
以下のように、よりコンパクトなプロトコルを設計することができる。

      +-------------------------------+-----------------------------+
      |            Content            |           Source            |
      +-------------------------------+-----------------------------+

                     Figure 1: Layout of the Datagram

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

Content - 高次プロトコルのカプセル化を含む可変長のフィールド
Source - メッセージの送信者
送信時は、以下の Source の表現のうち 1 つを選択しなければならない (MUST)
- ドット付き10進数表記による IPv4 アドレス (例:192.168.1.1)
- 標準的な表記法による IPv6 アドレス (RFC 5952 [2])
- E.123 表記による電話番号
- 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.

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.

Source フィールドは必ず存在しなければならない (MUST)。メッセージを匿名で送信するために、送信者は異なるタイプの予約済みエントリーのうちの 1 つを使用しなければならない (MUST)。
電話番号の予約項目は地域によって異なる。たとえば、北米では 555-0100 から 555-0199 である。
IPv4 (RFC 5735 [4])、IPv6 (RFC 5156 [5])、および URI (RFC 2606 [6]) の予約エントリは、それぞれのRFCで見つけることができる。
同種の通信特性によって定義される地域という概念は、すでに [7] で提唱されているので、地理的なアドレス指定に関するあいまいさは、コミュニティ標準によって解決されるかもしれない。

メッセージは特定の地理的地域に送信されるため、送信元アドレスにはより寛容な対応が可能であるが、より上位のプロトコルによって要件を課される場合がある。

このプロトコルを、Asynchronous Dumb Visual Exchange of Raw Transmissions または ADVERT と呼んでいる。

5.3. Transport Layer（トランスポート層）

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.

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:

ネットワーク層と同様に、トランスポート層プロトコルでは、既存のトランスポート層プロトコルで使用されているいくつかの構成を省略できる。
TCP を考えてみる ―― ブロードキャストメッセージには SYN、SYN/ACK、ACK のハンドシェイクがないため、シーケンス、確認応答、フラグの多くが省略できる。
同様に、ウィンドウサイズや緊急 (主にルーターメーカーの利益として作成された) などのフィールドは、このメディアでは不要である。

実際、プレーンテキストメッセージの場合、コンテンツはトランスポートプロトコルを必要とせずに ADVERT プロトコルに直接埋め込まれるべきである (SHOULD)。
次のパケットについて考えてみる：

              Content                          Source
   +------------------------------------------------------------+
   | Lobster Dinner - only $14.99    500 Boardwalk, Pt Pleasant |
   +------------------------------------------------------------+

                 Figure 2: Example ADVERT Datagram

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 エンコードされたペイロードの場合、パケットが人間に読めるように、デフォルトの UTF エンコードを使用すべきである (SHOULD)。
これは、偶発的な誤読を最小限に抑えるためである。
この伝送構造は、人間が解析可能なメッセージに最も適している。

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.

コンピュータに応答されることを意図したメッセージ (例えば、バイナリコンテンツ) については、トランスポート層のプロトコルが使用されなければならず (MUST)、実装者はこの層で利用できるよりコンパクトなプロトコルである UDP を使用すべきである (SHOULD)。
実装者は UDP のポート、長さ、チェックサムを10進数 (先頭のゼロは省略) で、データを Base64 でエンコードすべきである (SHOULD)。
Base64 エンコーディングと UDP チェックサムの組み合わせは、末尾のホワイトスペースや印字不可能な文字による曖昧さを解決する。

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 またはソースとデスティネーションアドレス上でチェックサムを計算する他のプロトコルの使用は、ADVERT プロトコルのソースとして IPv4 または IPv6 アドレスのいずれかを使用することが必要である。
宛先アドレス 255.255.255 は、転送してはならないローカルハードウェアブロードキャストとしてすでに指定されているため、IPv4 ベースのチェックサムの計算で使用されなければならない (MUST) (RFC 919)。
IPv6 の場合、RFC 4291 [8] で定義されている全ノードリンクローカルマルチキャストデスティネーション FF02:0:0:0:0:1 が使用されなければならない (MUST)。

     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

6. Reception（受信）

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] で使用されている方法と同様に、電子的に送信可能な形で光学的にスキャンされるべきである。
存在する場合、あらゆるチェックサムが計算され、提供された値と比較されるべきである (SHOULD)。
チェックサムが一致しない場合、そのパケットは破棄されなければならない (MUST)。

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 内であっても、時間が経つにつれ、データグラムから意味を解読できなくなり、エラー率が急激に上昇することになる ―― チェックサムが一致しないため、またはチェックサムがない場合 (ADVERT プロトコルなど)、送信内容の意味が理解できなくなるため。
Source フィールドが十分に区別可能な場合、受信者はメッセージの明確化のため送信者に連絡してもよい (MAY)。
RFC 919 は、ブロードキャストが確実に配送されたと仮定してはならない (MUST NOT) と述べている点で一致している。

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 されたデバイスを暴露することを避けるために、ホスト保護メカニズムやイグレスフィルタリングを利用することは、各組織の責任である。

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 の倫理綱領では、完全性、信頼性、可用性の維持が重要であることを認めている。

7. Datagram Transmission（データグラム伝送）

7.1. Chemical Approach to the Atmospheric Link Layer（大気リンク層への化学的アプローチ）

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 の範囲外であるが、実装者は参考文献を参照してもよい。
実装者が異なる物理層の実装を選択した場合でも、ブロードキャストメカニズムが非互換性をもたらさないように設計されている。

7.2. Location

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 メートル) の大気中で表示されなければならない (MUST)。
ドットマトリクス印刷に似た「skytyping」方式で書かれるべきである (図4)。
この方法は、気流の存在下でデータグラムをより持続させることができる。
さらに、追加の航空電子工学機器を使用することにより、並列化する能力を提供する。

                #######   #######   #######   #######
                   #      #            #      #
                   #      #            #      #
                   #      ####         #      ####
                   #      #            #      #
                   #      #            #      #
                #######   #######      #      #

               Figure 4: Skytyping Method in the Sky

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.

このリンク層でデータグラムをブロードキャストする最も効率的な方法は、このサービスを定期的に実行する専門会社を雇うことである。
この方法を頻繁に使用することに関心のある大規模な組織では、独自の方法を開発する方が費用対効果が高いかもしれない。

7.3. Physical Layer Conditions（物理層に関する考慮事項）

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.

送信前、送信中、送信後に状況が悪化し、予想以上の送信エラー率が発生することがある。
地域通信事業者は、その運用状況をよく把握し、この伝送媒体にカジュアルまたは堅牢なインフラを導入することの実現可能性を検討する必要がある。
地域によっては、通常の運用に適しているところもある。

8. References

8.1. Normative References

   [1]  Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919,
        October 1984.

8.2. Informative References

   [2]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
        Address Text Representation", RFC 5952, August 2010.

   [3]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
        January 2005.

   [4]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153,
        RFC 5735, January 2010.

   [5]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April
        2008.

   [6]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names",
        BCP 32, RFC 2606, June 1999.

   [7]  Hooke, A., "Interplanetary Internet", 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.

   [9]  Waitzman, D., "Standard for the transmission of IP datagrams on
        avian carriers", RFC 1149, April 1 1990.

   [10] Defense Advanced Research Projects Agency and Internet
        Activities Board, "Ethics and the Internet", RFC 1087, January
        1989.

Author's Address

   Thomas Ritter
   PO Box 541
   Hoboken, NJ 07030
   USA

   EMail: tom@ritter.vg
   URI:   http://ritter.vg