!!! Overview
[{$pagename}] is defined in [RFC 1149] 


[{$pagename}] was initially described in [RFC 1149], a [Request For Comment] ([RFC]) issued by the [Internet Engineering Task Force] ([IETF]), written by D. Waitzman, and released on April 1, [1990|Year 1990]. It is one of several April Fools' Day Request for Comments.

!!Status of this Memo
This memo describes an [experimental] method for the encapsulation of [IP] [datagrams] in avian carriers.  This specification is primarily useful in [Metropolitan Area Networks].  This is an [Experimental], not recommended standard.  Distribution of this memo is unlimited.

!! Overview and Rationale
Avian carriers can provide high [latency], low throughput, and low altitude service.  The connection topology is limited to a single [Point-to-Point Protocol] path for each carrier, used with standard carriers, but many carriers can be used without significant interference with each other, outside of early spring.  This is because of the 3D ether space available to the carriers, in contrast to the 1D ether used by [IEEE 802.3].  The carriers have an intrinsic [Collision Resistance] avoidance system, which increases availability.  Unlike some [network] technologies, such as [packet] radio, communication is not limited to line-of-sight distance.  Connection oriented service is available in some cities, usually based upon a central hub topology.

!! [Frame] Format
The [IP] [datagram] is printed, on a small scroll of paper, in [hexadecimal], with each [octet] separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram's edges.  The bandwidth is limited to the leg length.  The [MTU] is variable, and paradoxically, generally increases with increased carrier age.  A typical [MTU] is 256 milligrams.  Some [datagram] [Padding bit] may be needed.\\
Upon receipt, the duct tape is removed and the paper copy of the [datagram] is optically scanned into a electronically transmittable form.

!! Discussion
Multiple types of service can be provided with a prioritized pecking order.  An additional property is built-in worm detection and eradication.  Because IP only guarantees best effort delivery, loss of a carrier can be tolerated.  With time, the carriers are self regenerating.  While broadcasting is not specified, storms can cause data loss.  There is persistent delivery retry, until the carrier drops.  Audit trails are automatically generated, and can often be found on logs and cable trays.

!! [Security Considerations]
Security is not generally a problem in normal operation, but special measures must be taken (such as data encryption) when avian carriers are used in a tactical environment.

[{$pagename}] has updates in [RFC 2549] and [RFC 6214]

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [IP_over_Avian_Carriers|Wikipedia:IP_over_Avian_Carriers|target='_blank'] - based on information obtained 2018-11-10-