RFC 6217
Regional Broadcast Using an Atmospheric Link Layer
RFC 6217 🎀 Regional Broadcast Using an Atmospheric Link Layer
okay bestie, let's get the basics down first 💅
- Number: RFC 6217
- Title: Regional Broadcast Using an Atmospheric Link Layer
- Author: T. Ritter
- Date: 1 April 2011 📅
- Category: Experimental 🧪 (so it's not a standard, just an experiment!)
- Stream: Independent Submission
- ISSN: 2070-1721
- Obsoletes / Updates: the header doesn't list either one, so this RFC doesn't obsolete or update anything 🌸
Abstract ✨
okay so broadcasting has kinda been pushed to the side in favor of stuff like multicast, which is giving "the new girl got the spotlight" energy 😭 this doc builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets headed to multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs), using an alternative link layer. it significantly reduces congestion on network equipment and doesn't need any extra physical infrastructure investment. the glow-up is real 💖
Status of This Memo 📚
this one isn't an Internet Standards Track spec. it's just published for informational purposes 🦋
it's a contribution to the RFC Series, independent of any other RFC stream. the RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741. so no, this isn't getting a standards badge 🙃
if you want current status info, any errata, or a way to give feedback, check 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, obviously 🔒
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. please actually read these, bestie, because 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 .....................................81. Introduction 🧚
okay so RFC 919 [1] defines a method for broadcasting packets to a local network. it assumes that data link layers support efficient broadcasting. since RFC 919 was written, Local Area Networks have grown exponentially in size, and honestly? they're often not geographically local anymore 😭
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 doesn't impact current inter- or intra-network routed traffic. it also uses a widely available infrastructure that's in use in all major cities and, surprisingly, rural and under-developed locations too 🌸
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. these are the official vibes, so read them carefully 🎀
3. Limitations 🙈
this RFC doesn't propose solutions to all problems, and that's okay. just like RFC 919 wasn't concerned with reliability, we also don't guarantee that hosts receive the datagrams sent. hosts may not receive packets for a bunch of reasons, like weather conditions, line of sight, sleep patterns, and distraction 💀 a best-effort delivery approach is taken.
these limitations do impact how useful the proposal is, but organizations that are serious about distributing information this way can overcome these obstacles with relatively little difficulty 💪
4. Physical Layer ☁️
the physical layer is made up primarily of nitrogen and oxygen, at a pressure of 101.3 kilopascal at sea level. it drops 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's common for there to be some degree of gaseous dihydrogen monoxide present 💧 (yes, that's water, and yes, I'm laughing too 😭). these trace molecules usually don't impede the broadcast, though more details on datagram transmission follow 🦋
5. Frame Format in the OSI Model 🧩
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, the 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 here were designed for maximum ease of interpretation, so their use is encouraged 💖
5.1. Data Link Layer 🔗
the Data Link Layer is primarily concerned with transmitting datagrams between adjacent nodes. it's unnecessary here since we only support broadcast transmission. implementers MUST NOT encapsulate packets in a link layer protocol 🚫
5.2. Network Layer 🌐
when designing a protocol for the Network Layer, it makes sense to look at existing protocols in this layer and reference their strengths and weaknesses. looking at IPv4/6, we can see their header structures include several fields that are 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:
+-------------------------------+-----------------------------+
| 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:
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're 555-0100 to 555-0199. reserved entries for IPv4 (RFC 5735 [4]), IPv6 (RFC 5156 [5]), and URIs (RFC 2606 [6]) can be found in their respective RFCs. the concept of a region defined by homogeneous communication characteristics has already been put forward in [7], so geographic addressing ambiguities may be resolved by community standards 🌍
because the message is sent to a specific geographical region, there's more leniency 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 🦋 (yes, the acronym was clearly the main character goal)
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, since 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 for a transport protocol. consider this packet:
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.
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, since it's 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 ✨
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, since 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, as defined in RFC 4291 [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 🧚♀️
6. Reception ✨
okay so bestie, picture this: when a datagram finally lands, it gets optically scanned into something electronic, kind of like the trick from RFC 1149 [9] 📸. If there are any checksums, you SHOULD compute them and compare them with the supplied values 🧮. And if the checksum doesn't match? 💀 The packet MUST be discarded. No exceptions, no drama, it's gone.
Physical layers are always giving pros and cons depending on their condition, upkeep, how common they are, and money stuff, and the atmosphere is absolutely no different 🌦️. That's why these protocols don't set a TTL, because it's usually out of their hands and depends on whatever the conditions are doing that day 🤷♀️. The intrinsic TTL makes a curve of error rates where, after a while, the meaning just can't be decoded from the datagram 😭. Maybe the checksum doesn't match, or if there's no checksum (like in the ADVERT protocol), the transmission is just unintelligible. If the Source field is distinct enough, the recipient MAY contact the sender to clarify the message 📞. RFC 919 agrees that broadcasts MUST NOT be assumed to have been reliably delivered 🙈.
Now, looking back at Figure 3, a broadcast HTTP Request goes out, and recipients should send the request back from each of their computer systems that are listening on the required port 📮. Be careful, though, because accepting data from unknown senders has real security implications 🔐. It's each organization's job to use host-protection mechanisms and egress filtering so they don't expose their systems to undue risk or expose internal or NAT-ed devices 🛡️.
Even though it might be easy for an operator to quietly drop the packet, it would be inappropriate for a network operator to unilaterally discard data without policy backing it up 🚫. RFC 1087 [10] calls any action that destroys the integrity of computer-based information unethical and unacceptable, and the Code of Ethics of SAGE, USENIX, and LOPSA recognizes the important of maintaining integrity, reliability, and availability 👑.
7. Datagram Transmission 🦋
7.1. Chemical Approach to the Atmospheric Link Layer 🧪
Information gets sent by transmitters producing a specialized form of smoke, most often by emitting a specialized oil onto the exhaust manifold 💨. The oil sits in a pressurized container, gets vaporized into a thick white smoke, and that produces a readable display 🎀. The makeup of the smoke is often subject to patents, so any organization interested should consult their attorneys ⚖️. Further details on transmission on the Physical Layer are beyond the scope of this RFC, but implementers MAY refer to references for help 📚. By design, the broadcast mechanism does not result in incompatibilities if implementers choose different Physical Layer implementations 🌈.
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 gives better persistence of the datagram in the presence of air currents 🌬️. Plus, it allows parallelism by using additional avionic instruments ✈️.
####### ####### ####### #######
# # # #
# # # #
# #### # ####
# # # #
# # # #
####### ####### # #
Figure 4: Skytyping Method in the SkyThe most efficient method for broadcasting a datagram on this link layer is hiring specialized companies that do this service regularly 💼. For a large organization using this method frequently, it may be more cost-effective to develop one's own methods 💅.
7.3. Physical Layer Conditions 🌤️
Transmission ability changes with atmospheric and regional conditions 🌧️. Rough conditions, like moisture or ice crystals building up in the Physical Layer, may stop transmission for a while 🧊. During those periods, it is suggested that broadcasts be delayed, since higher-than-expected error rates may happen and receivers may not be ready to process the transmission right away ⏳.
Also, solar radiation affects transmission in a predictable, cyclic way ☀️. Depending on latitude, the medium may be unusable for a long stretch, and during that time alternate arrangements must be made 🗺️.
Conditions can get worse before, during, or after a transmission, which leads to higher-than-expected transmission error rates 😵. Regional operators should know their operating conditions and consider whether a casual or robust infrastructure on this transmission medium is feasible 🏗️. Some locales are just better suited for 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📦 where this page comes from
- ietf: rfc6217 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms