Протоколы и стандарты Internet

Продолжающееся быстрое развитие Internet, протоколов и стандартов, связанных с Сетью, требует систематизации и упорядочения достигнутых результатов. Этой цели служат периодически обновляемые документы, издаваемые Управляющим советом по вопросам архитектуры Internet (IAB - Internet Architecture Board). Однако, несмотря на многообразие этих документов, ни один из них не дает достаточно полной и ясной картины о статусе выпускаемых документов и стадиях их разработки. Даже в совокупности они дают очень слабое представление о взаимоотношениях между протоколами и стандартами Internet.

Общая их классификация имеет следующий вид:

1. RFC Index (перечень RFC - Request for Comments) - список всех изданных RFC в порядке возрастания номеров, дополняемый по мере их появления.
2. Internet official protocol standards (официальный перечень стандартов по протоколам Internet) - периодически обновляемый документ, где излагается общая характеристика процесса стандартизации в Internet, перечни вновь изданных RFC и обобщающие перечни протоколов, группируемые по стадиям стандартизации и иным признакам. Последняя версия этого документа изложена в RFC 2400.
3. RFC Summary Numbers (сводный перечень номеров RFC) переиздается, начиная с номера 699, через каждые 100 номеров и содержит перечни с краткими аннотациями каждых 100 предыдущих номеров RFC.
4. Assigned Numbers (присвоенные номера) - перечисляются присвоенные значения параметров, используемых в различных протоколах (например, адреса Internet, имена регионов, протокольные коды IP, номера портов TCP, коды опций Telnet, наименования типов терминалов).

К концу сентября прошлого года IAB выпустил 2331 документ RFC (последний изданный в сентябре RFC имеет номер 2428, но в первой тысяче осталось 77 «пустых» или пропущенных номеров, под которыми никогда ничего не издавалось). Динамика количественного выпуска документов RFC по годам (дифференциальная кривая) и с нарастающим итогом (интегральная кривая), начиная с 1969 года, которая в какой-то мере отражает динамику развития самой сети Internet, показана на рис. 1.

Рис. 1. Динамика разработки документов RFC

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

Кроме того, RFC никогда не переиздаются и не пересматриваются с тем же номером. Пересмотренный протокол издается под другим номером, а прежние сохраняются в каталогах под прежними номерами.

Согласно RFC 2400 в Internet приняты две независимые системы классификации протоколов. Первая подразделяет протоколы по уровню зрелости или стадиям стандартизации на:

• информационные (informational);
• экспериментальные (experimental);
• предложения по стандартам (proposed standards);
• проекты стандартов (draft standards);
• стандарты (standards);
• исторические (historic).

Вторая делит протоколы по уровню требований или статусу на:

• обязательные (required);
• рекомендуемые (recommended);
• избирательного применения (elective);
• ограниченного применения (limited use);
• не рекомендуемые (not recommended).

Протоколы проходят три стадии созревания: предложение по стандарту, проект и стандарт, подвергаясь на каждой стадии тщательному анализу и тестированию. Предложение по стандарту может стать проектом только при наличии минимум двух независимых реализаций и рекомендации Инженерной группы управления Internet (IESG - Internet Engineering Steering Group). Продвижение от проекта к стандарту требует обычно эксплуатационной проверки и демонстрации взаимодействия с двумя или более реализациями и также рекомендации IESG.

От предложения до проекта стандарта минимальная задержка составляет 6 месяцев, от проекта до стандарта - 4 месяца. Фактические же задержки могут достигать нескольких лет.

Некоторые документы, фиксирующие результаты проводимых исследований и разработок, получают название экспериментальных. Экспериментальный протокол не обеспечивает предлагаемых эксплуатационных услуг Internet и всегда имеет статус «ограниченного применения».

Протоколы, разработанные другими организациями по стандартизации или поставщиками и представляющие информационный интерес, либо по каким то другим причинам не входящие в предмет рассмотрения IESG, помечаются как информационные. Информационные документы не имеют статуса.

Вышедшие из употребления протоколы сохраняются в перечнях RFC с пометкой «исторические». Все такие протоколы должны иметь статус «не рекомендуемые». Протоколы, замененные новыми, получают название «устарелые» (obsolete).

Если протокол находится в одной из стадий «предложение по стандарту», «проект стандарта» или «стандарт», считается, что он находится в «треке стандартов» (standards track). Протоколам в стадии «стандарт» присваиваются номера STD. При этом в отличие от нумерации документов RFC номер стандарта STD при его пересмотре не изменяется (хотя пересмотренный документ будет иметь новый номер RFC). Иначе говоря, стандарт по конкретному протоколу всегда будет иметь один и тот же номер STD.

Другая особенность нумерации STD состоит в том, что если спецификация стандарта охватывает несколько документов RFC, они будут иметь один и тот же номер STD. Например, спецификация Domain Name System определяется комбинацией двух RFC - 1034 и 1035, которые охватываются одним номером STD 13. Шесть RFC по протоколам сетевого уровня (протокол IP, его расширения и протоколы ICMP, IGMP) охватываются одним STD 5. Для большей ясности один из нескольких RFC, охватываемых одним STD, можно указывать двойным номером, например, «STD 13/RFC 1034».

Общее правило присвоения номеров STD состоит в том, что отдельный номер STD присваивается, если спецификация логически отделена от других. Такой логически отдельной опции присваивается отдельный номер, в то время как не опциональные расширения используют один и тот же номер SТD в качестве базовой спецификации. В подобных случаях документы, определяющие конкретный стандарт, должны ссылаться друг на друга.

Согласно RFC 2400 при вхождении в трек стандартов (на стадии предложения по стандарту) протокол должен получить один из трех статусов, который, однако, может быть пересмотрен в любой момент времени:

1. Обязательный - система должна реализовать этот протокол.
2. Рекомендуемый - желательно (по соображениям экономичности, технической эффективности или лучшей совместимости), чтобы система реализовала данный протокол.
3. Избирательного применения - система может реализовать один из нескольких протоколов аналогичного назначения по усмотрению разработчика. К таким протоколам должны относиться, например, протоколы электронной почты или протоколы маршрутизации. Фактически же, для всех протоколов в стадии «предложение по стандарту» независимо от наличия альтернатив и возможностей выбора в документе RFC 2400 указан статус «избирательного применения», что несколько противоречит определению этого статуса.

   Помимо этого протоколы (в основном экспериментальные и исторические) могут получить один из следующих статусов:

4. Ограниченного применения - протокол используется в ограниченном числе случаев. Это могут быть протоколы экспериментальные, специального характера или ограниченных функциональных возможностей.
5. Не рекомендуемые - не рекомендуются для общего пользования (ограниченные функциональные возможности, специального назначения, исторические или устарелые).

С 1995 году IAB ввоцедуре принятия предложений по стандартам. Статус этих документов определен в RFC 1818, а документы BCP имеют свою независимую нумерацию. К сегодняшнему дню разработано 25 RFC в статусе BCP, однако при формальном группировании RFC по RFC 2400 документы BCP в отдельный класс не выделяются.

Рис. 2. Классификация протоколов Internet

Изложенная классификация протоколов в схематическом виде представлена на рис. 2. К сожалению, фактическая классификация конкретных документов и протоколов Internet как в самом RFC 2400, так и в других перечисленных регламентирующих и обобщающих документах IAB не обладает четкостью этого рисунка и страдает иногда нелогичностью и противоречивостью.

Прежде всего, в последнем обновленном RFC 2400, который перевел 20 ранее выпущенных версий этого документа в категорию исторических и одновременно устарелых, фактически упоминается лишь около 30% всех изданных RFC (758 документов). Сведения о стадии разработки и статусе остальных 70% RFC приходится разыскивать в 20 устарелых «исторических» RFC.

Уже отсюда видно, что понятию «устарелый» в классификации протоколов Internet придается смысл, несколько отличный от общепринятого. Это подтверждается еще и тем фактом, что после появления по какому-либо протоколу нового «предложения по стандарту» прежний продолжающий действовать стандарт по этому протоколу объявляется устарелым, хотя очевидно, что новое предложение по стандарту не может заменить действующий стандарт. Фактически, что признается и в самом RFC 2400, все устарелые протоколы делятся на две категории - те, которые не имеет смысла упоминать в официальном перечне протоколов, и те, которые заслуживают того, чтобы на какое-то время сохранить их в перечне, поскольку в данном случае «устарелый стандарт находится в процессе замены». Типичным (но не единственным) примером подобного подхода является стандарт STD 12 по протоколу NTP (Network Time Protocol), версия 2 (RFC 1119), который согласно RFC 2400 переведен в разряд устарелых стандартом избирательного статуса по протоколу NTP, версия 3 (RFC 1305) и в то же время оставлен в перечне действующих стандартов со статусом «рекомендуемый», а новому стандарту (по RFC 1305) номер STD 12 не передан.

