Показаны сообщения с ярлыком 1 апреля. Показать все сообщения
Показаны сообщения с ярлыком 1 апреля. Показать все сообщения

Магия IETF: ASCII Art

В IETF множество разных штук зависит от магии. Без волшебной пыльцы или других дополнительных действий из мира фей, Интернет просто бы никогда не заработал. Тролли должны быть голодными. Единороги обеспечивают работоспособность алгоритма SDN PCE.

Очередной первоапрельский RFC 8140 от 2017 года прекрасен как первый снег и наполнен благородным безумием до краёв.

RFC от 1 апреля 2015 года

В 2015 году коллекция шутливых RFC обогатилась двумя новыми экземплярами:

RFC 7511 предлагает ввести в протокол IPv6 дополнительную опцию маршрутизации, которая позволит несчастным IP-пакетам получать как можно больше свежего воздуха, избегая передачи по меди или оптике в пользу беспроводных сред. Вероятно, от этого IP-пакеты станут более счастливыми и количество добра в мире увеличится.

RFC 7514 предлагает ввести в ICMP новое ообщение "Really Explicit Congestion Notification" (RECN), которое можно использовать в качестве совета уменьшить скорость передачи данных для таких устройств, которые не понимают нормального языка игнорируют потерю пакетов или сообщения Explicit Congestion Notification (ECN). Новый стандарт предлагает доводить такое сообщение аж до специалиста, ответственного за передачу пакетов на конкретном узле и даже выдавать аудио-сигнализацию или показывать pop-up сообщение, если подсистема text-to-speach отключена или звук выключен

April1: HTCPCP-TEA и NSA Certificate Extension

Фрагмент логотипа сайта http://www.rfc-editor.org/
В этом году на 1 апреля RFC опубликовал два новых чудесных документа:

Первый из них RFC 7168, озаглавленный The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA), повествует о нелёгкой судьбе кофейников, предоставляющих сетевые функции приготовления кофе по протоколу HTCPCP, но не умеющих при этом варить чай. К слову сказать, протокол HTCPCP тоже зафиксирован в RFC 2324 ещё 1 апреля 1998 года. Так вот, HTCPCP-TEA определяет дополнительные коды возврата, например, HTTP 300 Multiple Options возвращается кофеваркой, если URL, по которому обратился клиент, может запускать процесс приготовления и того и другого напитка. Кроме того, этот документ стандартизирует новый тип MIME message/teapot на случай, когда клиент, обращающийся по сети к кофеварке хочет непременно чаю (а если ещё да с мягкими французскими булочками,- как быть тогда?)

Второй первоапрельский RFC 2014 года,- RFC 7169 The NSA (No Secrecy Afforded) Certificate Extension,- предлагает добавить в сертификаты новое расширение "Секретность не поддерживается" на тот случай когда владелец сертификата не уверен, сможет ли он сохранить свои приватные ключи действительно приватными, или даже если прямо хочет сообщить, что приватные ключи публично доступны. Вообщем,- секретность,- это сложно.

FTL Communications

Очередной первоапрельский RFC: Соглашения для коммуникаций на скорости быстрее света (Design Considerations for Faster-Than-Light (FTL) Communication).

Автор упоминает некоторые аспекты взаимодействии пространства-времени при околосветовых скоростях и делает смелое предположение, что при скорости быстрее света время обращается вспять. Это может привести к таким неожиданным эффектам, что пакеты данных могут будут доставлены получателю раньше, чем они были посланы отправителем. Таким образом, существующий дизайн протокола TCP/IP не совсем подходит для передачи данных в среде FTL и требует доработки.

Помимо некоторых RFC, требующих переосмысления, автор рекомендует задуматься над соглашениями и ограничениями путешествий во времени, так как, по его мнению, FTL-коммуникации неминуемо приведут к возможности путешествий во времени:
That said, FTL communication might lead to FTL travel, where we can travel into the past. It may be necessary to start working on this yesterday.

