RFC | это… Что такое RFC?
Эта статья о Request for Comments.
Рабочее предложение (англ. Request for Comments, RFC) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» ещё можно перевести как «заявка (запрос) на отзывы» или «тема для обсуждения». В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (англ. Internet Society, ISOC). Правами на RFC обладает именно Общество Интернета.
Содержание
|
История
Формат RFC появился в 1969 году при обсуждении проекта ARPANET. RFC 1 был опубликован 7 апреля 1969 г. и назывался «Host Software».
Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде.
Большинство ранних RFC были созданы в Калифорнийском университете Лос-Анджелеса и Стэнфордском исследовательском институте.
С 1969 по 1998 гг. бессменным и единственным редактором RFC был Джон Постел. После его смерти Общество Интернета (ISOC) поручило редактирование и публикацию RFC Институту информационных наук Университета Южной Калифорнии.
Очерк истории RFC за 30 лет с 1969 по 1999 гг. представлен в RFC 2555.
Содержимое RFC
Несмотря на название, запросы на отзывы RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ.
- Выносится на всеобщее рассмотрение интернет-проект (Internet Draft).
Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения. - Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.
- Следующая стадия — проект стандарта (Draft Standard) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В проекты стандартов ещё могут вноситься мелкие правки, но они считаются достаточно стабильными и рекомендуются для реализации.
- Высший уровень — стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.
- Многие старые RFC замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус исторических (Historic)
Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.Практически все стандарты Глобальной сети существуют в виде опубликованных заявок RFC. Но в виде документов RFC выходят не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях:
- Экспериментальные (Experimental) спецификации содержат информацию об экспериментальных исследованиях, интересных для интернет-сообщества. Это могут быть, например, прототипы, реализующие новые концепции.
- Информационные (Informational) RFC предназначены для ознакомления общественности, не являются стандартами и не являются результатом консенсуса или рекомендациями. Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.
- Лучший современный опыт (Best Current Practice). Эта серия RFC содержит рекомендации по реализации стандартов, в том числе от сторонних организаций, а также внутренние документы о структуре и процедурах стандартизации.
Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-организаций (например W3C, IETF, консорциум Юникода, Интернет2).
Запросы на отзывы официально существуют только на английском языке. Строгих требований к оформлению нет. Встречаются RFC, написанные в строгом академическом стиле, иные — в дружеской неформальной манере. Существует традиция выпуска первоапрельских шуточных RFC, например, RFC 1149 рассказывает о передаче пакетов IP с помощью почтовых голубей.
Примеры популярных запросов на отзывы
| Номер RFC | Тема |
|---|---|
RFC 768 (англ. ) RFC 768 (рус.) | UDP |
| RFC 791 (англ.) RFC 791 (рус.) | IP |
| RFC 792 (англ.) RFC 792 (рус.) | ICMP |
| RFC 793 (англ.) RFC 793 (рус.) | TCP |
| RFC 821 (англ.) | SMTP, заменён RFC 2821 |
| RFC 822 (англ.) | Формат электронной почты, заменён RFC 2822 |
| RFC 826 (англ.) | Протокол разрешения адреса (ARP) |
| RFC 894 (англ.) RFC 894 (рус.) | IP по Ethernet |
| RFC 951 (англ.) | Протокол начальной загрузки (BOOTP) |
| RFC 959 (англ.) | FTP |
| RFC 977 (англ.) | NNTP — устаревший, дополнен RFC 2980 , заменён RFC 3977 |
| RFC 1034 (англ.) | DNS — концепция |
| RFC 1035 (англ.) | DNS — внедрение |
| RFC 1122 (англ.) RFC 1122 (рус.) | Требования к хосту 1 |
RFC 1123 (англ.) RFC 1123 (рус. ) | Требования к хосту 2 |
| RFC 1191 (англ.) RFC 1191 (рус.) | Определение MTU пути |
| RFC 1256 (англ.) | Обнаружение маршрутизатора в сети |
| RFC 1323 (англ.) | Высокопроизводительный протокол TCP |
| RFC 1350 (англ.) | TFTP |
| RFC 1403 (англ.) | Взаимодействие BGP и OSPF |
| RFC 1459 (англ.) RFC 1459 (рус.) | IRC |
| RFC 1498 (англ.) | Архитектурная дискуссия |
| RFC 1518 (англ.) | Присвоение адресов CIDR |
| RFC 1519 (англ.) | Междоменная маршрутизация |
| RFC 1591 (англ.) | Структура доменных имён |
| RFC 1661 (англ.) | PPP |
| RFC 1738 (англ.) | URL |
| RFC 1771 (англ.) | BGP версии 4 |
| RFC 1772 (англ.) | Приложение BGP |
| RFC 1789 (англ.) | Телефония по Интернет (заменён стандартами VoIP) |
RFC 1812 (англ. | Требования к маршрутизаторам IPv4 |
| RFC 1855 (англ.) | Руководство по Нетикету |
| RFC 1889 (англ.) | Транспорт реального времени |
| RFC 1905 (англ.) | SNMP |
| RFC 1907 (англ.) | SNMP версии 2 |
| RFC 1918 (англ.) RFC 1918 (рус.) | «Сеть 10» |
| RFC 1939 (англ.) RFC 1939 (рус.) | Протокол POP версии 3 (POP3) |
| RFC 2001 (англ.) RFC 2001 (рус.) | Расширения производительности TCP |
| RFC 2026 (англ.) | Процесс стандартизации в Интернете |
| RFC 2045 (англ.) | MIME |
| RFC 2046 (англ.) | |
| RFC 2047 (англ.) | |
| RFC 2048 (англ.) | |
| RFC 2049 (англ.) | |
| RFC 2060 (англ.) RFC 2060 (рус.) | IMAP версии 4 (IMAP4), заменён RFC 3501 |
| RFC 2131 (англ.) | DHCP |
RFC 2223 (англ. ) | Инструкции для авторов RFC |
| RFC 2246 (англ.) RFC 2246 (рус.) | SSL и TLS |
| RFC 2231 (англ.) | Кодировка символов |
| RFC 2328 (англ.) | OSPF |
| RFC 2401 (англ.) | Архитектура безопасности протокола IP (IPsec) |
| RFC 2453 (англ.) | RIP |
| RFC 2516 (англ.) RFC 2516 (рус.) | PPPoE |
| RFC 2525 (англ.) | Проблемы TCP |
| RFC 2535 (англ.) | Безопасность DNS |
| RFC 2581 (англ.) RFC 2581 (рус.) | Контроль заторов в TCP |
| RFC 2616 (англ.) | HTTP |
| RFC 2637 (англ.) | PPTP |
| RFC 2663 (англ.) | Трансляция сетевых адресов |
| RFC 2766 (англ.) | NAT-PT |
| RFC 2821 (англ.) RFC 2821 (рус.) | SMTP, заменён RFC 5321 |
| RFC 2822 (англ.) | Формат электронной почты |
RFC 2865 (англ. ) | RADIUS |
| RFC 2866 (англ.) RFC 2866 (рус.) | Средства учёта RADIUS |
| RFC 2960 (англ.) | SCTP |
| RFC 2980 (англ.) | Общие расширения NNTP, дополняет RFC 977, заменён RFC 3977 |
| RFC 3010 (англ.) | NFS |
| RFC 3031 (англ.) | Архитектура MPLS |
| RFC 3066 (англ.) | Языковые теги |
| RFC 3092 (англ.) | Этимология «Foo» |
| RFC 3098 (англ.) | Ответственная реклама по электронной почте |
| RFC 3160 (англ.) | Гид по IETF |
| RFC 3168 (англ.) RFC 3168 (рус.) | ECN |
| RFC 3261 (англ.) | SIP |
| RFC 3501 (англ.) | IMAP версии 4 издание 1 (IMAP4rev1) |
| RFC 3977 (англ.) | NNTP, заменяет RFC 977, дополняет RFC 2980 |
См. также
- CfV
- FYI
- BCP
- IETF
- W3C
- ISOC
- IEEE
- Первоапрельские RFC
- IEN
Ссылки
- Официальные источники
- База данных RFC (англ. )
- Запросы RFC на сайте IETF (англ.)
)- Другие сайты
- Русские Переводы RFC (рус.)
RFC | это… Что такое RFC?
Эта статья о Request for Comments.
Рабочее предложение (англ. Request for Comments, RFC) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» ещё можно перевести как
Содержание
|
История
Формат RFC появился в 1969 году при обсуждении проекта ARPANET.
RFC 1 был опубликован 7 апреля 1969 г. и назывался «Host Software». Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде.
Большинство ранних RFC были созданы в Калифорнийском университете Лос-Анджелеса и Стэнфордском исследовательском институте.
С 1969 по 1998 гг. бессменным и единственным редактором RFC был Джон Постел. После его смерти Общество Интернета (ISOC) поручило редактирование и публикацию RFC Институту информационных наук Университета Южной Калифорнии.
Очерк истории RFC за 30 лет с 1969 по 1999 гг. представлен в RFC 2555.
Содержимое RFC
Несмотря на название, запросы на отзывы RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft здесь — проект). Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:
- Выносится на всеобщее рассмотрение интернет-проект (Internet Draft). Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
- Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.
- Следующая стадия — проект стандарта (Draft Standard) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В проекты стандартов ещё могут вноситься мелкие правки, но они считаются достаточно стабильными и рекомендуются для реализации.
- Высший уровень — стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.
- Многие старые RFC замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус исторических (Historic)
Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.Практически все стандарты Глобальной сети существуют в виде опубликованных заявок RFC. Но в виде документов RFC выходят не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях:
- Экспериментальные (Experimental) спецификации содержат информацию об экспериментальных исследованиях, интересных для интернет-сообщества. Это могут быть, например, прототипы, реализующие новые концепции.
- Информационные (Informational) RFC предназначены для ознакомления общественности, не являются стандартами и не являются результатом консенсуса или рекомендациями. Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.
- Лучший современный опыт (Best Current Practice). Эта серия RFC содержит рекомендации по реализации стандартов, в том числе от сторонних организаций, а также внутренние документы о структуре и процедурах стандартизации.
Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-организаций (например W3C, IETF, консорциум Юникода, Интернет2).
Запросы на отзывы официально существуют только на английском языке. Строгих требований к оформлению нет. Встречаются RFC, написанные в строгом академическом стиле, иные — в дружеской неформальной манере. Существует традиция выпуска первоапрельских шуточных RFC, например, RFC 1149 рассказывает о передаче пакетов IP с помощью почтовых голубей.
Примеры популярных запросов на отзывы
| Номер RFC | Тема |
|---|---|
RFC 768 (англ. ) RFC 768 (рус.) | UDP |
| RFC 791 (англ.) RFC 791 (рус.) | IP |
| RFC 792 (англ.) RFC 792 (рус.) | ICMP |
| RFC 793 (англ.) RFC 793 (рус.) | TCP |
| RFC 821 (англ.) | SMTP, заменён RFC 2821 |
| RFC 822 (англ.) | Формат электронной почты, заменён RFC 2822 |
| RFC 826 (англ.) | Протокол разрешения адреса (ARP) |
| RFC 894 (англ.) RFC 894 (рус.) | IP по Ethernet |
| RFC 951 (англ.) | Протокол начальной загрузки (BOOTP) |
| RFC 959 (англ.) | FTP |
| RFC 977 (англ.) | NNTP — устаревший, дополнен RFC 2980 , заменён RFC 3977 |
| RFC 1034 (англ.) | DNS — концепция |
| RFC 1035 (англ.) | DNS — внедрение |
| RFC 1122 (англ.) RFC 1122 (рус.) | Требования к хосту 1 |
RFC 1123 (англ.) RFC 1123 (рус. ) | Требования к хосту 2 |
| RFC 1191 (англ.) RFC 1191 (рус.) | Определение MTU пути |
| RFC 1256 (англ.) | Обнаружение маршрутизатора в сети |
| RFC 1323 (англ.) | Высокопроизводительный протокол TCP |
| RFC 1350 (англ.) | TFTP |
| RFC 1403 (англ.) | Взаимодействие BGP и OSPF |
| RFC 1459 (англ.) RFC 1459 (рус.) | IRC |
| RFC 1498 (англ.) | Архитектурная дискуссия |
| RFC 1518 (англ.) | Присвоение адресов CIDR |
| RFC 1519 (англ.) | Междоменная маршрутизация |
| RFC 1591 (англ.) | Структура доменных имён |
| RFC 1661 (англ.) | PPP |
| RFC 1738 (англ.) | URL |
| RFC 1771 (англ.) | BGP версии 4 |
| RFC 1772 (англ.) | Приложение BGP |
| RFC 1789 (англ.) | Телефония по Интернет (заменён стандартами VoIP) |
RFC 1812 (англ. ) | Требования к маршрутизаторам IPv4 |
| RFC 1855 (англ.) | Руководство по Нетикету |
| RFC 1889 (англ.) | Транспорт реального времени |
| RFC 1905 (англ.) | SNMP |
| RFC 1907 (англ.) | SNMP версии 2 |
| RFC 1918 (англ.) RFC 1918 (рус.) | «Сеть 10» |
| RFC 1939 (англ.) RFC 1939 (рус.) | Протокол POP версии 3 (POP3) |
| RFC 2001 (англ.) RFC 2001 (рус.) | Расширения производительности TCP |
| RFC 2026 (англ.) | Процесс стандартизации в Интернете |
| RFC 2045 (англ.) | MIME |
| RFC 2046 (англ.) | |
| RFC 2047 (англ.) | |
| RFC 2048 (англ.) | |
| RFC 2049 (англ.) | |
| RFC 2060 (англ.) RFC 2060 (рус.) | IMAP версии 4 (IMAP4), заменён RFC 3501 |
| RFC 2131 (англ.) | DHCP |
RFC 2223 (англ. ) | Инструкции для авторов RFC |
| RFC 2246 (англ.) RFC 2246 (рус.) | SSL и TLS |
| RFC 2231 (англ.) | Кодировка символов |
| RFC 2328 (англ.) | OSPF |
| RFC 2401 (англ.) | Архитектура безопасности протокола IP (IPsec) |
| RFC 2453 (англ.) | RIP |
| RFC 2516 (англ.) RFC 2516 (рус.) | PPPoE |
| RFC 2525 (англ.) | Проблемы TCP |
| RFC 2535 (англ.) | Безопасность DNS |
| RFC 2581 (англ.) RFC 2581 (рус.) | Контроль заторов в TCP |
| RFC 2616 (англ.) | HTTP |
| RFC 2637 (англ.) | PPTP |
| RFC 2663 (англ.) | Трансляция сетевых адресов |
| RFC 2766 (англ.) | NAT-PT |
| RFC 2821 (англ.) RFC 2821 (рус.) | SMTP, заменён RFC 5321 |
| RFC 2822 (англ.) | Формат электронной почты |
RFC 2865 (англ. ) | RADIUS |
| RFC 2866 (англ.) RFC 2866 (рус.) | Средства учёта RADIUS |
| RFC 2960 (англ.) | SCTP |
| RFC 2980 (англ.) | Общие расширения NNTP, дополняет RFC 977, заменён RFC 3977 |
| RFC 3010 (англ.) | NFS |
| RFC 3031 (англ.) | Архитектура MPLS |
| RFC 3066 (англ.) | Языковые теги |
| RFC 3092 (англ.) | Этимология «Foo» |
| RFC 3098 (англ.) | Ответственная реклама по электронной почте |
| RFC 3160 (англ.) | Гид по IETF |
| RFC 3168 (англ.) RFC 3168 (рус.) | ECN |
| RFC 3261 (англ.) | SIP |
| RFC 3501 (англ.) | IMAP версии 4 издание 1 (IMAP4rev1) |
| RFC 3977 (англ.) | NNTP, заменяет RFC 977, дополняет RFC 2980 |
См. также
- CfV
- FYI
- BCP
- IETF
- W3C
- ISOC
- IEEE
- Первоапрельские RFC
- IEN
Ссылки
- Официальные источники
- База данных RFC (англ. )
- Запросы RFC на сайте IETF (англ.)
)- Другие сайты
- Русские Переводы RFC (рус.)
IETF | TLS 1.3
Интернет-стандарты, разработанные IETF сегодня, обеспечивают Интернет завтрашнего дня. Работа IETF приносит пользу каждому, кто вкладывает свое время и талант. Прямо сейчас вы также можете поддержать будущее IETF, сделав подарок Фонду IETF, и Интернет-сообщество удвоит ваш подарок.
- Lee-Berkeley ShawIETF Administration LLC Директор по развитию
14 декабря 2022 г.
Хакатон IETF 115 прошел 5-6 ноября в Лондоне. 350 человек зарегистрировались для участия на месте и еще более 100 зарегистрировались для удаленного участия, чтобы работать над 39 проектами практически во всех областях работы IETF, что ознаменовало возвращение к допандемическим уровням участия.
- Чарльз Экель Сопредседатель IETF Hackathon
13 декабря 2022 г.
В прошлом месяце у меня была возможность посетить первое совещание Целевой группы по проектированию Интернета, IETF 115, которое проходило в Лондоне. Это был отличный опыт, и я смог многому научиться у многих присутствовавших сетевых специалистов.
- Момока Ямамото
6 декабря 2022 г.
На этом семинаре IAB рассматривается, что могут сделать технологи и разработчики стандартов, чтобы снизить затраты или увеличить выгоды от воздействия интернет-приложений и систем на окружающую среду.
- Яри Аркко Член IAB
- Ларс Эггерт Председатель IETF
- Колин Перкинс Председатель IRTF
5 декабря 2022 г.
Открыта регистрация для IETF 116 Йокогама
- Джей Дейли Исполнительный директор IETF
24 нояб.
2022 г.Показать все
2022 г.Фильтр по теме и дате
TopicAll Интернет вещей Общая площадь Транспортная зона (тсв) Безопасность и конфиденциальность Зона операций и управления Совет по архитектуре Интернета Приложения и зона реального времени IETF-LLC Зона безопасности (сек) Новости
Дата с
Дата по
Фильтр по теме и дате
TopicAll Интернет вещей Общая площадь Транспортная зона (тсв) Безопасность и конфиденциальность Зона операций и управления Совет по архитектуре Интернета Приложения и зона реального времени IETF-LLC Зона безопасности (сек) Новости
Дата с
Дата до
- Джозеф А. Саловейтлс Председатель рабочей группы
- Шон Тернертлс Рабочая группа
- Кристофер А. Вудтлс Работаем в Интернете, обеспечивая превосходную конфиденциальность, безопасность и производительность.
Безопасная передача информации через Интернет является основой онлайн-торговли, медицины и других конфиденциальных транзакций. Для этих и многих других целей крайне важно, чтобы передаваемая информация не была подделана, подделана или прочитана кем-либо, кроме отправителя и получателя. Эти функции были ключевой частью роста Интернета и имеют решающее значение для многих инновационных применений.
В то время как наиболее широко используемая технология, обеспечивающая безопасность транспортного уровня для Интернета, восходит к SSL более 20 лет назад, недавно завершенная версия TLS 1.3 является серьезной версией, разработанной для современного Интернета. Протокол имеет значительные улучшения в области безопасности, производительности и конфиденциальности.
Хотя предыдущую версию, TLS 1.
2, можно было безопасно развернуть, несколько известных уязвимостей использовали необязательные части протокола и устаревшие алгоритмы. TLS 1.3 удаляет многие из этих проблемных опций и поддерживает только алгоритмы без известных уязвимостей. На протяжении разработки TLS 1.3 рабочая группа IETF TLS взаимодействовала с сообществом криптографических исследователей для анализа, улучшения и проверки безопасности TLS 1.3. Это включало несколько семинаров, на которых исследователи могли представить свои выводы, например, семинар TRON, организованный в связи с конференцией NDSS 2016, и дал не менее 15 высокоцитируемых рецензируемых статей на известных научных конференциях.В отличие от TLS 1.2, TLS 1.3 обеспечивает дополнительную конфиденциальность при обмене данными, шифруя большую часть рукопожатия согласования, чтобы защитить его от перехватчиков. Это усовершенствование помогает защитить идентификационные данные участников и препятствует анализу трафика. TLS 1.3 также включает прямую секретность по умолчанию, что означает, что компрометация долгосрочных секретов, используемых в протоколе, не позволяет расшифровывать данные, передаваемые во время использования этих долгосрочных секретов.
В результате текущие коммуникации останутся безопасными, даже если будущие коммуникации будут скомпрометированы.Что касается производительности, то TLS 1.3 сокращает весь круговой путь от рукопожатия установления соединения. В общем случае новые подключения TLS 1.3 будут выполняться за одно обращение между клиентом и сервером. Некоторые приложения теперь также могут использовать режимы, которые доставляют данные приложениям еще быстрее. Эти улучшения в сочетании с эффективными современными криптографическими алгоритмами делают TLS 1.3 быстрее, чем когда-либо.
Процесс разработки TLS 1.3 включал в себя значительную работу над «запускаемым кодом», основной мантрой IETF. Это означало создание и тестирование реализаций многими компаниями и организациями, которые предоставляют продукты и услуги, широко используемые в Интернете, такие как веб-браузеры и сети распространения контента. Например, TLS 1.3 был в центре внимания IETF 9.8 Проект хакатона , объединивший людей, работающих с веб-браузерами, веб-сайтами и Интернетом вещей.
Это сотрудничество помогает продемонстрировать совместимость, отловить документацию и ошибки реализации и, в конечном счете, гарантировать, что спецификация станет надежной ссылкой для других, желающих внедрить TLS 1.3. Эта работа помогла сделать TLS 1.3 частью дорожной карты для многих компаний, и она готова быстро и широко стать доступной для широкого круга пользователей Интернета. Растущий список реализаций можно найти здесь.В ходе его разработки многие люди вложили свое время, энергию и опыт, чтобы улучшить протокол до его текущего состояния. Мы выражаем особую благодарность этим авторам. Теперь, когда TLS 1.3 — как основной протокол, так и несколько других спецификаций, поддерживающих его реализацию и развертывание, — находится на завершающей стадии завершения, мы ожидаем, что внедрение будет быстрым и широким.
Что нужно сделать, чтобы воспользоваться преимуществами TLS 1.
3? Большинство современных веб-браузеров и многие приложения, которые вы, вероятно, используете, уже поддерживают TLS 1.3. Для тех, кто в настоящее время не поддерживает протокол, мы ожидаем, что будущие обновления обеспечат поддержку. Точно так же, если вы управляете веб-сайтом или другим онлайн-сервисом, серверы и инфраструктура, которые вы используете, скорее всего, начнут использовать TLS 1.3, хотя стоит дважды проверить это у ваших провайдеров. Если вы разрабатываете или внедряете программное обеспечение или службы, используемые другими в Интернете, и еще не используете TLS 1.3 как часть своей дорожной карты, вам следует посмотреть, что делают другие, и соответствующим образом спланировать.Короче говоря, TLS 1.3 призван обеспечить основу для более безопасного и эффективного Интернета в течение следующих 20 лет и далее.
WebRTC: знаменательная веха в коммуникации в реальном времени
Интернет-стандарты, разработанные IETF сегодня, обеспечивают Интернет завтрашнего дня.
Работа IETF приносит пользу каждому, кто вкладывает свое время и талант. Прямо сейчас вы также можете поддержать будущее IETF, сделав подарок Фонду IETF, и Интернет-сообщество удвоит ваш подарок.- Lee-Berkeley ShawIETF Administration LLC Директор по развитию
14 декабря 2022 г.
Хакатон IETF 115 прошел 5-6 ноября в Лондоне. 350 человек зарегистрировались для участия на месте и еще более 100 зарегистрировались для удаленного участия, чтобы работать над 39 проектами практически во всех областях работы IETF, что ознаменовало возвращение к допандемическим уровням участия.
- Чарльз ЭккельСопредседатель IETF Hackathon
13 декабря 2022 г.
В прошлом месяце у меня была возможность посетить первое совещание Целевой группы по проектированию Интернета, IETF 115, которое проходило в Лондоне.
Это был отличный опыт, и я смог многому научиться у многих присутствовавших сетевых специалистов.- Момока Ямамото
6 декабря 2022 г.
На этом семинаре IAB рассматривается, что могут сделать технологи и разработчики стандартов, чтобы снизить затраты или увеличить выгоды от воздействия интернет-приложений и систем на окружающую среду.
- Яри Аркко Член IAB
- Ларс Эггерт Председатель IETF
- Колин Перкинс Председатель IRTF
5 декабря 2022 г.
Открыта регистрация для IETF 116 Йокогама
- Джей Дейли Исполнительный директор IETF
24 нояб. 2022 г.
Показать все
Интернет-стандарты, разработанные IETF сегодня, обеспечивают Интернет завтрашнего дня.
Работа IETF приносит пользу каждому, кто вкладывает свое время и талант. Прямо сейчас вы также можете поддержать будущее IETF, сделав подарок Фонду IETF, и Интернет-сообщество удвоит ваш подарок.- Lee-Berkeley ShawIETF Administration LLC Директор по развитию
14 декабря 2022 г.
Хакатон IETF 115 прошел 5-6 ноября в Лондоне. 350 человек зарегистрировались для участия на месте и еще более 100 зарегистрировались для удаленного участия, чтобы работать над 39 проектами практически во всех областях работы IETF, что ознаменовало возвращение к допандемическим уровням участия.
- Чарльз ЭккельСопредседатель IETF Hackathon
13 декабря 2022 г.
В прошлом месяце у меня была возможность посетить первое совещание Целевой группы по проектированию Интернета, IETF 115, которое проходило в Лондоне.
Это был отличный опыт, и я смог многому научиться у многих присутствовавших сетевых специалистов.- Момока Ямамото
6 декабря 2022 г.
На этом семинаре IAB рассматривается, что могут сделать технологи и разработчики стандартов, чтобы снизить затраты или увеличить выгоды от воздействия интернет-приложений и систем на окружающую среду.
- Яри Аркко Член IAB
- Ларс Эггерт Председатель IETF
- Колин Перкинс Председатель IRTF
5 декабря 2022 г.
Открыта регистрация для IETF 116 Йокогама
- Джей Дейли Исполнительный директор IETF
24 нояб. 2022 г.
Показать все
Фильтр по теме и дате
TopicAll Интернет вещей Общая площадь Транспортная зона (тсв) Безопасность и конфиденциальность Зона операций и управления Совет по архитектуре Интернета Приложения и зона реального времени IETF-LLC Зона безопасности (сек) Новости
Дата с
Дата по
Фильтр по теме и дате
TopicAll Интернет вещей Общая площадь Транспортная зона (тсв) Безопасность и конфиденциальность Зона операций и управления Совет по архитектуре Интернета Приложения и зона реального времени IETF-LLC Зона безопасности (сек) Новости
Дата от
Дата до
- Алиса Купер Председатель IETF
27 января 2021
Публикация стандартов, которые обеспечивают основу для веб-коммуникаций в реальном времени (WebRTC), знаменует собой веху в развитии используемых сервисов конференц-связи миллиардами людей по всему миру.
Более десяти лет назад, когда многофункциональные веб-приложения находились в зачаточном состоянии, инженеры из разных отраслей Интернета и связи в реальном времени собрались вместе, чтобы решить сложную проблему: можно ли перенести современные технологии передачи голоса и видео по IP на повсеместную платформу. Интернета?
Задача была сложной. Коммуникации в реальном времени включали в себя сложную механику протокола и механизм обхода трансляции сетевых адресов (NAT), в то время как в Интернете отсутствовали API и модель безопасности, необходимые для безопасного осуществления двусторонней связи в реальном времени. Но идея сделать видеозвонок в браузере одним нажатием кнопки предоставила почти безграничные возможности для совместной работы, связи и продуктивности.
Эта идея стала реальностью для миллиардов пользователей по всему миру благодаря многолетней интенсивной работе по стандартизации WebRTC в IETF и Консорциуме World Wide Web (W3C). На прошлой неделе IETF опубликовала набор из 50 спецификаций (составляющих основную часть RFC, опубликованных в январе), которые определяют основной стек протоколов WebRTC вместе с несколькими другими протоколами, использующими строительные блоки WebRTC.
Ранее на этой неделе W3C опубликовал WebRTC 1.0, веб-API, которые делают возможными вызовы между браузерами. Еще до окончательной доработки этих спецификаций — фактически за несколько лет до этого — технологии WebRTC развертывались и использовались как часть большинства современных сервисов, использующих голос или видео, в том числе многих, не использующих веб-браузеры. Наличие кода WebRTC, API и стандартов упростило добавление функций связи в реальном времени в любое приложение. И эта широкая доступность была настоящим спасательным кругом во время COVID-19.пандемия.Уже ведутся работы по расширению WebRTC. Работа IETF WebTransport (WEBTRANS) направлена на создание дополнительной веб-поддержки для различных свойств транспорта. Работа WebRTC Ingest Signaling over HTTPS (WISH) сосредоточена на разработке протокола для поддержки односторонних аудиовизуальных сеансов на основе WebRTC между инструментами вещания и сетями медиавещания в реальном времени. Аналогичная работа по расширению вариантов использования WebRTC ведется в W3C.
Завершение основных стандартов WebRTC потребовало огромных усилий со стороны десятков участников IETF и W3C на протяжении многих лет. Конечным результатом стал чрезвычайно популярный технологический пакет, который выполняет основное предназначение Интернета — ежедневное соединение людей в глобальном масштабе. Будет интересно посмотреть, что ждет нас в будущем, поскольку сообщество IETF продолжает развивать этот успех.
Поделиться этой страницей
Интернет-стандарты, разработанные IETF сегодня, обеспечивают Интернет завтрашнего дня. Работа IETF приносит пользу каждому, кто вкладывает свое время и талант. Прямо сейчас вы также можете поддержать будущее IETF, сделав подарок Фонду IETF, и Интернет-сообщество удвоит ваш подарок.
- Lee-Berkeley ShawIETF Administration LLC Директор по развитию
14 декабря 2022 г.
Хакатон IETF 115 прошел 5-6 ноября в Лондоне.
350 человек зарегистрировались для участия на месте и еще более 100 зарегистрировались для удаленного участия, чтобы работать над 39 проектами практически во всех областях работы IETF, что ознаменовало возвращение к допандемическим уровням участия.- Чарльз Экель Сопредседатель IETF Hackathon
13 декабря 2022 г.
В прошлом месяце у меня была возможность посетить первое совещание Целевой группы по проектированию Интернета, IETF 115, которое проходило в Лондоне. Это был отличный опыт, и я смог многому научиться у многих присутствовавших сетевых специалистов.
- Момока Ямамото
6 декабря 2022 г.
На этом семинаре IAB рассматривается, что могут сделать технологи и разработчики стандартов, чтобы снизить затраты или увеличить выгоды от воздействия интернет-приложений и систем на окружающую среду.
Саловейтлс Председатель рабочей группы
2, можно было безопасно развернуть, несколько известных уязвимостей использовали необязательные части протокола и устаревшие алгоритмы. TLS 1.3 удаляет многие из этих проблемных опций и поддерживает только алгоритмы без известных уязвимостей. На протяжении разработки TLS 1.3 рабочая группа IETF TLS взаимодействовала с сообществом криптографических исследователей для анализа, улучшения и проверки безопасности TLS 1.3. Это включало несколько семинаров, на которых исследователи могли представить свои выводы, например, семинар TRON, организованный в связи с конференцией NDSS 2016, и дал не менее 15 высокоцитируемых рецензируемых статей на известных научных конференциях.
В результате текущие коммуникации останутся безопасными, даже если будущие коммуникации будут скомпрометированы.
Это сотрудничество помогает продемонстрировать совместимость, отловить документацию и ошибки реализации и, в конечном счете, гарантировать, что спецификация станет надежной ссылкой для других, желающих внедрить TLS 1.3. Эта работа помогла сделать TLS 1.3 частью дорожной карты для многих компаний, и она готова быстро и широко стать доступной для широкого круга пользователей Интернета. Растущий список реализаций можно найти здесь.
3? Большинство современных веб-браузеров и многие приложения, которые вы, вероятно, используете, уже поддерживают TLS 1.3. Для тех, кто в настоящее время не поддерживает протокол, мы ожидаем, что будущие обновления обеспечат поддержку. Точно так же, если вы управляете веб-сайтом или другим онлайн-сервисом, серверы и инфраструктура, которые вы используете, скорее всего, начнут использовать TLS 1.3, хотя стоит дважды проверить это у ваших провайдеров. Если вы разрабатываете или внедряете программное обеспечение или службы, используемые другими в Интернете, и еще не используете TLS 1.3 как часть своей дорожной карты, вам следует посмотреть, что делают другие, и соответствующим образом спланировать.
Работа IETF приносит пользу каждому, кто вкладывает свое время и талант. Прямо сейчас вы также можете поддержать будущее IETF, сделав подарок Фонду IETF, и Интернет-сообщество удвоит ваш подарок.
Это был отличный опыт, и я смог многому научиться у многих присутствовавших сетевых специалистов.
Работа IETF приносит пользу каждому, кто вкладывает свое время и талант. Прямо сейчас вы также можете поддержать будущее IETF, сделав подарок Фонду IETF, и Интернет-сообщество удвоит ваш подарок.
Это был отличный опыт, и я смог многому научиться у многих присутствовавших сетевых специалистов.
Ранее на этой неделе W3C опубликовал WebRTC 1.0, веб-API, которые делают возможными вызовы между браузерами. Еще до окончательной доработки этих спецификаций — фактически за несколько лет до этого — технологии WebRTC развертывались и использовались как часть большинства современных сервисов, использующих голос или видео, в том числе многих, не использующих веб-браузеры. Наличие кода WebRTC, API и стандартов упростило добавление функций связи в реальном времени в любое приложение. И эта широкая доступность была настоящим спасательным кругом во время COVID-19.пандемия.
350 человек зарегистрировались для участия на месте и еще более 100 зарегистрировались для удаленного участия, чтобы работать над 39 проектами практически во всех областях работы IETF, что ознаменовало возвращение к допандемическим уровням участия.