Здесь, видимо, правильнее было бы во избежание путаницы для документов, «находящихся в процессе замены» применить понятие «устаревающий», но не «устарелый».

Официально считается, что стадии стандартизации, которые на рис. 2 изображены жирными прямоугольниками, являются долгосрочными, остальные же, особенно те, которые отражают процесс обновления стандартов, должны длиться один-два года. Фактически же эти «краткосрочные» стадии растягиваются иногда на десятилетия. Например, некоторые предложения по стандартам Telnet (RFC 652 - 658) сохранялись на этой стадии в течение 24 лет (с 1974 по 1998 год), после чего были переведены в категорию исторических, а многие проекты стандартов сохраняют свой статус с 1990 года (RFC 951, 954, 1191 и др.) по сегодняшний день.

Анализ перечисленных документов IAB позволил выявить следующую статистику количественного распределения документов RFC и протоколов Internet по стадиям разработки.

К документам с неизвестной стадией разработки относятся 908 начальных документов Internet, изданных до 1990 года, которые, судя по RFC 2400, не входят в трек стандартов и не относятся к экспериментальным (их можно отнести либо к информационным, либо к историческим). «Исторический» и одновременно «устарелый» документ должен означать, что он заменен новым документом, просто «исторический» должен означать, что он морально устарел и не имеет замены. Все документы RFC подразделяются на две группы: технические спецификации (TS - Technical Specifications) и положения о применимости (AS - Applicability Statements). Пока издано только 8 спецификаций AS, находящихся в различных стадиях разработки.

Все документы RFC, как и протоколы Internet, можно подразделить по другому признаку еще на две группы: документы, определяющие внутреннее функционирование Internet, и документы, определяющие взаимодействие Internet с сетями других типов. При этом ко второй группе относится около 277 (из 2331) документов RFC (включая устарелые и исторические). По относительному количеству выпущенных документов попытаемся косвенно оценить заинтересованность Internet во взаимосвязи с другими сетевыми технологиями и сетевыми архитектурами.

Эта статистика не показывает, однако, динамики взаимоотношений. Так, если взаимосвязь Internet с устарелыми (ARPANET) или достаточно зрелыми, но в чем-то устаревающими системами (IPX Novell, AppleTalk), постепенно вытесняемыми самой Internet, стабилизировалась (судя по отсутствию новых RFC) в начале 80-х, то с конца 80-х началась проработка взаимосвязей с развивающимися новыми архитектурами Frame Relay, ATM, а также привлечение и освоение ресурсов, наработанных в ISO, ITU-T, что и отразилось в появлении соответствующих RFC.

C 1990 года IAB ввел новую серию документов под названием FYI (For Your Information), которые носят информационный характер и должны обеспечить пользователей Internet централизованным справочником по наиболее важным темам и обобщающим вопросам (терминология, ответы на часто задаваемые вопросы относительно Internet и т.п.). Документы FYI имеют свою независимую нумерацию, и помещаются отдельным разделом в RFC Index, но не анализируются в RFC 2300. Издано 32 документа FYI, большинство из которых имеют своими дубликатами документы RFC.

Взаимосвязи между протоколами Internet

Уровневая архитектура протоколов Internet во многом соответствует концепции семиуровневой архитектуры протоколов эталонной модели OSI. Основное различие этих двух архитектур состоит в том, что протоколы трех верхних уровней эталонной модели OSI - прикладного, представления данных и сеансового в Internet, как правило, объединяются в один уровень - прикладной. Обобщенный профиль основных прикладных и коммуникационных протоколов Internet приведен на рис. 3.

Рис. 3. Основополагающие протоколы Internet и взаимосвязи между ними

Основными изначальными прикладными службами Internet были и остаются службы передачи файлов, электронной почты и обмена новостями, виртуальных терминалов и справочная служба. В каждой из таких областей шло постоянное развитие исходных и создание новых более эффективных протоколов, основные из которых, используемые сегодня перечислены на рисунке. Кроме того изначально применялись протоколы, выполняющие ряд вспомогательных, но повышающих эффективность работы функций - протоколы информирования о времени (TIME, NTP), получения собственных идентификаторов (BOOTP), получения информации об окружающей системе (Finger), диагностические протоколы (Echo) и др.

