Independent Submission T. Ritter
Request for Comments: 6217 1 April 2011
Category: Experimental
ISSN: 2070-1721
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为基础，描述了一种更有效的路由机制，用于使用替代链路层发送到多个局域网（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.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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 ....................................................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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
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（区分服务代码点）、ECN（显式拥塞通知）、跃点限制等。因此，我们可以设计更紧凑的协议：
+-------------------------------+-----------------------------+
| Content | Source |
+-------------------------------+-----------------------------+
+-------------------------------+-----------------------------+
| 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
Source-邮件的发件人。传输必须选择源的以下表示形式之一：-点十进制表示法中的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.
源字段必须存在——若要匿名发送消息，发送者必须使用不同类型的保留项之一。保留的电话号码条目因地区而异；例如，在北美，它们是555-0100到555-0199。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.
与网络层类似，传输层协议能够省略现有传输层协议中使用的几个结构。考虑TCP——序列、确认，并且许多标志被丢弃，因为在广播消息中将不存在SYN、SYN/ACK或ACK握手。类似地，窗口大小和紧急值等字段（主要是为了路由器制造商的利益而创建的）在这种媒体中也是不必要的。
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 |
+------------------------------------------------------------+
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编码的有效载荷，应该使用默认UTF编码，以便数据包是人类可读的。这将最大限度地减少意外误解。这种传输结构最容易传递人类可解析的消息。
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，因为它是该层中可用的更紧凑的协议之一。实现者应该以base-10（省略前导零）对UDP端口、长度和校验和进行编码，并以Base64编码对数据进行编码。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或其他协议计算源地址和目标地址的校验和时，必须在广告客户协议中使用IPv4或IPv6地址作为源地址。在计算基于IPv4的校验和时必须使用目标地址255.255.255.255，因为它已被指定为不得转发的本地硬件广播（RFC 919）。对于IPv6，必须使用RFC 4291[8]中定义的所有节点链路本地多播目标FF02:0:0:0:0:0:1。
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 |
+-----------------+ +-----------------+ +-----------------+
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通常不受其控制，并且取决于当前的条件。内在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设备。
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米）的大气中显示。它应该使用“skytyping”方法编写，类似于点阵打印（图4）。这种方法将在存在气流的情况下提供更好的数据报持久性。此外，通过使用额外的航空电子仪器，它还提供了并行能力。
####### ####### ####### #######
# # # #
# # # #
# #### # ####
# # # #
# # # #
####### ####### # #
####### ####### ####### #######
# # # #
# # # #
# #### # ####
# # # #
# # # #
####### ####### # #
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] Mogul，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] Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3] Berners Lee，T.，Fielding，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] Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[5] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[5] Blanchet，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] Eastlake 3rd，D.和A.Panitz，“保留顶级域名”，BCP 32，RFC 26061999年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.Deering，“IP版本6寻址体系结构”，RFC 42912006年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号，邮编07030
EMail: tom@ritter.vg
URI: http://ritter.vg
EMail: tom@ritter.vg
URI: http://ritter.vg