“Joke and some truth”: a couple of interesting RFCs “practically” without practical use

RFC format exist since 1969 – it was introduced during the discussion of ARPANET. Then engineer Steve Crocker wrote RFC 1 about the operation of the host software.

More than 50 years have passed since then, but Request for Comments is still on the way – published ~ 9 thous. documents on network protocols, data storage models and encryption algorithms.

In this variety, there are RFCs that have no practical application. They were written for the most part just for fun… Today we will tell you about some of the findings from this area.

Photo – Braydon anderson – Unsplash

RFC 8771

It describes the internationalized deliberately unreadable network notation (I-DUNNO). According to the authors, the document is intended to balance the following situation:

DNS was introduced in the early 80’s. It has made access to network resources more convenient, but engineers “still invade” communications machine-to-machine: read and manually register IP addresses. The task of I-DUNNO is to prevent this activity and, finally, to assign the work with addresses to the computing systems.

I-DUNNO uses encoding UTF-8to 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 that is prohibited. IDNA2008

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


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 fail – quantum bugs

Photo – Umberto – Unsplash

Multipath TCP for throughput estimation calculated alpha value. 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 protocol LEDBATused by Apple and BitTorrent will start transmitting packets as quickly as possible and clog up 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. You can use as a reference RFC 2626 – about the year 2000 problem. Then it will remain to update all untrusted code. This process may be delayed, given that the problem of 2038 for Linux was solved for several years and finished to rewrite the kernel code only this year.

More interesting materials in our corporate blog:

“Found, saw, received”: unusual invitations for an interview
Development team suggests switching to UTF-8
How the Domain Name System Evolved: The ARPANET Era
A selection of books on cybersecurity

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *