Just for fun: a couple of entertaining RFCs

The RFC format has existed since 1969 - it was introduced during the discussion on ARPANET. Then engineer Steve Crocker wrote RFC 1 about how host software works.



More than 50 years have passed since then, but Request for Comments is still in circulation - ~ 9 thousand documents have been published on network protocols, data storage models and encryption algorithms.



In this variety, there are RFCs that have no practical application. They were written mostly as a joke . Today we will tell you about some of the findings from this area.





Photo - Braydon Anderson - Unsplash



RFC 8771



The Internationalized Intentionally Unreadable Network Notation ( I-DUNNO ) is described here . According to the authors, the document aims to balance the following situation:



In the early 80s, the DNS was introduced . It has made accessing network resources more convenient, but engineers still "invade" machine-to-machine communications by reading and manually writing IP addresses. The task of I-DUNNO is to discourage this activity and, finally, to assign the work with addresses to the computer systems.



I-DUNNO uses UTF-8 encodingto obfuscate IP addresses and make them harder for humans to read. Code points are represented by one to four octets, and the sequence itself contains at least one character prohibited by IDNA2008 .



As an example, the authors of RFC 8771 cite the transformation of the IPv4 address 198.51.100.164. First, it is written as a 32-bit string:



11000110001100110110010010100100


Then translated into symbolic form:



1100011 -> U+0063 ( c)
0001100 -> U+000C (   form feed)
1101100 -> U+006C ( l)
10010100100 -> U+04A4 (   «»)


The reverse conversion algorithm is not specified because "computers know what to do and people shouldn't even try."


RFC 8774



This document describes the special errors that will arise in the quantum networks of the future. Information in them is transmitted through fiber-optic cables using qubits - polarized photons. The author of RFC 8774 writes that after the massive introduction of such networks, the value of the packet transmission time can be equal to zero. This fact will lead to failures on the Internet, since the classical network infrastructure and protocols are not designed to work with such timing.



Only a few protocols are prepared for the 0-RTT situation: TFO , TLS 1.3, and QUIC . Many others will work with bugs - quantum bugs .





Photo - Umberto - Unsplash



Multipath TCP for bandwidth estimationthe alpha value is calculated . At one of the stages, it is necessary to divide by RTT, which is impossible with a round-trip delay of zero. In turn, the LEDBAT protocol used by Apple and BitTorrent will start transmitting packets as quickly as possible and clog the channel, although it should limit the network load.



To solve the problem, the author of RFC 8774 suggests starting with a complete list of protocols that are prone to quantum bugs. As a reference, you can use RFC 2626 - about the year 2000 problem. Then it will remain to update all untrusted code. This process may be delayed, given that in 2038 the problem solved several years for Linux and finished rewriting the kernel code only this year.






:



«, , »:

UTF-8

: ARPANET









All Articles