Terminology for Describing Internet Connectivity
RFC 4084 устанавливает нейтральную терминологию для описания услуг подключения к Интернету, чтобы уменьшить путаницу у потребителей из-за различий в предоставляемых возможностях. Документ различает несколько уровней услуг — от подключения только к Web до полного подключения к Интернету — и поясняет их свойства в отношении адресации, серверов, NAT, прокси и фильтрации. Для отдельных ограничений, особенно связанных с электронной почтой и фильтрацией, документ устанавливает или рекомендует раскрытие информации; раздел 4 перечисляет дополнительные сведения, которые поставщик может решить предоставить. Это BCP 104, предназначенный для поставщиков услуг, потребителей и, возможно, регулирующих органов.
Рабочая группа по сетям J. Klensin
Запрос комментариев: 4084 Май 2005
BCP: 104
Категория: Лучшая современная практика
Терминология для описания интернет-подключения
Статус данного документа
Этот документ определяет Лучшие современные практики Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого документа не ограничено.
Уведомление об авторских правах
Авторские права (C) The Internet Society (2005).
Аннотация
По мере развития Интернета множество видов предложений рекламировались
и продавались как «интернет-подключение». Поскольку они могут
существенно различаться предоставляемыми возможностями, диапазоном
вариантов и отсутствием какой-либо стандартной терминологии, попытки
различать эти услуги вызвали значительную путаницу у потребителей.
Этот документ предоставляет перечень терминов и определений, которые
могут быть полезны поставщикам, потребителям и, возможно, регуляторам
для разъяснения типа и характера предлагаемых услуг.
Содержание
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Проблема и требование . . . . . . . . . . . . . . . . . 2
1.2. Принятие и непейоративная терминология . . . . . . . . 2
2. Общая терминология . . . . . . . . . . . . . . . . . . . . . 3
3. Вопросы фильтрации или безопасности и терминология . . . . . . 5
4. Дополнительная терминология . . . . . . . . . . . . . . . . . 7
5. Соображения безопасности . . . . . . . . . . . . . . . . . . 9
6. Благодарности . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Информативные ссылки . . . . . . . . . . . . . . . . . . . . 9
Klensin Лучшая современная практика [Страница 1]
RFC 4084 Термины IP-услуг Май 2005
1. Введение
1.1. Проблема и требование
Разные ISP и другие поставщики предлагают широкий спектр продуктов,
обозначаемых как «Интернет» или «доступ к Интернету». Эти продукты
предлагают разные виды функциональности, и вследствие этого некоторые
могут подходить для определённых пользователей и способов применения,
но не для других. Например, услуга, предоставляющая доступ только к Web
(в данном контексте — той части Интернета, которая доступна через
протоколы HTTP и HTTPS), может подходить тому, кто заинтересован
исключительно в просмотре Web и почтовых услугах на основе Web. Она не
будет подходить тому, кому необходимо загружать файлы или чаще
пользоваться электронной почтой. И она, вероятно, будет ещё менее
подходить тому, кому необходимо эксплуатировать серверы для других
пользователей, кому требуются возможности виртуальной частной сети
(VPN) или другой защищённый доступ к удалённому офису либо кому
необходимо синхронизировать почту для автономного использования.
Недавние и быстро развивающиеся изменения в среде электронной почты
Интернета привели к дополнительным ограничениям на отправку и
получение электронной почты. Эти ограничения, большинство из которых
разработано в рамках добросовестных попыток предотвратить
нежелательную почту или бороться с ней, могут вводиться независимо от
описанных ниже типов услуг и отдельно рассматриваются в разделе 3.
Этот документ описывает только функции, предоставляемые или
разрешённые поставщиком услуг. Он не описывает и не может описывать
функции, проходящие через различное оборудование, предоставленное
пользователем, и поддерживаемые им.
Термины СЛЕДУЕТ (SHOULD), ДОЛЖЕН (MUST) и МОЖЕТ (MAY) в этом документе
пишутся прописными буквами в соответствии с определением в [1].
1.2. Принятие и непейоративная терминология
Предлагаемые здесь определения имеют небольшую ценность, если
поставщики услуг и производители не готовы их принять. Предлагаемые
термины не имеют целью быть пейоративными, несмотря на мнение
некоторых членов сообщества IETF, что некоторые из этих моделей
подключения просто «неработоспособны» или «на самом деле не являются
интернет-услугой». Упоминание в этом документе конкретной услуги или
модели не подразумевает её одобрения, а лишь признаёт нечто, что
существует или может существовать на рынке. Таким образом, описанная
в этом документе Лучшая современная практика относится к терминологии
и информации, которую следует предоставлять пользователю, а не к
типам услуг, которые следует предлагать.
Klensin Лучшая современная практика [Страница 2]
RFC 4084 Термины IP-услуг Май 2005
2. Общая терминология
В этом разделе перечислены основные термины IP-услуг. Есть надежда,
что поставщики услуг примут эти термины, чтобы лучше определять услуги
для потенциальных пользователей или клиентов. Термины относятся к
намерению поставщика (ISP), выраженному либо техническими мерами, либо
условиями предоставления услуги. Может быть возможно обойти конкретные
реализации этих характерных типов подключения, но такая свобода в
целом не является намерением поставщика и вряд ли будет поддержана,
если обходные решения перестанут работать.
Термины услуг перечислены в порядке возрастания возможностей, чтобы
достичь «полного интернет-подключения».
o Web-подключение.
Эта услуга предоставляет подключение к Web, то есть к услугам,
поддерживаемым через «Web-браузер» (такой как Firefox, Internet
Explorer, Mozilla, Netscape, Lynx или Opera), особенно к услугам,
использующим протоколы HTTP или HTTPS. Другие услуги, как правило,
не поддерживаются. В частности, может не быть доступа к электронной
почте POP3 или IMAP4, зашифрованным туннелям или другим механизмам
VPN.
Используемые адреса могут быть частными и/или недостижимыми
глобально. Как правило, они динамические (дальнейшее обсуждение
этой терминологии и её последствий см. в обсуждении динамических
адресов в разделе 3) и относительно кратковременные (часы или дни,
а не месяцы или годы). Эти адреса часто объявляются как
«динамические» тем, кто ведёт списки коммутируемых или динамических
адресов. Поставщик может применять к соединениям фильтрующий
Web-прокси; этот прокси может изменять и перенаправлять URL на
сайты, отличные от сайта, первоначально указанного пользователем
или во встроенной ссылке.
o Подключение только клиента, без публичного адреса.
Эта услуга предоставляет доступ к Интернету без поддержки серверов
или большинства одноранговых функций. IP-адрес, назначаемый клиенту,
является динамическим и обычно назначается из непубличного
адресного пространства. Серверы и одноранговые функции обычно не
поддерживаются системами преобразования сетевых адресов (NAT),
необходимость которых обусловлена использованием частных адресов.
(Более точная классификация типов NAT, приведённая в [2], в
некоторой степени ортогональна этому документу, однако она может
предоставляться как дополнительные термины, как описано в разделе
4.)
Klensin Лучшая современная практика [Страница 3]
RFC 4084 Термины IP-услуг Май 2005
Фильтрующие Web-прокси распространены при таком типе услуг, и
поставщику СЛЕДУЕТ (SHOULD) указывать, присутствует ли такой прокси.
o Только клиент, публичный адрес.
Эта услуга предоставляет доступ к Интернету без поддержки серверов
или большинства одноранговых функций. IP-адрес, назначаемый клиенту,
находится в публичном адресном пространстве. Обычно он номинально
является динамическим или иным образом может измениться, но может
не изменяться месяцами. Большинство VPN и сходных подключений будут
работать с этой услугой. Поставщик может запрещать использование
серверных функций либо юридическими (договорными) ограничениями,
либо фильтрацией входящих попыток подключения.
Фильтрующие Web-прокси необычны при таком типе услуг, и поставщику
СЛЕДУЕТ (SHOULD) указывать, если такой прокси присутствует.
o Интернет-подключение с межсетевым экраном.
Эта услуга предоставляет доступ к Интернету и поддерживает
большинство серверов и большинство одноранговых функций с одним или
(обычно) несколькими статическими публичными адресами. Она сходна с
«Полным интернет-подключением», описанным ниже, и применимы все
описанные там оговорки и ограничения. Однако в рамках этой услуги
между клиентом и публичным Интернетом размещается управляемый
поставщиком «межсетевой экран», обычно по запросу клиента и за
дополнительную плату по сравнению с услугами без межсетевого
экрана. Обычно в силу договорных соглашений с клиентом это может
приводить к блокированию некоторых услуг.
Другие услуги могут перехватываться прокси, механизмами фильтрации
содержимого или шлюзами приложений. Поставщику СЛЕДУЕТ (SHOULD)
указывать, какие услуги блокируются и какие перехватываются или
изменяются иными способами.
В большинстве регионов такой вариант услуги предлагается как
дополнительная платная опция к тому, что иначе было бы Полным
интернет-подключением. Он отличается от приведённых выше моделей
тем, что любые услуги фильтрации или блокирования в конечном счёте
выполняются по запросу клиента, а не навязываются как ограничения
услуги.
o Полное интернет-подключение.
Эта услуга предоставляет пользователю полное интернет-подключение
с одним или несколькими статическими публичными адресами.
Динамические адреса, существующие достаточно долго, чтобы сделать
эксплуатацию серверов практически осуществимой без записей DNS с
высокой динамичностью, возможны при условии, что для третьих сторон
они не характеризуются как «динамические».
Klensin Лучшая современная практика [Страница 4]
RFC 4084 Термины IP-услуг Май 2005
Фильтрующие Web-прокси, прокси перехвата, NAT и другие навязываемые
поставщиком ограничения на входящие или исходящие порты и трафик
несовместимы с таким типом услуги. Серверы в подключённой локальной
сети клиента обычно считаются нормальным явлением. Единственными
совместимыми ограничениями являются ограничения пропускной
способности и запреты на злоупотребление сетью или незаконную
деятельность.
3. Вопросы фильтрации или безопасности и терминология
Как упоминалось во Введении, стремление контролировать или ограничить
нежелательный сетевой трафик привело к дополнительным ограничениям
поведения и возможностей интернет-услуг. Такой нежелательный трафик
может включать нежелательную почту различных типов (включая «спам»),
черви, вирусы и их воздействие, а в некоторых случаях — конкретное
содержимое.
В целом существенные ограничения наиболее вероятны при Web-подключении
и услугах без публичного адреса, но некоторые текущие рекомендации
применяли бы ограничения на всех уровнях. Некоторые из этих почтовых
ограничений могут предотвращать отправку исходящей почты (кроме как
через серверы, эксплуатируемые ISP для этой цели), могут предотвращать
использование обратных адресов по выбору пользователя и могут даже
предотвращать доступ к хранилищам почты (кроме поставляемых
поставщиком) с помощью протоколов удалённого доступа, таких как POP3
или IMAP4. Поскольку у пользователей могут быть обоснованные причины
для доступа к удалённым файловым службам, удалённым серверам отправки
почты (или, по меньшей мере, для использования предпочитаемых ими
адресов электронной почты из нескольких мест) и для доступа к удалённым
хранилищам почты (опять же, почти необходимого условия при
использовании одного адреса), важно, чтобы поставщики раскрывали,
какие услуги они предоставляют, а также фильтры и условия, которые
они вводят.
Несколько ключевых вопросов фильтрации электронной почты имеют особую
важность.
o Динамические адреса.
Ряд систем, включая несколько систем «чёрных списков», основан на
предположении, что большинство нежелательной электронной почты
исходит от систем с динамическими адресами, особенно систем
коммутируемого доступа и домашних широкополосных систем. Поэтому
они пытаются предотвратить использование этих адресов для отправки
почты или выполнения некоторых других услуг, кроме как через
системы поставщика, назначенные для этой цели.
Для выявления систем с динамическими адресами используются разные
методы, включая объявление поставщиком таких адресов операторам
чёрных списков, эвристики, использующие определённые диапазоны
адресов, и проверку доменных имён обратного отображения, чтобы
установить, содержат ли они характерные строки, такие как «dsl» или
«dial». В некоторых случаях отсутствие DNS-адреса обратного
отображения принимается как указание на то, что адрес является
«динамическим». (Запрет соединений на основании отсутствия записи
DNS обратного отображения был методом, разработанным для FTP-серверов
много лет назад; было установлено, что он имеет довольно высокую
частоту отказов: как запрещая допустимые попытки подключения, так и
не предотвращая недопустимые.) Поставщикам услуг СЛЕДУЕТ (SHOULD)
описывать, что они делают в этой области для входящего и исходящего
трафика сообщений, и пользователям следует знать, что если адрес
объявлен как «динамический», использовать его для отправки почты
произвольной системе может быть невозможно, даже если в остальном
предоставляется Полное интернет-подключение.
o Непубличные адреса и NAT.
Системы NAT, используемые для отображения между частным и публичным
адресными пространствами, могут поддерживать соединения с удалёнными
почтовыми системами для исходящей и входящей почты, но условия
предоставления услуг часто запрещают использование систем, не
поставляемых поставщиком подключения, и запрещают эксплуатацию
«серверов» (обычно без точного определения) на клиентском
подключении.
o Фильтрация исходящих портов поставщиком.
Другой распространённый приём заключается в блокировании соединений с
серверами, не находящимися под контролем провайдера, путём блокирования
TCP-«портов», обычно используемых для функций обмена сообщениями. У разных
провайдеров разные представления об этом. Некоторые запрещают своим клиентам
обращаться к внешним SMTP-серверам для отправки сообщений, но разрешают
использовать протокол передачи сообщений ([3]) с аутентификацией отправителя.
Другие пытаются блокировать все исходящие протоколы, связанные с обменом
сообщениями, включая протоколы удалённого получения почты; однако это менее
распространено в службах с публичными адресами, чем в службах, зависящих от
частных адресов и NAT. Если присутствует фильтрация такого типа, особенно в
службах «Только клиент, публичный адрес» и «Полная связность с Интернетом»,
провайдер ДОЛЖЕН (MUST) указать этот факт (см. также раздел 4).
Третьи могут перенаправлять исходящий почтовый трафик на собственные
серверы, исходя из того, что это устраняет необходимость перенастраивать
переносные машины при их подключении из другого сетевого местоположения.
Опять же, такое перенаправление ДОЛЖНО (MUST) раскрываться, особенно потому,
что оно может иметь существенные последствия для безопасности и
конфиденциальности.
Klensin Лучшая современная практика [Страница 6]
RFC 4084 Термины IP-служб Май 2005
В более общем случае фильтры, блокирующие часть или всю почту,
отправляемую в удалённые системы (или передаваемую им) (иначе чем через
поддерживаемые провайдером серверы), либо пытающиеся перенаправить этот трафик
на собственные серверы, как обсуждалось выше, становятся обычным явлением и
их СЛЕДУЕТ (SHOULD) раскрывать.
4. Дополнительная терминология
Эти дополнительные термины, хотя и не столь существенные для понимания
предложения службы, как указанные выше, приводятся как дополнительная
информация, которую провайдер службы может выбрать для предоставления в
dополнение к этим общим определениям. Например, потенциальный клиент может
использовать относящиеся к нему термины, чтобы составить перечень конкретных
вопросов.
o Поддержка версий.
Включает ли служба поддержку только IPv4, поддержку как IPv4, так и
IPv6 либо только поддержку IPv6?
o Поддержка аутентификации.
Какие технические механизмы используются службой для установления и,
возможно, аутентификации соединений? Примерами могут быть DHCP без
aутентификации, PPP, RADIUS или перехват HTTP.
o VPN и туннели.
Блокируется или разрешается IPSec? Разрешаются ли другие методы
туннелирования на IP-уровне или ниже него, такие как L2TP? Предпринимаются ли
какие-либо попытки блокировать механизмы туннелирования на уровне приложений,
такие как SSH?
o Поддержка многоадресной рассылки
Имеет ли пользовательская машина доступ к пакетам и службам
многоадресной рассылки?
o Поддержка DNS.
Обязаны ли пользователи использовать DNS-серверы, предоставляемые
провайдером службы, или DNS-запросам разрешено достигать произвольных
серверов?
o Службы, связанные с IP.
Блокируются или разрешаются в целом сообщения ICMP к площадкам конечных
пользователей и от них? Блокируются ли конкретные функции, такие как ping и
traceroute, и, если да, в какой точке сети?
Klensin Лучшая современная практика [Страница 7]
RFC 4084 Термины IP-служб Май 2005
o Поддержка роуминга.
Преднамеренно ли служба включает поддержку IP-роуминга и, если да, как
это определяется? Предусмотрена ли для «широкополосных» подключений какая-либо
схема коммутируемого доступа для резервирования или поездок клиента? Если она
присутствует, имеет ли эта схема полный доступ к почтовым ящикам и т. д.?
o Предоставляемые службы приложений.
Предоставляются ли в составе службы почтовые службы и/или Web-хостинг и
на каких условиях? В перечне почтовых служб следует указать, предоставляются ли
POP3, IMAP4 или Web-доступ, в каких сочетаниях, а также какие типы служб
aутентификации и конфиденциальности поддерживаются или требуются для каждого из
них.
o Использование и блокирование исходящих служб приложений.
Блокирует ли служба использование SMTP или передачу почты не на свои
серверы либо перехватывает такие передачи и направляет их на свои серверы?
Ограничивают ли её серверы пользователя использованием её доменных имён в
исходящей электронной почте? (Относительно электронной почты в частности также
см. раздел 3 выше.) Поддерживается или блокируется команда FTP PASV?
Применяются ли блокировки или перехваты к другим механизмам совместного
использования либо передачи файлов, к приложениям для конференций или к частным
службам приложений?
В более общем случае провайдеру следует указывать любые действия службы
по блокированию, ограничению или изменению назначения исходящего использования
(т. е. использования служб, не поставляемых провайдером или не находящихся в
сети провайдера) служб приложений.
o Блокирование входящих служб приложений.
Помимо вопросов, обусловленных динамическим или частным адресным
пространством (когда оно имеется), предпринимает ли служба какие-либо другие
меры, специально ограничивающие соединения, которые могут устанавливаться с
оборудованием, эксплуатируемым клиентом? В частности, запрещены ли входящие
SMTP, HTTP или HTTPS, FTP либо различные одноранговые или другие соединения
(возможно, включая приложения, специально не распознаваемые провайдером) и,
если да, какие именно?
o Фильтрация содержимого приложений.
Службе следует объявить, предоставляет ли она фильтрацию или защиту от
червей или атак отказа в обслуживании, направленных против её клиентов,
фильтрацию вирусов и спама для её почтовых служб (если таковые имеются),
недискреционную фильтрацию содержимого или фильтрацию «родительского контроля»
и так далее.
Klensin Лучшая современная практика [Страница 8]
RFC 4084 Термины IP-служб Май 2005
o Прослушивание и перехват.
Службе СЛЕДУЕТ (SHOULD) указывать, подлежит ли проходящий через неё
трафик законному перехвату и будет ли провайдер предпринимать упреждающую
попытку уведомить пользователя о таком перехвате, когда такое уведомление
законно. Аналогичные вопросы можно задать о данных трафика, которые хранятся
для возможного использования правоохранительными органами.
5. Соображения безопасности
Этот документ посвящён терминологии, а не протоколам, поэтому он не
поднимает каких-либо особых вопросов безопасности. Однако если предложенный
тип терминологии будет широко принят, может стать проще выявлять связанные с
безопасностью ожидания для конкретных хостов, LAN и типов соединений.
6. Благодарности
Этот документ был вдохновлён перепиской по электронной почте с Vernon
Schryver, Paul Vixie и Nathaniel Bornstein. Хотя предложения выработать такие
определения существовали много лет, та переписка убедила автора, что наконец
пришло время вынести на обсуждение исходный вариант, чтобы посмотреть, сможет
ли IETF действительно продвинуть его дальше. Harald Alvestrand, Brian
Carpenter, George Michaelson, Vernon Schryver и другие внесли несколько
предложений к первоначальному черновику, в результате чего были уточнены
формулировки второго, а Stephane Bortzmeyer, Brian Carpenter, Tony Finch, Susan
Harris, David Kessens, Pekka Savola и Vernon Schryver внесли весьма полезные
предложения, которые были включены в последующие версии. Susan Harris также
исключительно внимательно прочитала предпоследнюю версию, за что выражается
большая признательность, как и за редакторские предложения RFC Editor.
7. Информационные ссылки
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
Klensin Лучшая современная практика [Страница 9]
RFC 4084 Термины IP-служб Май 2005
Адрес автора
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Телефон: +1 617 491 5735
EMail: john-ietf@jck.com
Klensin Лучшая современная практика [Страница 10]
RFC 4084 Термины IP-служб Май 2005
Полное заявление об авторских правах
Copyright (C) The Internet Society (2005).
Этот документ подпадает под действие прав, лицензий и ограничений,
содержащихся в BCP 78, и, за исключением предусмотренного в нём, авторы
сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ
СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING
TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ,
ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ
ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ЛИБО ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ
ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма любых
прав интеллектуальной собственности либо иных прав, которые могут заявляться
как относящиеся к реализации или использованию технологии, описанной в этом
dокументе, или относительно того, может ли быть доступна какая-либо лицензия на
такие права; также IETF не заявляет, что предприняла какие-либо независимые
усилия по выявлению таких прав. Информация о процедурах IETF в отношении прав в
документах IETF содержится в BCP 78 и BCP 79.
Копии раскрытий IPR, сделанных Секретариату IETF, и любые заверения о
лицензиях, которые будут предоставлены, либо результат попытки получить общую
лицензию или разрешение на использование таких имущественных прав разработчиками
или пользователями этой спецификации можно получить из интерактивного
репозитория IPR IETF по адресу
http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне довести до её сведения любые
авторские права, патенты или патентные заявки либо иные имущественные права,
которые могут охватывать технологию, которая может потребоваться для реализации
этого стандарта. Просим направлять информацию в IETF по адресу ietf-
ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивается
Internet Society.
Klensin Лучшая современная практика [Страница 11]
Network Working Group J. Klensin
Request for Comments: 4084 May 2005
BCP: 104
Category: Best Current Practice
Terminology for Describing Internet Connectivity
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
As the Internet has evolved, many types of arrangements have been
advertised and sold as "Internet connectivity". Because these may
differ significantly in the capabilities they offer, the range of
options, and the lack of any standard terminology, the effort to
distinguish between these services has caused considerable consumer
confusion. This document provides a list of terms and definitions
that may be helpful to providers, consumers, and, potentially,
regulators in clarifying the type and character of services being
offered.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Problem and the Requirement . . . . . . . . . . . . 2
1.2. Adoption and a Non-pejorative Terminology . . . . . . . 2
2. General Terminology . . . . . . . . . . . . . . . . . . . . . 3
3. Filtering or Security Issues and Terminology . . . . . . . . . 5
4. Additional Terminology . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 9
Klensin Best Current Practice [Page 1]
RFC 4084 IP Service Terms May 2005
1. Introduction
1.1. The Problem and the Requirement
Different ISPs and other providers offer a wide variety of products
that are identified as "Internet" or "Internet access". These
products offer different types of functionality and, as a result,
some may be appropriate for certain users and uses and not others.
For example, a service that offers only access to the Web (in this
context, the portion of the Internet that is accessible via the HTTP
and HTTPS protocols) may be appropriate for someone who is
exclusively interested in browsing and in Web-based email services.
It will not be appropriate for someone who needs to download files or
use email more frequently. And it is likely to be even less
appropriate for someone who needs to operate servers for other users,
who needs virtual private network (VPN) capabilities or other secured
access to a remote office, or who needs to synchronize mail for
offline use.
Recent and rapidly evolving changes to the Internet's email
environment have led to additional restrictions on sending and
retrieving email. These restrictions, most of them developed as part
of well intentioned attempts to prevent or fight unsolicited mail,
may be imposed independently of the service types described below and
are discussed separately in Section 3.
This document describes only the functions provided or permitted by
the service provider. It does not and cannot specify the functions
that pass through and are supported by various user-provided
equipment.
The terms SHOULD, MUST, or MAY are capitalized in this document, as
defined in [1].
1.2. Adoption and a Non-pejorative Terminology
The definitions proposed here are of little value if service
providers and vendors are not willing to adopt them. The terms
proposed are intended not to be pejorative, despite the belief of
some members of the IETF community that some of these connectivity
models are simply "broken" or "not really an Internet service". The
mention of a particular service or model in this document does not
imply any endorsement of it, only recognition of something that
exists or might exist in the marketplace. Thus, the Best Current
Practice described in this document is about terminology and
information that should be supplied to the user and not about the
types of service that should be offered.
Klensin Best Current Practice [Page 2]
RFC 4084 IP Service Terms May 2005
2. General Terminology
This section lists the primary IP service terms. It is hoped that
service providers will adopt these terms, to better define the
services to potential users or customers. The terms refer to the
intent of the provider (ISP), as expressed in either technical
measures or terms and conditions of service. It may be possible to
work around particular implementations of these characteristic
connectivity types, but that freedom is generally not the intent of
the provider and is unlikely to be supported if the workarounds stop
working.
The service terms are listed in order of ascending capability, to
reach "full Internet connectivity".
o Web connectivity.
This service provides connectivity to the Web, i.e., to services
supported through a "Web browser" (such as Firefox, Internet
Explorer, Mozilla, Netscape, Lynx, or Opera), particularly those
services using the HTTP or HTTPS protocols. Other services are
generally not supported. In particular, there may be no access to
POP3 or IMAP4 email, encrypted tunnels or other VPN mechanisms.
The addresses used may be private and/or not globally reachable.
They are generally dynamic (see the discussion of dynamic
addresses in Section 3 for further discussion of this terminology
and its implications) and relatively short-lived (hours or days
rather than months or years). These addresses are often announced
as "dynamic" to those who keep lists of dial-up or dynamic
addresses. The provider may impose a filtering Web proxy on the
connections; that proxy may change and redirect URLs to other
sites than the one originally specified by the user or embedded
link.
o Client connectivity only, without a public address.
This service provides access to the Internet without support for
servers or most peer-to-peer functions. The IP address assigned
to the customer is dynamic and is characteristically assigned from
non-public address space. Servers and peer-to-peer functions are
generally not supported by the network address translation (NAT)
systems that are required by the use of private addresses. (The
more precise categorization of types of NATs given in [2] are
somewhat orthogonal to this document, but they may be provided as
additional terms, as described in Section 4.)
Klensin Best Current Practice [Page 3]
RFC 4084 IP Service Terms May 2005
Filtering Web proxies are common with this type of service, and
the provider SHOULD indicate whether or not one is present.
o Client only, public address.
This service provides access to the Internet without support for
servers or most peer-to-peer functions. The IP address assigned
to the customer is in the public address space. It is usually
nominally dynamic or otherwise subject to change, but it may not
change for months at a time. Most VPN and similar connections
will work with this service. The provider may prohibit the use of
server functions by either legal (contractual) restrictions or by
filtering incoming connection attempts.
Filtering Web proxies are uncommon with this type of service, and
the provider SHOULD indicate if one is present.
o Firewalled Internet Connectivity.
This service provides access to the Internet and supports most
servers and most peer-to-peer functions, with one or (usually)
more static public addresses. It is similar to "Full Internet
Connectivity", below, and all of the qualifications and
restrictions described there apply. However, this service places
a provider-managed "firewall" between the customer and the public
Internet, typically at customer request and at extra cost compared
to non-firewalled services. Typically by contractual arrangements
with the customer, this may result in blocking of some services.
Other services may be intercepted by proxies, content-filtering
arrangements, or application gateways. The provider SHOULD
specify which services are blocked and which are intercepted or
altered in other ways.
In most areas, this service arrangement is offered as an add-on,
extra-cost, option with what would otherwise be Full Internet
Connectivity. It is distinguished from the models above by the
fact that any filtering or blocking services are ultimately
performed at customer request, rather than being imposed as
service restrictions.
o Full Internet Connectivity.
This service provides the user full Internet connectivity, with
one or more static public addresses. Dynamic addresses that are
long-lived enough to make operating servers practical without
highly dynamic DNS entries are possible, provided that they are
not characterized as "dynamic" to third parties.
Klensin Best Current Practice [Page 4]
RFC 4084 IP Service Terms May 2005
Filtering Web proxies, interception proxies, NAT, and other
provider-imposed restrictions on inbound or outbound ports and
traffic are incompatible with this type of service. Servers on a
connected customer LAN are typically considered normal. The only
compatible restrictions are bandwidth limitations and prohibitions
against network abuse or illegal activities.
3. Filtering or Security Issues and Terminology
As mentioned in the Introduction, the effort to control or limit
objectionable network traffic has led to additional restrictions on
the behavior and capabilities of internet services. Such
objectionable traffic may include unsolicited mail of various types
(including "spam"), worms, viruses, and their impact, and in some
cases, specific content.
In general, significant restrictions are most likely to be
encountered with Web connectivity and non-public-address services,
but some current recommendations would apply restrictions at all
levels. Some of these mail restrictions may prevent sending outgoing
mail (except through servers operated by the ISP for that purpose),
may prevent use of return addresses of the user's choice, and may
even prevent access to mail repositories (other than those supplied
by the provider) by remote-access protocols such as POP3 or IMAP4.
Because users may have legitimate reasons to access remote file
services, remote mail submission servers (or, at least, to use their
preferred email addresses from multiple locations), and to access
remote mail repositories (again, a near-requirement if a single
address is to be used), it is important that providers disclose the
services they are making available and the filters and conditions
they are imposing.
Several key issues in email filtering are of particular importance.
o Dynamic Addresses.
A number of systems, including several "blacklist" systems, are
based on the assumption that most undesired email originates from
systems with dynamic addresses, especially dialup and home
broadband systems. Consequently, they attempt to prevent the
addresses from being used to send mail, or perform some other
services, except through provider systems designated for that
purpose.
Different techniques are used to identify systems with dynamic
addresses, including provider advertising of such addresses to
blacklist operators, heuristics that utilize certain address
ranges, and inspection of reverse-mapping domain names to see if
Klensin Best Current Practice [Page 5]
RFC 4084 IP Service Terms May 2005
they contain telltale strings such as "dsl" or "dial". In some
cases, the absence of a reverse-mapping DNS address is taken as an
indication that the address is "dynamic". (Prohibition on
connections based on the absence of a reverse-mapping DNS record
was a technique developed for FTP servers many years ago; it was
found to have fairly high rates of failure, both prohibiting
legitimate connection attempts and failing to prevent illegitimate
ones). Service providers SHOULD describe what they are doing in
this area for both incoming and outgoing message traffic, and
users should be aware that, if an address is advertised as
"dynamic", it may be impossible to use it to send mail to an
arbitrary system even if Full Internet Connectivity is otherwise
provided.
o Non-public addresses and NATs.
The NAT systems that are used to map between private and public
address spaces may support connections to distant mail systems for
outbound and inbound mail, but terms of service often prohibit the
use of systems not supplied by the connectivity provider and
prohibit the operation of "servers" (typically not precisely
defined) on the client connection.
o Outbound port filtering from the provider.
Another common technique involves blocking connections to servers
outside the provider's control by blocking TCP "ports" that are
commonly used for messaging functions. Different providers have
different theories about this. Some prohibit their customers from
accessing external SMTP servers for message submission, but they
permit the use of the mail submission protocol ([3]) with sender
authentication. Others try to block all outgoing messaging-
related protocols, including remote mail retrieval protocols;
however, this is less common with public-address services than
those that are dependent on private addresses and NATs. If this
type of filtering is present, especially with "Client only, public
address" and "Full Internet Connectivity" services, the provider
MUST indicate that fact (see also Section 4).
Still others may divert (reroute) outbound email traffic to their
own servers, on the theory that this eliminates the need for
reconfiguring portable machines as they connect from a different
network location. Again, such diversion MUST be disclosed,
especially since it can have significant security and privacy
implications.
Klensin Best Current Practice [Page 6]
RFC 4084 IP Service Terms May 2005
More generally, filters that block some or all mail being sent to
(or submitted to) remote systems (other than via provider-
supported servers), or that attempt to divert that traffic to
their own servers, are, as discussed above, becoming common and
SHOULD be disclosed.
4. Additional Terminology
These additional terms, while not as basic to understanding a service
offering as the ones identified above, are listed as additional
information that a service provider might choose to provide to
complement those general definitions. A potential customer might use
those that are relevant to construct a list of specific questions to
ask, for example.
o Version support.
Does the service include IPv4 support only, both IPv4 and IPv6
support, or IPv6 support only?
o Authentication support.
Which technical mechanism(s) are used by the service to establish
and possibly authenticate connections? Examples might include
unauthenticated DHCP, PPP, RADIUS, or HTTP interception.
o VPNs and Tunnels.
Is IPSec blocked or permitted? Are other tunneling techniques at
the IP layer or below, such as L2TP, permitted? Is there any
attempt to block applications-layer tunnel mechanisms such as SSH?
o Multicast support
Does the user machine have access to multicast packets and
services?
o DNS support.
Are users required to utilize DNS servers provided by the service
provider, or are DNS queries permitted to reach arbitrary servers?
o IP-related services.
Are ICMP messages to and from end user sites generally blocked or
permitted? Are specific functions such as ping and traceroute
blocked and, if so, at what point in the network?
Klensin Best Current Practice [Page 7]
RFC 4084 IP Service Terms May 2005
o Roaming support.
Does the service intentionally include support for IP roaming and,
if so, how is this defined? For "broadband" connections, is some
dialup arrangement provided for either backup or customer travel?
If present, does that arrangement have full access to mailboxes,
etc.
o Applications services provided.
Are email services and/or Web hosting provided as part of the
service, and on what basis? An email services listing should
identify whether POP3, IMAP4, or Web access are provided and in
what combinations, and what types of authentication and privacy
services are supported or required for each.
o Use and Blocking of Outbound Applications Services.
Does the service block use of SMTP or mail submission to other
than its own servers or intercept such submissions and route them
to its servers? Do its servers restrict the user to use of its
domain names on outbound email? (For email specifically, also see
Section 3 above.) Is the FTP PASV command supported or blocked?
Are blocks or intercepts imposed on other file sharing or file
transfer mechanisms, on conferencing applications, or on private
applications services?
More generally, the provider should identify any actions of the
service to block, restrict, or alter the destination of, the
outbound use (i.e., the use of services not supplied by the
provider or on the provider's network) of applications services.
o Blocking of Inbound Applications Services.
In addition to issues raised by dynamic or private address space
(when present), does the service take any other measures that
specifically restrict the connections that can be made to
equipment operated by the customer? Specifically, are inbound
SMTP, HTTP or HTTPS, FTP, or various peer-to-peer or other
connections (possibly including applications not specifically
recognized by the provider) prohibited and, if so, which ones?
o Application Content Filtering.
The service should declare whether it provides filtering or
protection against worms or denial of service attacks against its
customers, virus and spam filtering for its mail services (if
Klensin Best Current Practice [Page 8]
RFC 4084 IP Service Terms May 2005
any), non-discretionary or "parental control" filtering of
content, and so on.
o Wiretapping and interception.
The service SHOULD indicate whether traffic passing through it is
subject to lawful intercept, and whether the provider will make a
proactive attempt to inform the user of such an intercept when
such notice is legal. Analogous questions can be asked for
traffic data that is stored for possible use by law enforcement.
5. Security Considerations
This document is about terminology, not protocols, so it does not
raise any particular security issues. However, if the type of
terminology that is proposed is widely adopted, it may become easier
to identify security-related expectations of particular hosts, LANs,
and types of connections.
6. Acknowledgements
This document was inspired by an email conversation with Vernon
Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been
proposals to produce such definitions for many years, that
conversation convinced the author that it was finally time to put a
strawman on the table to see if the IETF could actually carry it
forward. Harald Alvestrand, Brian Carpenter, George Michaelson,
Vernon Schryver, and others made several suggestions on the initial
draft that resulted in clarifications to the second one and Stephane
Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, David Kessens,
Pekka Savola, and Vernon Schryver made very useful suggestions that
were incorporated into subsequent versions. Susan Harris also gave
the penultimate version an exceptionally careful reading, which is
greatly appreciated, as are editorial suggestions by the RFC Editor.
7. Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
Klensin Best Current Practice [Page 9]
RFC 4084 IP Service Terms May 2005
Author's Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Klensin Best Current Practice [Page 10]
RFC 4084 IP Service Terms May 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klensin Best Current Practice [Page 11]