С середины 90-х в Internet начала активно развиваться и внедряться технология World Wide Web, обеспечивающая гипертекстовые ссылки и связки различных видов информации. В эти годы были созданы язык HTML и протокол HTTP, претерпевшие к настоящему времени несколько модификаций, а также необходимые форматы адресных ссылок URL и URN.

На прикладном уровне Internet используются также разработанные в рамках архитектуры OSI прикладные протоколы электронной почты Х.400 и справочной службы Х.500.

Для управления Сетью, эксплуатации и технического обслуживания различного сетевого оборудования разработан стандарт (STD 15/RFC 1157, статус «рекомендуемый») по протоколу SNMP. Кроме того, имеется несколько десятков документов различной стадии разработки, расширяющих функции SNMP на работу с самым разнообразным сетевым оборудованием и на взаимодействие с другими сетями в целом.

Функции уровня представления данных по эталонной модели OSI в Internet выполняет стандарт по протоколу и языку представления данных XDR, во мноIP. Вспомогательный протокол ICMP, предназначенный для передачи сообщений об ошибках в передаваемых пакетах IP, расположен над IP, но по своим функциям он все же больше тяготеет к сетевому уровню, чем к транспортному.

На уровне звена данных (канальном уровне) изначально использовался протокол SLIP, который сегодня фактически вытеснен протоколом двухпунктовых соединений PPP, поддерживающим как асинхронные (байт-ориентированные стартстопные), так и синхронные (бит-ориентированные) двунаправленные кабельные или модемные соединения. В последнее время дополнительно разработаны и успешно используются специальные стандарты для передачи IP-трафика по сетям различных архитектур, которые более полно учитывают особенности этих сетей. Кроме того на этом уровне часто используются (с применением инкапсуляции) протоколы других архитектур (Frame Relay, HDLC (в подсетях X.25), SDLC (в подсетях SNA), DDCMP (в подсетях DECNet), протоколы LAN и др.

На физическом уровне в сети Internet могут быть использованы практически все широко известные протоколы и интерфейсы физического уровня, стандартизованные ITU-T (CCITT), EIA, ISO, Frame Relay Forum, ATM Forum, протоколы и интерфейсы LAN, SDH (SONET) и др. Единственным ограничением, налагаемым протоколом РРР на физический уровень, является наличие дуплексного канала, выделенного или коммутируемого, работающего в асинхронном или синхронном последовательном режиме, прозрачном для пакетов уровня PPP. На скорости передачи данных и тип интерфейса никаких ограничений не налагается.

Протоколы прикладного уровня взаимодействуют с протоколами транспортного и сетевого уровней с использованием инкапсуляции. Так, в частности, протоколы HTTP, Telnet, FTP, SMTP, POP3, IMAP используют протокол TCP, протокол TFTP использует протокол UDP, а службы NetBIOS, TIME и протоколы OSI могут использовать оба транспортных протокола.

Стандартизация протоколов защиты информации на всех уровнях Internet пока недостаточно зрелая - сегодня по этим вопросам нет ни одного принятого стандарта. Однако проработка вопросов защиты информации ведется достаточно активно - в стадии рассмотрения находится 14 предложений по стандартам и еще большее число документов находятся в экспериментальной и информационной стадиях.

Взаимосвязь с другими сетями и архитектурами

Большие информационные и коммуникационные возможности Internet, с одной стороны, наличие современных высокоскоростных сетевых технологий, а также прикладных программ других сетевых архитектур с более широкими и гибкими возможностями, с другой стороны, приводят к общей практической заинтересованности во взаимном обогащении прикладных и коммуникационных ресурсов различных сетей.

Как уже отмечалось, вопросам взаимодействия Internet с другими сетями посвящено 290 документов RFC, отражающих используемые на практике конфигурации взаимодействия. Основные из таких конфигураций отражены на рис. 4, где указаны также соответствующие документы RFC, определяющие взаимодействие протоколов Internet с другими протоколами.

Можно выделить два основных подхода к взаимодействию Internet с другими сетевыми архитектурами и сетевыми технологиями.

1. Использование на нижних уровнях Internet современных высокоскоростных протоколов типа типа FDDI, Fast Ethernet, Frame Relay, ATM и др., повышающее эффективность работы прикладных протоколов Internet.
2. Использование более эффективных прикладных программ других сетевых архитектур (типа OSI, SNA) для работы по практически апробированным, достаточно зрелым и широко распространенным коммуникационным протоколам Internet.

В свою очередь, сами принципы и методы организации таких взаимодействий можно разделить на две категории: инкапсуляция протоколов и преобразование услуг. Метод инкапсуляции охватывает обычно три этапа:

1. разбиение длинного сообщения пользователя или единицы информации вышерасположенного уровня (пакета, кадра) на несколько более коротких фрагментов или сегментов. Этот процесс получил в литературе двоякое название: «фрагментация» (fragmentation) или «сегментирование» (segmenting);
2. образование из полученных фрагментов единиц информации (кадров, ячеек), воспринимаемых используемой сетевой технологией и упаковка полученных единиц информации в кадры или ячейки данной сетевой технологии. Этот процесс получил название «инкапсуляция» (encapsulation);
3. восстановление на принимающей стороне исходного сообщения, пакета или кадра. Этот процесс, в зависимости от конкретных используемых сетевых технологий, называется «сборка» (reassembling) (например, в X.25, ISDN) или «декапсуляция» (decapsulation) в большинстве других технологий.

Метод инкапсуляции протоколов определен в рекомендациях ITU-T I.363, I.365, Q.2119, стандартах ANSI T1.617a, Frame Relay Forum FRF.3.1 и в RFC 1490. На рис. 4 взаимодействие различных протоколов методом инкапсуляции изображено стрелками.

Метод преобразования услуг использован в показанном на рис. 4 взаимодействии протоколов Internet с прикладными протоколами OSI. В RFC 1006 (стандарт STD 35) определен механизм, позволяющий протоколу транспортного уровня ТР 0 (простой класс) по ISO/IEC 8073 (и, следовательно, любым прикладным программам OSI, работающим по ТР 0) функционировать над протоколом TCP Internet при использовании услуг протокола IP. В результате логические объекты всех верхних уровней OSI (прикладного, представления данных и сеансового) могут функционировать нормально, не ощущая того, что все они работают по TCP/IP.

В RFC 2126 (предложение по стандарту) дополнительно к протоколу ТР 0 предусмотрено также функционирование протокола ТР 2 (класс с мультиплексированием сетевых соединений) ISO/IEC 8073 над протоколом TCP и, кроме того, уточняются механизмы преобразования услуг TCP в услуги сетевого уровня OSI, используемые TP 0 и TP 2. Аналогичный стандарт «Использование прикладных протоколов OSI над протоколом TCP Internet» разработан в ISO.

Протокол по RFC 1006/2126 и ISO/IEC 14766 преобразует услуги протокола TCP Internet в стандартные по ISO/IEC 8348 услуги сетевого уровня OSI в режиме с установлением соединения (CONS), которые затем используются протоколом TP 0 или TP 2 по ISO/IEC 8073. Кроме того указанный протокол инкапсулирует протокольные блоки ISO/IEC 8073 в пакеты протокола ТСР. При этом все основные аспекты услуг транспортного уровня по ISO/IEC 8072 сохраняются, за исключением параметра качества услуг.

Рис. 4. Взаимосвязь протоколов Internet с протоколами других сетевых архитектур и технологий

Наряду с широко известными сетевыми архитектурами и сетевыми технологиями OSI, X.25, ISDN, Frame Relay, ATM, SDH/SONET, а также стандартными технологиями локальных сетей семейства IEEE 802 (Ethernet, Token Ring, FDDI) на рис. 4 изображены взаимосвязи Internet с другими менее известными технологиями.

Технология SMDS, получившая название «коммутируемая многомегабитовая служба передачи данных», разработана компанией Bellcore. По ее определению, SMDS - это «высокоскоростная служба коммутации пакетов общего пользования, работающая в режиме без установления соединения и предназначенная для расширения локальных сетей за пределы оборудования пользователя через глобальные или региональные вычислительные сети». Эта служба может использоваться для многих применений, включая взаимосвязи локальных сетей, высокоскоростной доступ к удаленным базам данных, пакетная передача аудио- и видеоинформации, распределение ресурсов, передача изображений или телерадиология. При этом SMDS может обеспечивать взаимодействия с другими широкополосными технологиями, такими как Frame Relay и ATM. SMDS обеспечивает скорости передачи данных 56/64 Кбит/с (DS0), 1544 Мбит/с (DS1) и 44736 Мбит/с (DS3).

Спецификация NetBIOS, опубликованная в 1984 году корпорацией IBM под названием «IBM PC Network Technical Reference Manual», определила интерфейс и услуги сети IBM PC и совместимых систем, коллективно использующих общую широкополосную физическую среду. Предусмотрены два режима работы - сются динамически.

Поскольку служба NetBIOS сконструирована на основе различных протоколов и различного оборудования, то для обеспечения взаимодействия NetBIOS в Internet RFC 1001 и 1002 определили стандартный протокол для функционирования прикладных программ NetBIOS над протоколами TCP и UDP. Кроме того, поскольку для выполнения некоторых приложений NetBIOS типа серверов файлов ПК не подходят, то RFC 1001 и 1002 определили возможность построения реализаций на системах любого типа, где имеется комплект протоколов TCP/IP.

С другой стороны, RFC 1088 определил стандартный метод инкапсуляции датаграмм протокола IP в датаграммы NetBIOS с тем, чтобы обеспечить возможность работы в компьютерах сети NetBIOS прикладных программ Internet, работающих над IP. Кроме того определено преобразование 4-байтовых адресов IP в 16-байтовые имена NetBIOS. Использование маршрутизаторов, способных инкапсулировать пакеты IP в обычные протоколы уровня звена данных (типа протоколов локальных сетей), а также в датаграммы NetBIOS, позволяют компьютерам NetBIOS взаимодействовать со всей Internet.

Протокол PPP обеспечивает стандартный метод транспортирования многопротокольных датаграмм по двухпунктовым каналам. PPP определяет расширяемый Link Control Protocol и поддерживает семейство различных протоколов сетевого уровня NCP (Network Control Protocols). RFC 2097 определил один из протоколов NCP, поддерживаемых PPP, для функционирования протокола сетевого уровня NBFCP сети NetBIOS над PPP.

Высокопроизводительный параллельный интерфейс HIPPI, разработанный в конце 80-х - начале 90-х рабочей группой ANSI X3T9.3 HIPPI, представляет собой простой канал данных. Пара таких каналов обеспечивает одновременный прием и передачу данных на скорости 800 Мбит/с и факультативно 1600 Мбит/с.

Документы RFC Index:

ftp://ftp.ripe.net

http://www.ds.internic.net/rfc/rfc-index.txt

http://www.kiarchive.ru:/pub/internet/

http://www.csl.sony.co.jp/rfc/mirror/

http://www.rfc.fh-koeln.de/doc/rfc/html/

Следует учесть, что содержимое RFC Index по всем указанным адресам не идентичное. Если, например, по первому из адресов RFC Index содержит только перечень номеров RFC (без названий документов), форматы RFC (указываемые расширением имени файла) и емкость электронной версии документа в Кбайт, то по последнему из перечисленных адресов содержится наиболее подробный RFC Index с указанием дополнительно наименования документа, фамилий авторов, даты издания, устарелых или обновляемых версий документа и стадии разработки протокола.

При этом ни по одному из перечисленных адресов в приводимых RFC Index не указан статус протоколов, а стадии разработки указываются только по последнему из адресов, однако здесь регламентированные в RFC стадии разработки (типа proposed standard, draft standard) именуются как «статус», а то, что в RFC 2400 трактуется как «статус» (типа required, recommended), в этом RFC Index вообще не упоминается. Из 55 разработанных STD в этом RFC Index упомянуты только 12. Для 928 документов (из 2331) стадии разработки помечены как «не известные» (UNKNOWN). В этом же RFC Index протоколы TELNET (RFC 856 - RFC 861) указаны со статусом UNKNOWN, тогда как в RFC 2400 они помечены как STANDARD со статусом Recommended.

Во всех RFC Index 480 документов (в основном из первой тысячи) недоступны в электронном виде. Полный, оперативно дополняемый RFC Index, включая перечень FYI, с указанием стадий разработки протоколов и статусов документов и лишенный многих указанных выше неточностей других RFC Index можно найти на сервере http://incoma.ru