Широковещательная передача через атмосферу

Очередной первоапрельский RFC 6217: Regional Broadcast Using an Atmospheric Link Layer :-)

Предлагают использовать в качестве среды передачи атмосферу. В IPv4/6 слишком много лишних заголовков (Destination, TTL (Time to Live), DSCP (Diffserv Code Point), ECN (Explicit Congestion Notification), Hop Limits и т.д.). От этого всего можно отказаться. Оставим только необходимое:

      +-------------------------------+-----------------------------+
      |            Content            |           Source            |
      +-------------------------------+-----------------------------+

                     Рисунок 1: Формат датаграммы

Content - Поле переменной длины, содержащее инкапсулированные данные протоколов верхнего уровня,
Source - источник данных
В качестве источника могут выступать:
  • IP - адрес
  • номер телефона в формате E.123
  • IPv6 адрес в стандартной нотации (RFC 5952)
  • URI (RFC 3986)
  • географический адрес
  • и так далее...
Типичным примером использования такого вида связи может быть трансляция рекламных сообщений, типа такого:
 Content                          Source
   +------------------------------------------------------------+
   | Lobster Dinner - only $14.99    500 Boardwalk, Pt Pleasant |
   +------------------------------------------------------------+

                 Figure 2: Example ADVERT Datagram

Жгут ребята :-)

Настроение TCP-пакетов

Для того, чтобы добавить немного антропоморфности потокам бит сетях всего мира, специалисты из Google R. Hay и W. Turkal предлагают использовать опции TCP для передачи настроения. Вольный перевод:

Сами по себе пакеты не могут чувствовать. Они созданы только для передачи данных от одного хоста к другому. Тем не менее, в некоторых ситуациях можно добавить им немного эмоциональности. Например, пакет, который пришлось отправить повторно (из-за того, что для него не было получено подтверждение ACK), может быть описан как "сердитый" или "разочарованный"


Предложение гугловцев зафиксировано в RFC 5841 1 апреля 2010 года, и содержит описание TCP Options для использования, возможные Use Cases, психологические характеристики различных пакетов (счастливые, удивлённые и смущённые пакеты, и даже апатичные, ага) и отсылки к используемой литературе и дополняемым RFC

IPv6 поверх социальных сетей (IPoSN)

В догонку к трехбуквенным акронимам и шуткам в RFC, в этом году появился ещё один RFC 1 апреля: IPv6 over Social Network (IPoSN). Автор предлагает следующий концепт:

  • считать каждого пользователя маршрутизатором, у которого есть как минимум loopback интерфейс;

  • каждого друга или связь между пользователями использовать как point-
    to-point.


Таким образом, на уровне социальной сети обеспечиваем хорошую связность сети. Осталось понять что у нас с пропускной способностью ;-)

ITшники изволят шутить

Известные многим профессиональным IT-специалистам документы RFC содержат много нужной информации. А так-же не очень нужной (конкретному спецу), а иногда и откровенно шутливой. Существует энное количество RFC, опубликованных 1 апреля и содержащих откровенные фейки. Чего стоит, например, RFC 2795 The Infinite Monkey Protocol Suite (IMPS),-описание протокола управления бесконечным количеством обезъян за бесконечным числом печатных машинок, выпущенный 1 апреля 2000 года, или шутка этого (2009) года,- RFC 5313 , стандартизация трёхбуквенных сокращений:

Acronym Expansion Reference
--------+-------------------------------------+-----------
TLA Two Letter Acronym [RFC5513]
TBD Two Be Deleted [RFC5513]
RFC Ready for Compost [RFC5513]
PoS Not particularly good [RFC5513]
VPN Very possibly no use [RFC5513]
TCP Totally bad proposal [RFC5513]
USA Universal Source of Acronyms [RFC5513]
NBG This document [RFC5513]
BCP Badly construed proposal [RFC5513]


Нормально люди шутят...