RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy

Network Working Group                                      V. Fuller
Request for Comments: 1519                                   BARRNet
Obsoletes: 1338                                                T. Li
Category: Standards Track                                      cisco
                                                               J. Yu
                                                               MERIT
                                                         K. Varadhan
                                                              OARnet
                                                      September 1993

Бесклассовая междоменная маршрутизация (CIDR)

Выделение адресов и стратегия агрегирования

Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy

PDF

Статус документа

В данном RFC содержится спецификация стандарта, предложенного сообществу Internet; документ служит приглашением к дискуссии в целях совершенствования и развития данной спецификации. Информацию о текущем состоянии стандартизации для этого протокола вы можете найти в документе «Internet Official Protocol Standards». Документ может распространяться без ограничений.

Тезисы

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

Оглавление

Исключено в HTML-версиию

Благодарности

Авторы хотят выразить свою признательность участникам группы ROAD за использование в этом документе поданных ими идей.

1. Проблема, цели, мотивация

В последние годы сеть Internet развивается и растет, делая очевидными некоторые весьма серьезные проблемы масштабирования. К таким проблемам относятся:

  1. Нехватка адресного пространства для сетей класса B. Одной из основных причин этого является отсутствие класса адресов, подходящего по числу адресов для организаций средних размеров. Сети класса C могут включать до 254 адресов (слишком мало), а сети класса B позволяют адресовать до 65534 хостов, что является явным избытком для организации средних размеров. В результате блоки адресов класса B используются неэффективно.

  2. Избыток маршрутной информации. Размеры и скорость роста таблиц маршрутизации в маршрутизаторах Internet превосходят возможности существующих программ (и людей) по эффективному управлению этими таблицами.

  3. Общая нехватка номеров IP для сетей.

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

Предлагаемое решение состоит в топологическом распределении выделяемых вновь адресов IP с выделением сегментов адресного пространства IP транзитным доменам маршрутизации.

Предлагаемый в документе план распределения адресов IP следует реализовать как можно скорее. Мы надеемся, что этого будет достаточно на период поиска и реализации долговременного решения перечисленных проблем. Этот план решит проблемы по крайней мере на ближайшие три (3) года, в течение которых должно быть найдено подходящее долгосрочное решение.

Предлагаемый план направлен прежде всего на решение первых двух проблем. Мы надеемся, что разумное использование методов деления на подсети переменных размеров снизит также остроту проблемы нехватки 32-битового адресного пространства. Отметим также, что эффективные инструменты распределения адресов в мире с supernet и подсетями переменного размера окажет существенную помощь пользователям в принятии этих (порой недостаточно понятных) методов. Сообществу Internet следует приложить усилия к разработке простых инструментов для такого распределения.

Отметим, что этот план не требует и не предполагает заново распределять уже выданные адреса, хотя по возможности это следует сделать в целях дополнительного снижения размеров таблиц маршрутизации. Предполагается, что технологии маршрутизации смогут обеспечить работу с таблицами существующих размеров и даже при незначительном росте размера таблиц маршрутизации. Задачей предлагаемого плана является существенное снижение скорости роста размеров таблиц маршрутизации.

Отметим, что этот план не требует смены адресов в доменах, которые меняют подключенные к ним транзитные домены. Одобряется такая переадресация внутри доменов маршрутизации, которая не будет требовать анонсирования отдельных блоков, выделенных внутри домена.

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

2. Распределение адресов CIDR

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

2.1 Агрегирование и его ограничения

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

Существуют две ситуации, в которых теряется эффективность агрегирования маршрутов.

  • Организации с множеством подключений. Поскольку многодомные сети должны анонсироваться в систему каждым из сервис-провайдеров, зачастую не удается агрегировать маршруты в такие сети в адресное пространство каждого из провайдеров. Отметим, что такие организации могут по-прежнему использовать адреса из пространства транзитных доменов (в этом есть определенные преимущества), но их маршрутная информация должна явно анонсироваться большинством их сервис-провайдеров (исключением является случай, когда блок адресов получен от провайдера, маршрут к которому наименее предпочтителен, — в таких случаях этот провайдер может не анонсировать маршрут явно, поскольку выбор по максимальной длине соответствия обеспечит доступ к сайту при анонсировании агрегированного маршрута). В силу перечисленных причин “стоимость” маршрута в такие сети практически не будет изменяться по сравнению с существующей.

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

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

Имеет смысл также отметить, что агрегирование может выполняться на разных уровнях системы, что делает возможным агрегирование таких аномальных маршрутов на более высоких уровнях иерархии. Например, если многодомный сайт подключен к двум региональным сетям NSFNET и обе сети используют адреса из пространства NSFNET, агрегирование маршрутов произойдет на уровне NSFNET.

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

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

2.2 Распределенное выделение адресов

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

Следует также отметить, что по мере распространения протоколов бесклассовой междоменной маршрутизации описанные в этом плане правила могут быть использованы для выделения объединения (supernetting) или разбиения на подсети оставшегося свободным адресного пространства классов A и B (в предположении, что бесклассовая междоменная маршрутизация будет допускать существование в системе подсетей, не являющихся непрерывными, или все компоненты одного блока класса A или B будут содержаться в одной домене маршрутизации). Это позволит использовать описываемый план даже в том случае, когда свободные блоки адресов класса C закончатся раньше, нежели будет реализовано долгосрочное решение. Такой вариант более подробно рассматривается в главе 6.

Иерархическое распределение адресов в такой манере предполагает, что клиенты с адресами из провайдерского блока с точки зрения маршрутизации являются частью сети данного провайдера и маршрутизация к таким клиентам обеспечивается провайдером. Такой подход предполагает, что маршрутные данные о многодомных сайтах (т. е., организациях, подключенных к сетям нескольких провайдеров) должны быть известны вышележащим уровням иерархии.

Преимуществами иерархического распределения адресов перечислены ниже.

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

  2. С учетом постоянного роста Internet это обеспечивает масштабируемый способ распределения адресов с возможностью передачи полномочий по выделению адресов другим агентствам.

В силу сказанного выше и в интересах обеспечения согласованной процедуры получения адресов Internet рекомендуется большую часть (если не все) адресов распределять через сервис-провайдеров. Более подробное обсуждение этих вопросов вы найдете в документе [2].

3. Анализ преимуществ

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

Это означает, что новый план сам по себе не сможет оказать влияния на рост размеров таблиц маршрутизации. Однако после развертывания новых протоколов междоменной маршрутизации начнется незамедлительное снижение числа записей для новых адресатов, которые должны будут передаваться протоколами маршрутизации. Детальный анализ этого процесса и перманентного снижения скорости роста размеров таблиц маршрутизации дается в следующей главе.

Следует также отметить что существующий “плоский” метод централизованного распределения адресов связан со значительными бюрократическими издержками в агентстве по распределению. Для повышения эффективности процесса распределения адресов (безотносительно к их нехватке или переполнению таблиц маршрутизации) механизм распределения следует изменить. Использование предложенного в этом документе механизма будет иметь также позитивный побочный эффект – за счет распределения функций выделения адресов существенно снизится загрузка центрального агентства.

3.1 Существующая картина распределения

Неформальный анализ «network-contacts.txt» (файл доступен через DDN NIC) показывает, что на 2 февраля 1992 г было распределено 46 сетей класса A из 126 возможных (свободен 81 блок) и 5467 из 16382 возможных блоков класса B (свободно 10915). В предположении, что тенденции распределения адресов будут сохраняться, число выделяемых блоков класса B будет удваиваться приблизительно за год. При таком росте скорости все сети класса B будут распределены в течение примерно 15 месяцев. На 13 января 1993 г. были распределены 52 сети класса A и 7133 сети класса B. Мы предполагаем, что изменение скорости распределения блоков класса B обусловлено началом реализации рассматриваемого здесь плана.

3.2 История роста размеров таблиц

Таблица 1: Рост размера анонсируемых таблиц маршрутизации

Дата Число записей Дата Число записей Дата Число записей

декабрь, 1992

8561

июнь, 1991

2982

декабрь, 1989

897

ноябрь, 1992

7854

май, 1991

2763

ноябрь, 1989

837

октябрь, 1992

7354

апрель, 1991

2622

октябрь, 1989

809

сентябрь, 1992

6640

март, 1991

2501

сентябрь, 1989

745

август, 1992

6385

февраль, 1991

2417

август, 1989

650

июль, 1992

6031

январь, 1991

2338

июль, 1989

603

июнь, 1992

5739

декабрь, 1990

2190

июнь, 1989

564

май, 1992

5515

ноябрь, 1990

2125

май, 1989

516

апрель, 1992

5291

октябрь, 1990

2063

апрель, 1989

467

март, 1992

4976

сентябрь, 1990

1988

март, 1989

410

февраль, 1992

4740

август, 1990

1894

февраль, 1989

384

январь, 1992

4526

июль, 1990

1727

январь, 1989

346

декабрь, 1991

4305

июнь, 1990

1639

декабрь, 1988

334

ноябрь, 1991

3751

май, 1990

1580

ноябрь, 1988

313

октябрь, 1991

3556

апрель, 1990

1525

октябрь, 1988

291

сентябрь, 1991

3389

март, 1990

1038

сентябрь, 1988

244

август, 1991

3258

февраль, 1990

997

август, 1988

217

июль, 1991

3086

январь, 1990

927

июль, 1988

173

В таблице 1 приведены данные MERIT.

3.3 Детальный анализ

Существуют незначительные издержки технического и административного типа, связанные с реализацией нового плана распределения адресов. Административные издержки связаны с убеждением NIC, IANA и сервис-провайдеров с необходимостью реализации этого плана – эта задача не представляется сложной. Важно что при реализации этого плана существенно сокращаются издержки на централизованное (NIC и IANA) распределение адресов. Однако для получения преимуществ в результате агрегирования маршрутной информации требуется возможность представления маршрутов в форме номеров сетей и масок произвольного размера (в отличие от фиксированных размеров номеров сетей и масок для классов A/B/C). Поддержка адресов и масок нефиксированных размеров должна быть добавлена в используемые протоколы междоменной маршрутизации. Таким образом, издержки технического характера заключаются в реализации протоколов бесклассовой междоменной маршрутизации.

3.3.1 Преимущества нового плана адресации

Реализация плана обеспечивает два преимущества:

  • существующая проблема нехватки адресов класса B может быть решена выделением подходящего числа блоков класса C организациям средних размеров (200 — 4000 хостов);

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

3.3.2 Оценка скорости роста размеров таблиц

В январе 1992 г. размер таблиц а маршрутизаторах, не использующих принятого по умолчанию пути (например, в магистральных маршрутизаторах NSFNET) составлял приблизительно 4700 записей. Это значение отражает текущий размер маршрутной базы данных NSFNET. Просмотр статистики роста размеров таблиц показывает, что в среднем за период между 1988 и 1991 годом этот размер удваивался каждые 10 месяцев. Если предположить, что такая скорость сохранится (нет основания для иных предположений), можно ожидать, что за два года размер таблиц в маршрутизаторах, не использующих принятого по умолчанию маршрута, возрастет до 30000. В приведенном далее анализе предполагается, что экспоненциальное расширение Internet будет сохраняться.

Следует отметить, что в этих оценках не принимался во внимание тот факт, что в силу нехватки адресов класса B, многие организации могут получать взамен множество блоков класса C. Предполагая, что компании средних размеров, которым раньше выдавались блоки класса B будут получать от 4 до 16 сетей класса C, мы видим, что скорость роста размеров таблиц маршрутизации может увеличиться вдвое или даже в 4 раза. Это означает, что число записей в маршрутизаторах, не использующих принятого по умолчанию пути, может превысить 10 000 в течение шести месяцев и 20 000 менее, чем за год.

В декабре 1992 размер таблицы маршрутизации составлял 8500 записей, хотя по прогнозам в таблицах должно было содержаться уже 9400 маршрутов. В настоящий момент еще неясно, можно ли говорить о существенно изменении скорости роста размеров таблиц.

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

Поскольку в соответствии с этим планом многодомные сети должны по-прежнему явно анонсировать себя через систему (согласно правилу #1, описанному в параграфе 4.2), предполагается, что число маршрутов из таких сетей будет основным фактором роста таблиц маршрутизации после того, как будет реализован план агрегирования маршрутов (supernetting).

По текущим оценкам число многодомных организаций, подключенных к Internet, менее 100. Каждая из таких организаций использует один или несколько номеров сетей. Во многих случаях (после реализации этого плана – во всех) номера сетей организации идут последовательно, что позволяет агрегировать эти сети при анонсировании маршрутов. Это означает, что число маршрутов, анонсируемых в Internet для многодомных сетей может быть приблизительно равным числу многодомных организаций. В предположении, что количество многодомных организаций будет удваиваться каждый год (эта оценка может оказаться преувеличенной, поскольку каждое подключение стоит денег), число маршрутов для многодомных сетей вырастет за три года приблизительно до 800.

Предположим далее, что существует около 100 сервис-провайдеров и каждому из них также требуется анонсировать свой блок адресов. Однако в результате агрегирования такое анонсирование будет создавать только 100 дополнительных маршрутов. Будем предполагать, что по истечении двух первых лет новые сервис-провайдеры вкупе с новыми блоками существующих провайдеров будут добавлять 50 маршрутов в год. Таким образом, суммарное число маршрутов составит 4700 + 800 + 150 = 5650. Это дает годовой прирост около 6%, что во много раз меньше нынешнего роста в 130%. В этом анализе предполагается незамедлительная реализация предлагаемого плана с полным соответствием документу. Отметим, что при анализе принимался во внимание только один уровень агрегирования маршрутов в сети Internet – разумное выделение адресов позволит использовать многоуровневое агрегирование.

Очевидно, что прогнозы не могут оказаться точными на 100%, равно как не следует ожидать незамедлительной и полной реализации предложенного плана. Однако при выполнении этого плана 90% сервис-провайдеров приведет к тому, что в течении трех лет размер таблиц маршрутизации достигнет 4700 + 800 + 145 + 7500 = 13145, тогда как существующие темпы прироста приведут за такое же время к росту таблиц приблизительно до 75000 маршрутов.

4. Изменения протоколов и практики междоменной маршрутизации

Очевидно, что для эффективной поддержки supernet потребуется изменение протоколов маршрутизации и способов интерпретации маршрутной информации. Для “новых” протоколов междоменной маршрутизации изменения синтаксиса должны быть сравнительно невелики. Этот механизм не будет работать со старыми протоколами междоменной маршрутизации типа EGP2 – для обеспечения интероперабельности со старыми системами, использующими такие протоколы, следует обратиться к механизмам обеспечения принятого по умолчанию маршрута или требовать, чтобы новые маршрутизаторы при обмене информацией со старыми разбивали агрегированные маршруты по номерам отдельных сетей. Поскольку первый вариант является тривиальным, а второй слишком громоздким (значительный расход памяти на разделение агрегированных маршрутов), рекомендуется использовать первый вариант – тогда старые системы смогут по-прежнему использовать механизм принятого по умолчанию маршрута.

Отметим, что настоящий план предполагает использование в организациях, которым требуется импортировать supernet-информацию в свою систему маршрутизации, должны использовать протоколы IGP, поддерживающие бесклассовые маршруты (например, OSPF [1]). Системы, использующие старые протоколы IGP, могут по-прежнему анонсировать и получать supernet-информацию, но они не способны распространять такую информацию через свои домены маршрутизации.

4.1 Изменения семантики

Для реализации рассматриваемого здесь плана нужно внести два фундаментальных изменения в протоколы междоменной маршрутизации. Первое изменение заключается в отказе от использования “классов сетей” — данный план предполагает что адресаты маршрута представляются парами “номер сети – маска” и выбор маршрута осуществляется по максимальной длине соответствия (т. е., для конкретного адресата может существовать множество подходящих пар “номер сети – маска”, из которых выбирается с большим размером маски). Современные протоколы маршрутизации в основном не поддерживают концепцию агрегирования маршрутов и второе изменение состоит в реализации новой семантики с поддержкой агрегирования в протоколах междоменной маршрутизации. При агрегировании маршрутов для многодомных сайтов или сайтов, которые сменили своего провайдера могут возникать дополнительные сложности. К счастью для таких случаев можно определить несколько достаточно простых правил.

4.2. Правила анонсирования маршрутов

  1. Маршрутизация ко всем адресатам должна осуществляться только с использованием пути с максимальной длиной соответствия. Это подразумевает, что адресаты, являющиеся многодомными, всегда явно анонсируются в домен маршрутизации. Такие маршруты нельзя объединять с другими – интуитивно понятно, что для многодомной сети все ее пути в домен маршрутизации, расположенный выше в сетевой иерархии, должны быть известны в расположенной иерархически выше сети.

  2. Домен маршрутизации, объединяющий множество маршрутов в один, должен отбрасывать пакеты, которое соответствуют агрегированному маршруту, но не соответствуют ни одному из явных маршрутов, использованных при создании агрегированного маршрута. Это важно для предотвращения петель в маршрутизации при наличии менее специфичной информации (например, принятого по умолчанию маршрута). Разработчикам следует иметь в виду, что одним из простых способов реализации этого правила будет поддержка на граничных маршрутизаторах “нисходящего” маршрута в каждую из используемых при агрегировании сетей. При использовании правила выбора маршрута по максимальной длине совпадения, весь трафик, адресованный получателям, к которым не известно явного пути, будет отбрасываться.

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

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

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

accept 128.32.0.0
accept 128.120.0.0
accept 134.139.0.0
deny   36.2.0.0
accept 36.0.0.0

будет работать как фильтры

accept 128.32.0.0  255.255.0.0
accept 128.120.0.0 255.255.0.0
accept 134.139.0.0 255.255.0.0
deny   36.2.0.0    255.255.0.0
accept 36.0.0.0    255.0.0.0

Это просто делает явными маски сетей, которые неявно предполагались для сетей классов A/B/C.

4.3. Как работают правила

Правило 1 гарантирует совместимость алгоритма маршрутизации в разных реализациях и совместимость с другими протоколами маршрутизации (такими, как OSPF). Многодомные сети всегда анонсируются явно каждым сервис-провайдером, через которого они маршрутизируются даже если такие сети являются частью агрегированного маршрута сервис-провайдера. Может казаться, что “основной” провайдер может неявно анонсировать многодомную сеть (как часть агрегированного маршрута), однако правило выбора маршрута по наибольшей длине соответствия приведет к тому, что работать это не будет.

Правило 2 гарантирует, что в результате агрегирования маршрутов не образуется маршрутных петель. Рассмотрим сеть среднего уровня, которой выделено 2048 блоков адресов класса C, начиная с номера 192.24.0.0 (см. также пример в главе 5). Средний уровень передает в “магистраль” свои анонсы 192.24.0.0/255.248.0.0. Предположим, что для “магистральной” сети выделен блок адресов 192.0.0.0/255.0.0.0. Эта сеть тогда будет анонсировать на средний уровень агрегированный маршрут для этого блока. В таком случае, если сеть среднего уровня утратит внутреннюю связность с сетью 192.24.1.0/255.255.255.0 (часть агрегированного маршрута), трафик из “магистрали”, адресованный хосту 192.24.1.1, будет соответствовать анонсируемому средним уровнем маршруту. Когда такой трафик попадет на средний уровень, эта сеть не должна анонсу 192.0.0.0/255.0.0.0, полученному из “магистральной” сети, поскольку это будет приводить к возникновению петли в маршрутизации. Правило 2 говорит, что для среднего уровня недопустимо использовать менее специфичный маршрут, который соответствует одному из агрегируемых этой сетью маршрутов. Отметим, что обработка “маршрута по умолчанию” (0.0.0.0/0.0.0.0) является специальным случаем этого правила – сеть не должна использовать принятый по умолчанию путь для адресатов, которые являются частью анонсируемого этой сетью агрегированного маршрута.

4.4. Ответственность за настройку агрегирования

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

Когда маршрутизатор на границе между доменами агрегирует маршруты, ему нужно знать диапазон адресов IP, для которых объединяются маршруты. Основным принципом объединения является агрегирование как можно большего числа маршрутов без включения в объединенный маршрут тех блоков, которые не могут трактоваться как часть блока адресов ввиду наличия многодомных сайтов, принятой политики и пр.

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

Настройка конфигурации требует участия администратора, но эта работа не превышает нагрузку на администраторов сегодняшних маршрутизаторов. Администратору достаточно просто добавить одну или две строки, определяющих блок адресов IP для агрегирования маршрутов. Если маршрутизатор агрегирует маршруты, его администратор знает диапазон адресов, выделенных для домена. Если принимающий домен уполномочен агрегировать маршруты и выполняет эту операцию, администратор этого домена также знает диапазон адресов для агрегирования, поскольку этот диапазон указывается при передаче полномочий на агрегирование маршрутной информации. Поскольку администратору известно какие маршруты следует агрегировать, настройка конфигурации для выполнения таких действий не создает большой нагрузки для администратора.

Примечание для разработчиков: агрегирование маршрутов для адресов класса D (групповая адресация) в настоящее время не изучено. Не следует агрегировать такие маршруты, даже если это возможно.

4.5 Рассмотрение протоколов внутридоменной маршрутизации

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

  1. использовать протокол внутренней маршрутизации, поддерживающий агрегирование маршрутов;

  2. найти иной способ распространения внешней информации, который не будет использовать ее лавинной рассылки с использованием протокола внутренней маршрутизации (например, использовать в качестве внутреннего протокол BGP);

  3. прекратить импорт внешней информации и использовать лавинную рассылку принятого по умолчанию маршрута через внутренний протокол для определения путей к внешним адресатам.

В случае (a) требуется изменение протокола маршрутизации для поддержки агрегированных маршрутов, что может оказаться достаточно сложной задачей. Протоколы типа OSPF и IS-IS, которые представляют маршрутную информацию в форме адрес-маска (OSPF) или префикс-размер префикса (IS-IS) поддержку агрегированной информации организовать достаточно просто, однако для протоколов, работа которых основана на использовании классов сетей, или протоколов, которые могут работать только с подсетями фиксированных размеров, потребуются более фундаментальные изменения. Но даже в концептуально простых случаях OSPF и IS-IS, требуется вносить изменения в реализации протокола для поддержки supernet в базе данных или таблице пересылки.

5. Примеры нового распределения и маршрутизации

5.1 Выделение адресов

Рассмотрим блок из 2048 адресов класса C, начинающийся с сети 192.24.0.0 (0xC0180000 и заканчивающийся сетью 192.31.255.0 (0xC01FFF00), который выделен одному провайдеру (RA). Агрегированный маршрут к этому блоку адресов будет описываться как 192.24.0.0 с маской 255.248.0.0 (0xFFF80000). Предположим, что к сервис-провайдеру подключено шесть клиентов в показанном ниже порядке (порядок важен для демонстрации возникновения временных “дыр” в адресном пространстве провайдера):

C1 требуется менее 2048 адресов (8 сетей класса C)

C2 требуется менее 4096 адресов (16 сетей класса C)

C3 требуется менее 1024 адресов (4 сети класса C)

C4 требуется менее 1024 адресов (4 сети класса C)

C5 требуется менее 512 адресов (2 сети класса C)

C6 требуется менее 512 адресов (2 сети класса C)

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

C1: блок 192.24.0 – 192.24.7, описываемый агрегированным маршрутом 192.24.0.0 с маской 255.255.248.0

C2: блок 192.24.16 – 192.24.31, описываемый маршрутом 192.24.16.0 с маской 255.255.240.0

C3: блок 192.24.8 – 192.24.11, описываемый маршрутом 192.24.8.0 с маской 255.255.252.0

C4: блок 192.24.12 – 192.24.15, описываемый маршрутом 192.24.12.0 с маской 255.255.252.0

C5: блок 192.24.32 – 192.24.33, описываемый маршрутом 192.24.32.0 с маской 255.255.254.0

C6: блок 192.24.34 – 192.24.35, описываемый маршрутом 192.24.34.0 с маской 255.255.254.0

Отметим, что при использовании провайдером протокола IGP, который может поддерживать бесклассовые сети, этот провайдер может (но не обязан) объединять блоки (supernet) в точке подключения клиента и, следовательно, поддерживать всего 6 маршрутов для 36 выделенных клиентам блоков класса C. Если объединение маршрутов не поддерживается, все 36 блоков будут передаваться протоколом IGP.

Чтобы сделать наш пример более реалистичным, предположим, что C4 и C5 являются многодомными и подключены также к другому провайдеру (RB). Дополнительно предположим существование клиента C7, который изначально был подключен к провайдеру RB, а потом перешел к RA. Этот клиент использует адреса из блока провайдера RB (следующие 2048 сетей класса C):

C7: блок 192.32.0 – 192.32.15, описываемый маршрутом 192.32.0 с маской 255.255.240.0

Для многодомных клиентов предположим, что C4 анонсирует RA как основного провайдера, а RB – как вспомогательного; для C5 основным является RB, а вторичным RA. Для того, чтобы собрать все воедино, предположим, что провайдеры RA и RB соединены между собой через “магистрального” провайдера BB.

На приведенном ниже рисунке представлена схема соединений:

                       C1
192.24.0.0 -- 192.24.7.0 \         _ 192.32.0.0 - 192.32.15.0
192.24.0.0/255.255.248.0  \       / 192.32.0.0/255.255.240.0
                           \     /            C7
                       C2  +----+                                 +----+
192.24.16.0 - 192.24.31.0 \|    |                                 |    |
192.24.16.0/255.255.240.0  |    |  _ 192.24.12.0 - 192.24.15.0 _  |    |
                           |    | /  192.24.12.0/255.255.252.0  \ |    |
                       C3 -|    |/            C4                 \|    |
192.24.8.0 - 192.24.11.0   | RA |                                 | RB |
192.24.8.0/255.255.252.0   |    |___ 192.24.32.0 - 192.24.33.0 ___|    |
                          /|    |    192.24.32.0/255.255.254.0    |    |
                        C6 |    |             C5                  |    |
192.24.34.0 - 192.24.35.0  |    |                                 |    |
192.24.34.0/255.255.254.0  |    |                                 |    |
                           +----+                                 +----+
                              \\                                     \\
192.24.12.0/255.255.252.0 (C4) ||     192.24.12.0/255.255.252.0 (C4) ||
192.32.0.0/255.255.240.0 (C7)  ||     192.24.32.0/255.255.254.0 (C5) ||
192.24.0.0/255.248.0.0 (RA)    ||     192.32.0.0/255.248.0.0 (RB)    ||
                               ||                                    ||
                               VV                                    VV
                               +---------- BACKBONE PEER BB ----------+

5.2 Анонсирование маршрутов

В соответствии с правилом 1 провайдер RA должен анонсировать свой блок адресов и C7. Поскольку сеть C4 является многодомной и имеет основное подключение через RA, эта сеть также должна анонсироваться. Многодомная сеть C5 имеет основное подключение через RB. Эту сеть не нужно анонсировать, поскольку при выборе маршрута по максимальной длине соответствия магистраль BB будет автоматически выбирать маршрут через RB, а анонсируемый RA агрегированный маршрута будут использоваться как вторичный.

Анонсы из RA в BB будут иметь вид:

192.24.12.0/255.255.252.0 primary (advertises C4)
192.32.0.0/255.255.240.0  primary (advertises C7)
192.24.0.0/255.248.0.0    primary (advertises remainder of RA)

Для провайдера RB анонс должен включать C4 и C5, а также блок адресов провайдера RB. Более того, RB может анонсировать C7 как недоступную сеть.

Анонсы из RB в BB будут иметь вид:

192.24.12.0/255.255.252.0 secondary (advertises C4)
192.24.32.0/255.255.254.0 primary (advertises C5)
192.32.0.0/255.248.0.0    primary (advertises remainder of RB)

Для иллюстрации проблемы с “дырой”, упомянутой в параграфе 4.2, рассмотрим ситуацию, когда RA теряет соединение с C7 (клиент, использующий адреса из блока провайдера RB). В протоколе, поддерживающем информацию о состоянии соединений ((stateful protocol) RA будет анонсировать в BB недоступность блока 192.32.0.0/255.255.240.0. После того, как BB исключит этот маршрут их своей таблицы маршрутизации, любой трафик, передаваемый через BB в адрес недоступной сети, будет пересылаться провайдеру RB (где он будет отбрасываться согласно правилу 2), поскольку для RB получается максимальная длина соответствия 192.32.0.0/255.248.0.0. Хотя дополнительных проблем не возникает (сеть C7 все равно недоступна), в таких случаях может передаваться избыточный трафик через BB, а также могут быть введены в заблуждение администраторы, пытающиеся проверить путь в недоступную сеть с помощью traceroute. Здесь помог бы механизм кэширования информации о недоступности сети, но рассмотрение таких механизмов не входит в задачи данного документа и не очевидна возможность реализации подобного механизма в ближайшем будущем.

6. Расширение CIDR для адресов класса A

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

Имеется два существенных различия в использовании адресов класса A и класса C. Первое различие заключается в том, что при делении на подсети блоков класса A несколько усложняется конфигурация DNS. Второе отличие состоит в том, что маршрутизаторы сетей класса A должны будут поддерживать бесклассовые протоколы IGP.

Поддержка DNS с разделенными на подсети блоками класса A является достаточно тяжелой задачей. Как часть механизма обратного преобразования адресов DNS поддерживает реверсный домен IN-ADDR.ARPA. Этот псевдо-домен содержит записи с обратным порядком байтовых полей IP-адресов и суффиксом IN-ADDR.ARPA и используется для определения имен хостов по их IP-адресам. Например, для хоста с адресом 131.108.1.111 в DNS имеется запись 111.1.108.131.IN-ADDR.ARPA. Поскольку псевдо-домены могут делегироваться только по границам байтов, это создает проблемы в тех случаях, когда конечный домен получает адресов, не выровненный по границе байта. Решение проблемы для таких случаев состоит в перечислении всех возможных комбинаций. Такой подход требует выполнения большой работы, но решает проблему. Более подробно это решение рассматривается ниже.

Маршрутизация в сети класса A с использованием CIDR также порождает интересную проблему. Обычно домен будет получать часть адресного пространства класса A. Такой домен может использовать протокол IGP, который поддерживает подсети переменного размера, или применять общую маску для всех хостов домена. В последнем случае возникают сложности, связанные с тем, что другие домены получившие адреса из того же блока A могут использовать отличающиеся маски. Если домен сам по себе является транзитным, ему может потребоваться выделение части полученных адресов для своих клиентов, которые также могут использовать отличающиеся маски. В этом случае клиентам потребуется информация об остальной части адресного блока класса A.

Если протокол IGP у клиента не поддерживает маски переменной длины, вопрос может быть решен путем анонсирования оставшейся части адресного блока класса A в виде подсетей подходящего размера. Однако в тех случаях, когда клиенты используют небольшие блоки, это приводит к необходимости организации большого числа подсетей (например, маска 255.255.255.0 будет требовать использования 65535 подсетей, включая сеть самого клиента). В силу этого может оказаться более разумным использовать в клиентском домене протокол IGP, поддерживающий подсети переменного размера.

Аналогичная ситуация наблюдается и для транзитных доменов. Очевидно, что такой домен не получит все пространство блока класса A и адреса из этого же блока будут выделены другим транзитным доменам. В этом случае транзитный домен также будет добавлять маршрутную информацию об остальной части адресного пространства блока класса A в протокол IGP. Ситуация аналогична описанной выше и связана с такими же сложностями. По этой причине рекомендуется использовать блоки класса A для CIDR только в тех случаях, когда во всем блоке используются протоколы IGP, поддерживающие подсети переменных размеров. Отметим, что от протоколов IGP не требуется поддержка supernet, как было сказано выше.

Отметим, что описанные здесь методы могут также применяться к адресам класса B. Однако ограниченное число свободных блоков класса B и их использование для многодомных сетей позволяю предположить, что оставшиеся блоки лучше зарезервировать для крупных организаций, которым нужен именно этот тип адресов [2].

7. Вопросы, связанные с серверами DNS

Одним из аспектов работы Internet, на который оказывает значительное влияние объединение (supernet) блоков класса C и разделение на подсети блоков класса AЮ является механизм определения имени хоста по его адресу – зона IN-ADDR.ARPA в системе доменных имен. Поскольку эта зона делегируется только по границе октетов, любой план распределения адресов, который использует маски переменной длины, будет порождать те или иные проблемы с поддержкой отдельных частей зоны IN-ADDR.ARPA.

7.1 Процедурные изменения для supernet класса C

В настоящее время части зоны IN-ADDR.ARPA делегируются только сетям, границы которых совпадают с границами полных октетов адреса. Для эффективного использования произвольных блоков адресов класса C рекомендуется отказаться от этого правила и позволить делегирование произвольных, ориентированных на октеты, частей зоны IN-ADDR.ARPA.

Как пример изменения правил рассмотрим гипотетическую крупную сеть провайдера BigNet, которая включает 1024 сети класса C с номерами от 199.0.0 до 199.3.255. В рамках действующих правил корневые серверы домена должны поддерживать 1024 записи вида:

0.0.199.IN-ADDR.ARPA.   IN NS NS1.BIG.NET.
1.0.199.IN-ADDR.ARPA.   IN NS NS1.BIG.NET.
....
255.3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.

Изменив политику в соответствии с приведенными выше соображениями, можно снизить число записей в корневых серверах до 4:

0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
1.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
2.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.

Провайдер может передать полномочия по поддержке частей зоны в отдельные сети класса C, которые были выделены клиентам, взамен поддержки таких зон у провайдера. Отметим, что устройство системы DNS позволяет корневым серверам поддерживать информацию о передаче полномочий для отдельных сетей, для которых провайдер не хочет или не может поддерживать сделать этого у себя. Такое решение существенно снижает нагрузку на серверы имен для “верхних” уровней зоны IN-ADDR.ARPA. Приведенный выше пример показывает только записи для одного сервера имен. В обычной ситуации для каждого домена существует несколько серверов имен и приведенные размеры могут удваиваться и утраиваться.

7.2 Процедурные изменения для подсетей в блоках класса A

При разбиении блоков класса A на подсети, выделяемые транзитным сервис-провайдерам, требуется отменить соответствующие ограничения и на делегирование частей домена IN-ADDR.ARPA для таких подсетей. В качестве примера рассмотрим провайдера, получившего 19-битовую часть адресного блока, которой соответствует номер 10.8.0.0 с маской 255.248.0.0. Это представляет все адреса, которые начинаются префиксами 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.15 и требует следующих записей IN-ADDR.ARPA:

8.10.IN-ADDR.ARPA.  IN NS NS1.MOBY.NET.
9.10.IN-ADDR.ARPA.  IN NS NS1.MOBY.NET.
....
15.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.

Для того, чтобы показать как работает дальнейшее делегирование IN-ADDR.ARPA, рассмотрим компанию FOO, подключенную к этому провайдеру и получившему 14-битовую часть адресного блока, которая соответствует номеру 10.10.64.0 с маской 255.255.192.0. Это представляет все адреса в диапазоне от 10.10.64.0 до 10.10.127.255 и будет требовать, чтобы провайдер обеспечил делегирование для фрагментов зоны IN-ADDR.ARPA

64.10.10.IN-ADDR.ARPA.  IN NS NS1.FOO.COM.
65.10.10.IN-ADDR.ARPA.  IN NS NS1.FOO.COM.
....
127.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.

с серверами для FOO.COM, содержащими отдельные записи PTR для всех адресов в каждой из этих подсетей.

8. Переход к долговременному решению

Это решение не меняет архитектуры маршрутизации и адресации Internet. Следовательно, переход к долговременному решению не подвержен влиянию реализации данного плана.

9. Заключение

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

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

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

Если сервис-провайдеры начнут брать плату за анонсирование маршрутов, это станет хорошим стимулом для совместного использования адресного пространства и связанного с этим числа маршрутов, анонсируемых сервис-провайдерам.

10. Рекомендации

NIC следует начать распределение крупных блоков сетей класса C сервис-провайдерам. Каждый блок должен быть выравнен по битовой границе и иметь достаточно большой размер, чтобы его хватило сервис-провайдеру по крайней мере на два года. Далее NIC следует выделить очень большие блоки для континентальных и национальных операторов, чтобы обеспечить дополнительное агрегирование на уровне основных магистральных сетей. В дополнение к сказанному NIC следует изменить процедуры для домена IN-ADDR.ARPA, чтобы позволить делегирование произвольных частей зоны, выровненных по границе октета.

Сервис провайдеры будут далее распределять блоки адресов класса C (кратные по размеру степеням числа 2) из полученного адресного пространства для своих клиентов.

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

Для эффективного использования нового плана распределения адресов и снижения объемов передаваемой маршрутной информации следует организовать соответствующие рабочие группы IETF по созданию обновленных вариантов протоколов междоменной маршрутизации. Реализацию и развертывание этих протоколов следует провести незамедлительно.

11 Литература

[1] Moy, J, «The OSPF Specification Version 2», RFC 12473, Proteon, Inc., January 1991.

[2] Rekhter, Y., and T. Li, «An Architecture for IP Address Allocation with CIDR», RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems, September 1993.

12. Вопросы безопасности

Вопросы безопасности не рассматриваются в данном документе.

13. Адреса авторов

Vince Fuller

BARRNet

Pine Hall 115

Stanford, CA, 94305-4122

EMail: vaf@Stanford.EDU

Tony Li

cisco Systems, Inc.

1525 O’Brien Drive

Menlo Park, CA 94025

EMail: tli@cisco.com

Jessica (Jie Yun) Yu

Merit Network, Inc.

1071 Beal Ave.

Ann Arbor, MI 48109

EMail: jyy@merit.edu

Kannan Varadhan

Internet Engineer, OARnet

1224, Kinnear Road,

Columbus, OH 43212

EMail: kannan@oar.net


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Classless Inter-Domain Routing

2Блок адресов организации перестает быть доступным через данного провайдера. Прим. перев.

3RFC 2328, содержит современную спецификацию протокола OSPF v2. Прим. перев.




RFC 1518 An Architecture for IP Address Allocation with CIDR

Network Working Group                                     Y. Rekhter
Request for Comments: 1518    T.J. Watson Research Center, IBM Corp.
Category: Standards Track                                      T. Li
                                                       cisco Systems
                                                             Editors
                                                      September 1993

Архитектура распределения адресов IP для CIDR

An Architecture for IP Address Allocation with CIDR

PDF

Статус документа

В данном RFC содержится спецификация стандарта, предложенного сообществу Internet; документ служит приглашением к дискуссии в целях совершенствования и развития протокола. Информацию о текущем состоянии стандартизации для этого протокола вы можете найти в документе «Internet Official Protocol Standards». Документ может распространяться без ограничений.

1. Введение

В этом документе рассматривается архитектура и план распределения адресов IP в Internet. Архитектура и план должны сыграть важную роль в переводе Internet на использование бесклассового распределения адресов и стратегии агрегирования, описанных в [1].

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

2. Обсуждаемые вопросы

Internet в глобальном масштабе можно представить как множество хостов, связанных между собой прямыми соединениями или системами коммутации. Управление хостами и соединениями, которые составляют глобальные ресурсы Internet, не является однородным и распределено между множеством уполномоченных организаций. Ресурсы, находящиеся под единым административным управлением, образуют домен. Далее в этом документе термины «домен» (domain) и «домен маршрутизации» (routing domain) будут использоваться как синонимы. Домены, которые предоставляют свои ресурсы другим доменам, называются поставщиками сетевых услуг или сервис-провайдерами (network service provider или provider). Домены, пользующиеся ресурсами других доменов, называют пользовательскими (network service subscriber или subscriber). Домен может относиться к провайдерским и пользовательским одновременно.

Следует разделять два аспекта обсуждения задачи распределения адресов IP в Internet. Первый связан с набором административных требований для получения и распределения адресов IP, а второй – с техническими аспектами такого распределения – внутридоменной и междоменной маршрутизацией, прежде всего. В этом документе обсуждаются технические вопросы.

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

Архитектура и рекомендации, приведенные в этом документе, предназначены для незамедлительной реализации. Документ не предлагает долговременного решения типа создания комплексной системы маршрутизации на основе правил.

Решения, требующие внесения существенных изменений или ограничений для существующей топологии, не рассматриваются.

Архитектура и рекомендации, приведенные в этом документе, связаны в первую очередь с крупномасштабным распределением адресов IP в Internet. В документе рассматриваются:

  • преимущества представления части топологической информации в адресах IP для существенного снижения нагрузки на протоколы маршрутизации;
  • предполагаемая потребность введения дополнительных уровней иерархии в систему адресации Internet для обеспечения возможности роста сети;
  • рекомендации по отображению элементов топологии Internet (провайдеров и пользователей) на адресное пространство IP и компоненты маршрутизации;
  • рекомендации по передаче функций распределения адресов IP сервис-провайдерам (например, магистральным, региональным) и пользователям (например, сайтам);
  • распределение адресов IP агентством Internet Registry;
  • выбор старшей части адреса IP в доменах маршрутизации, соединенных с несколькими провайдерами (например, магистральная или региональная сеть).

Отметим, что существуют технические и административные аспекты распределения адресов IP, которые не рассматриваются в этом документе. К таким аспектам относятся:

  • идентификация конкретных административных доменов в Internet;
  • правила и механизмы предоставления другим сторонам доступа к регистрационным данным (сведения о принадлежности адреса или блока адресов IP);
  • организация внутренней топологии и распределения адресов в доменах маршрутизации (в частности, сайтах); связи между топологией и распределением адресов рассматриваются в документе, но не обсуждаются вопросы выбора конкретной топологии или внутреннего плана адресации;
  • процедуры присваивания хостам адресов IP.

3. Основы

Приведенная ниже информация поможет разобраться с вопросами распределения адресов IP. Приводится краткое описание процесса маршрутизации IP.

Задача маршрутизации IP может быть разделена на 3 части:

  • обмен маршрутной информацией между конечными системами и маршрутизаторами (ARP);
  • обмен маршрутными данными между маршрутизаторами одного домена (внутренняя маршрутизация);
  • обмен маршрутными данными между доменами (внешняя маршрутизация).

4. IP-адреса и маршрутизация

В данном документе под префиксом IP будет пониматься некое означенное количество старших битов адреса IP, расположенных непрерывно. В документе для указания префиксов IP будут использоваться пары <IP-адрес, IP-маска> — побитовая логическая операция AND, примененная к компонентам пары, дает в результате непрерывную последовательность старших битов, которые и образуют префикс IP. Например, пара <193.1.0.0 255.255.0.0> указывает 16-битовый префикс.

При выборе административной политики распределения адресов IP важно понимать техническую сторону вопроса. Кроме обеспечения иерархической системы маршрутизации задача состоит в достижении некого уровня абстрагирования маршрутных данных для снижения расхода памяти и ресурсов процессора, а также полосы каналов для поддержки маршрутизации.

Хотя абстрагирование маршрутных данных может применяться к различным типам маршрутной информации, в этом документе используется только один тип такой информации – данные о доступности адресата. Эти данные включают множество доступных адресатов. Абстрагирование данных о доступности диктует необходимость распределения адресов IP в соответствии с топологической структурой маршрутизации. Однако административное распределение адресов связано с организациями или государствами. Границы (сетевые) организаций и государств могут не совпадать с топологическими границами, что может приводить к конфликтам требований. Поэтому нужно найти разумный компромисс между административными и топологическими требованиями к распределению адресов.

Абстрагирование маршрутных данных происходит на границе между иерархически расположенными топологическими структурами маршрутизации. Элементы нижнего уровня иерархии передают вышележащему (родительскому) уровню сводную информацию о маршрутах.

На границе доменов маршрутизации происходит статический или динамический обмен данными об адресах IP с другими доменами. Если IP-адреса в домене маршрутизации не могут быть представлены в виде непрерывной последовательности (абстракция невозможна), передаваемая через границу информация будет содержать список всех адресов IP в домене.

Если же все адреса IP в домене маршрутизации могут быть описаны одним префиксом, передаваемая через границу домена информация может быть сведена к единственному префиксу IP. Это существенно снижает объем данных и расширяет возможности масштабирования по сравнению со случаем использования дискретного набора адресов, описанным в предыдущем абзаце.

Если домены маршрутизации соединены по более или менее произвольной (т. е., не иерархической) схеме, очевидно, что дополнительного абстрагирования маршрутных данных не будет. Поскольку домены в такой ситуации не имеют определенных иерархических зависимостей, администраторы не могут выделять адреса IP с общим префиксом для обеспечения абстрагирования маршрутных данных. В результате получается плоская схема междоменной маршрутизации, в которой каждый домен должен в явном виде знать маршруты ко всем остальным доменам. Такое решение может хорошо работать для мелких и средних сетей, однако оно неприменимо для крупных сетей. Например, предполагается рост сети Internet, в результате которого число доменов маршрутизации только в Северной Америке будет достигать десятков или сотен тысяч. Такое расширение потребует значительно более высокого уровня абстракции данных о доступности, нежели можно получить на уровне домена маршрутизации.

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

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

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

Легко заметить, что число узлов по мере перемещения вниз по иерархии растет экспоненциально. Таким образом значительное повышение уровня абстрагирования (для эффективной работы более высоких уровней иерархии) произойдет в том случае, когда информация о доступности будет агрегироваться вблизи «листьев» иерархического дерева. При агрегировании на каждом из расположенных выше уровней значимость такого абстрагирования будет существенно снижаться. Следовательно, на каком-то уровне абстрагирование данных перестанет давать существенные преимущества. Определение этого уровня требует учета числа доменов маршрутизации, которое ожидается на каждом уровне иерархии (для данного периода времени) в сравнении с числом доменов маршрутизации и префиксов, которые успешно и эффективно обслуживаются с помощью протоколов динамической междоменной маршрутизации.

4.1 Эффективность и децентрализация

Если в Internet планируется поддержка децентрализованного распределения адресов [4], возникает необходимость в обеспечении баланса требований к распределению адресов IP для эффективной маршрутизации и децентрализованного администрирования. Предложения, описанные в документе [3], могут служить примером баланса.

Префикс IP <198.0.0.0 254.0.0.0> предоставлен для децентрализованного администрирования. Этот префикс идентифицирует часть адресного пространства IP, выделенного для Северной Америки. Адреса из этого блока распределяются с учетом топологических границ для повышения уровня абстракции данных. Клиенты из Северной Америки используют блоки адресов IP, которые являются частями адресного пространства, выделенного их провайдерам. Внутри домена маршрутизации адреса подсетей и хостов выделяются из уникального префикса IP, связанного с доменом.

5. Администрирование адресов IP и маршрутизация в Internet

Основными компонентами системы маршрутизации Internet являются сервис-провайдеры (например, магистральные и региональные сети) и потребители сервиса (например, сайты и кампусные сети). Эти компоненты в большинстве случаев образуют иерархическую структуру. Естественным отображением этих компонент на компоненты маршрутизации IP является то, что провайдеры и потребители действуют как домены маршрутизации. В дополнение к этому потребитель (например, сайт) может выбрать для себя режим функционирования как части домена, формируемого сервис-провайдером. Мы предполагаем, что некоторые (если не большинство) сайты предпочтут быть частью домена маршрутизации своего провайдера. Такие сайты могут обмениваться маршрутной информацией со своим провайдером через протоколы внутренней или внешней маршрутизации (в данном случае разница между этими протоколами не имеет существенного значения). Сайт использует блок адресов из префикса своего провайдера, а последний анонсирует свой префикс в систему междоменной маршрутизации.

Возникает вопрос – где следует администрировать адреса с учетом описанного отображения, чтобы обеспечить децентрализацию и абстракцию данных? Существует несколько вариантов:

  • в какой-либо части домена маршрутизации;
  • в ветви домена маршрутизации;
  • в транзитном домене маршрутизации (TRD1);
  • на границах континент.

Точка в домене маршрутизации соответствует подсети. Если домен состоит из множества подсетей, последние соединяются через маршрутизаторы. Ветви домена маршрутизации соответствуют сайтам, для которых основным типом сервиса является обеспечение внутридоменной маршрутизации. Транзитные домены маршрутизации (TRD) создаются для передачи транзитного трафика, к числу TRD относятся магистральные сети и провайдеры2.

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

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

В качестве примера предположим, что некий сайт пытается определить, следует ему получать блок адресов (префикс) из пространства IP, выделенного для Северной Америки, или из пространства своего сервис-провайдера. Если учитывать только собственные интересы данного сайта, оба варианта являются равнозначными как для этого сайта, так и для сервис-провайдера. Сайт должен использовать тот или иной префикс, а конкретное значение этого префикса не оказывает существенного влияния на эффективность маршрутизации для данного сайта. Провайдер должен поддерживать информацию о каждом подключенном сайте для обеспечения маршрутизации, независимо от уровня общности префиксов сайтов.

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

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

К описанной проблеме применимы отношения «поставщик-потребитель» — более высокий уровень маршрутной иерархии (например, магистральная сеть) является поставщиком услуг маршрутизации, тогда как более низкий уровень (например, TRD) является потребителем этих услуг. Стоимость услуг определяется расходами на их поддержку. Избыточная работа по поддержке больших таблиц адресов для маршрутизации к подключенному элементу топологии вносит свой вклад в эту стоимость.

Internet, однако, не представляет собой объект рыночной экономики. Основой сотрудничества скорей является обеспечение эффективности. Рекомендации, приведенные ниже, дают простые и понятные способы распределения адресов IP, обеспечивающего преимущества сообществу Internet в целом.

5.1 Администрирование адресов IP в домене

Если отдельные подсети будут получать свои адреса IP из произвольных блоков, станет невозможной эффективная абстракция маршрутных данных сверх возможностей, обеспечиваемых протоколами внутридоменной маршрутизации. Предположим для примера, что в домене маршрутизации используется три независимых префикса из 3 разных блоков IP, связанных с тремя подключенными провайдерами. Это будет оказывать негативное воздействие на междоменную маршрутизацию (в частности, для тех доменов, которым нужно поддерживать маршруты в данный домен). В данном случае не существует общего префикса, который мог бы использоваться для представления IP-адресов сети, следовательно не существует возможности агрегировать маршруты на границе домена маршрутизации. При анонсировании адресов в другие домены эти адреса будут передаваться с использованием трех отдельных префиксов.

Описанная ситуация весьма напоминает текущую картину Internet3, когда каждый домен может включать множество не связанных между собой адресных блоков. Это является результатом распределения для подсетей не связанных блоков IP в рамках плоской модели4 в адресами классов A/B/C. Число префиксов, анонсируемых ветвями доменов маршрутизации, совпадает по порядку величины с числом подключенных сетей, а число префиксов, анонсируемых провайдером, совпадает по порядку величины с числом сетей, подключенных к ветвям домена маршрутизации. Магистральные же сети анонсируют префиксы от всех подключенных провайдеров. Такая ситуация как-то приемлема для текущего состояния Internet, но рост сети быстро приведет к трудноразрешимым проблемам. Для продолжения роста Internet необходимо использование иерархической модели с агрегированием маршрутов.

5.2 Администрирование для ветви домена маршрутизации

Как было отмечено выше максимальное абстрагирование данных происходит на нижних уровнях иерархии. Предоставление каждой ветвью домена маршрутизации (т. е., сайтом) префикса из блока (префикса) своего провайдера является максимальным уровнем абстрагирования. За пределами данной ветви весь набор адресов, достижимых в этой ветви, может быть представлен единственным префиксом. Более того, все адреса, достижимые через данного провайдера, также могут быть представлены одним префиксом.

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

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

5.3 Администрирование для транзитных доменов

Ниже рассматриваются два типа транзитных доменов маршрутизации – прямые и косвенные (indirect) провайдеры. Большинство абонентов прямого провайдера является доменами, которые выступают лишь в качестве потребителей услуг (не обеспечивают транзита для трафика). Большинство абонентов косвенных провайдеров относится к числу доменов, которые сами являются сервис-провайдерами. В данной терминологии магистральная сеть является косвенным провайдером, а TRD — прямым. Ниже приводится описание администрирования адресов для обоих случаев.

5.3.1 Прямые сервис-провайдеры

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

В качестве примера рассмотрим прямого сервис-провайдера, обслуживающего 100 клиентов. Если каждый клиент получает свои адреса из 4 независимых блоков, общее число маршрутных записей для этих клиентов составит 400 (100 по 4 префикса). Если каждый клиент получает адреса из одного блока, количество записей для клиентов уменьшается до 100. Если же все клиенты получают адреса из общего блока, число записей уменьшается до 1.

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

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

Заинтересованы ли ветви доменов маршрутизации в получении префиксов от прямых провайдеров? В модели «поставщик-потребитель» прямой провайдер предлагает подключение, как сервис, стоимость которого зависит от операционных расходов. Эти расходы включают и стоимость услуг, получаемых прямым провайдером от магистральных сетей (косвенных провайдеров). В общем случае магистральные сети хотят обслуживать как можно меньше сетевых префиксов. В среде Internet, которая не управляется целиком законами рынка, ветви маршрутных доменов должны понимать, что прямые и косвенные провайдеры затрачивают свои ресурсы на поддержку системы маршрутизации. Повышение эффективности междоменной маршрутизации будет служить гарантией согласия ветвей доменов маршрутизации на получение префиксов IP из блока адресов своих провайдеров.

Механизм этого процесса очень прост. Каждый прямой провайдер получает уникальный набор префиксов IP, из которого для подключенных к провайдеру сетей могут выделяться более длинные префиксы IP. Предположим для примера, что NIST является ветвью домена маршрутизации, подключенной через провайдера SURANet. Если SURANet выделен уникальный префикс IP <198.1.0.0 255.255.0.0>, NIST может использовать уникальный префикс <198.1.0.0 255.255.240.0>.

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

5.3.2 Косвенные провайдеры (магистральные сети)

Для прямых провайдеров не представляется разумным получение адресного пространства из блоков IP, выделенных непрямым провайдерам (например, магистральным сетям). Преимущества абстрагирования маршрутных данных сравнительно малы. Число прямых провайдеров сегодня измеряется десятками и рост этого числа не приведет к чрезмерной загрузке магистралей. Кроме того, можно ожидать, что со временем будет расти число непосредственных соединений между прямыми провайдерами, число непосредственных соединений ветвей доменов маршрутизации к магистральным сетям и число международных каналов, напрямую подключенных к провайдерам. С учетом этих обстоятельств различия между прямыми и косвенными провайдерами размываются.

Дополнительным фактором, препятствующим получению адресов IP из префиксов магистральных сетей, является желание подключенных к магистралям провайдеров сохранить свою независимость. Провайдеры могут пользоваться услугами одной или нескольких магистральных сетей и выбирать эти сети с учетом экономической эффективности. Получение адресов из блоков магистральных сетей несовместимо с такой моделью.

5.4 Многодомные маршрутные домены

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

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

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

Для примера предположим, что крупная северо-американская компания Mega Big International Incorporated (MBII) имеет единую внутреннюю сеть с префиксом, выделенным из северо-американского блока. Очевидно, что за пределами Северной Америки в таблицах маршрутизации может поддерживаться одна запись для всего северо-американского префикса. Однако внутри Северной Америки каждый провайдер должен поддерживать отдельную запись для MBII. Если MBII фактически является международной корпорацией, тогда поддержка отдельной записи для нее может потребоваться от провайдеров всего мира (включая магистрали, к которым MBII не подключена). Очевидно, что такое решение приемлемо при небольшом количестве таких многодомных доменов маршрутизации и будет приводить к недопустимой нагрузке на магистральные маршрутизаторы, если все организации начнут использовать такую схему получения адресов. Это решение не подходит для сетей, в которых число многодомных организаций измеряется сотнями тысяч.

Другим вариантом для многодомных организаций является получение раздельных блоков IP-адресов для каждого соединения с TRD и выделения единого префикса для некоторого подмножества домена (доменов) этой организации в соответствии с ближайшей точкой подключения. Например, если MBII имеет соединения с двумя провайдерами в США (одно на западном побережье, другое на восточном), а также с тремя национальными магистралями в Европе и одной на дальнем востоке, тогда MBII может использовать шесть различных префиксов. Каждая часть MBII будет получать единый префикс в зависимости от ближайшей точки подключения.

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

Если мы предположим, что входящий (источник за пределами MBII, адресат в MBII) трафик всегда приходит через ближайшую к адресату точку, тогда каждому TRD, который имеет соединение с MBII, требуется анонсировать другим TRD доступность только той части MBII, в которой используются адреса из его блока. Это предполагает, что в обмен между TRD не включается дополнительных маршрутных данных, что ведет к снижению нагрузки на таблицы междоменной маршрутизации, поддерживаемые TRD, по сравнению с первым вариантом. Следовательно, это решение гораздо лучше масштабируется для очень больших сетей с огромным количеством многодомных организаций.

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

При втором варианте также требуется изменять внутреннюю адресацию при изменении внешних соединений.

Отметим, что доставка пакетов для первого и второго варианта будет происходить по разным путям. В первом варианте пакеты, адресованные снаружи в сеть MBII, будут доставляться через точку, которая ближе к отправителю, что приведет к увеличению нагрузки на внутреннюю сеть MBII. Во втором варианте пакеты, направленные в MBII извне, будут доставляться через точку, которая ближе к получателю, что приведет к снижению нагрузки на сеть MBII и росту нагрузки на TRD.

Эти решения также оказывают разное влияние на политику. Предположим, например, что страна X имеет закон, по которому трафик между двумя находящимися в этой стране сайтами в любом случае не должен выходить за пределы данной страны. При использовании первого решения по адресу получателя невозможно определить его принадлежность к данной стране. Во втором варианте хостам страны X можно выделить различаемые адреса, следовательно, правила маршрутизации могут быть выполнены. Предположим, для примера, что компания LSC имеет политику, в соответствии с которой ее пакеты никогда не могут передаваться адресатам из MBII. Для обоих вариантов маршрутизаторы внутри LSC можно настроить на отбрасывание трафика, направленного по адресам из блока MBII. Однако в первом случае потребуется только одна запись, а второй вариант потребует создания множества фильтров и может оказаться неприменимым на практике.

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

Существует по крайней мере одна ситуация, в которой третий вариант применим на практике. Предположим, что группа организаций со связанными интересами, реализовала каждая свою опорную сеть. Для примера предположим, что U.S. National Widget Manufacturers and Researchers организовала опорную сеть в масштабах США, которая используется корпорациями, производящими приборы, и некоторыми университетами, занимающимися разработкой приборов. Мы можем ожидать, что различные организации этой группы будут использовать свои внутренние сети, как отдельные домены маршрутизации и большинство из них будет также подключено к другим TRD (поскольку большинство организаций, связанный с производством и разработкой приборов, вовлечены также в другие сферы деятельности). Мы можем, следовательно, ожидать, что многие или большинство из этих организаций являются двудомными с подключением к «приборной сети» и какой-либо иной сети. Предположим также, что общее число организаций в приборной группе достаточно мало для того, чтобы можно было поддерживать таблицу маршрутизации, содержащую по одной записи для каждой организации, но эта таблица распространяется через более крупные сети со многими миллионами (не связанных с приборами) доменов маршрутизации.

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

Четвертый вариант распределения префиксов для доменов маршрутизации используется в тех случаях, когда домены подключены к двум (или большему числу) конкретным доменам маршрутизации. Предположим, например, что имеется два провайдера SouthNorthNet и NorthSouthNet, которые имеют в целом очень большое количество заказчиков (т. е., имеется большое число доменов маршрутизации, подключенных к обоим провайдерам). Вместо получения двух префиксов эти провайдеры могут взять три. Маршрутным доменам, подключенным только к провайдеру NorthSouthNet, будут выделяться адреса из одного префикса, подключенным только к SouthNorthNet – из другого, а подключенным к обоим провайдерам – из третьего. Каждый из двух TRD будет тогда анонсировать в другой TRD два префикса – один для маршрутных доменов, подключенных только к этому провайдеру, а другой – для доменов, подключенных к обоим провайдерам.

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

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

В дополнение к сказанному отметим, что большинство решений также указывают для каждого TRD необходимость выработки политики и условий восприятия адресов, не относящихся к их префиксам, и трактовки таких нелокальных адресов. Например, достаточно консервативная политика может заключаться в том, что нелокальные префиксы IP будут приниматься от любых подключенных краевых (leaf) доменов маршрутизации, но не будут анонсироваться другим TRD. При менее консервативной политике TRD может принимать такие нелокальные адреса и соглашаться обмениваться ими с определенным набором других TRD (этот набор может быть группой TRD, имеющих нечто общее – географическое положение или соглашения, принятые специально по запросу краевых доменов маршрутизации). Различные правила имеют реальную стоимость для TRD, которая может быть отражена в этих правилах.

5.5 Частные каналы

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

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

В качестве примера предположим, что корпорация XYZ имеет тесные деловые контакты с MBII. В этом случае XYZ и MBII могут заключить с провайдером контракт на организацию соединения между двумя корпорациями и этот канал будет использоваться только для передачи пакетов, отправитель которых находится в одной из этих корпораций, а получатель — в другой. Предположим также, что канал «точка-точка» организован между одним маршрутизатором (X) в корпорации XYZ и одним маршрутизатором (M) в MBII. Следовательно, требуется настроить маршрутизатор X так, чтобы он знал, какие адреса доступны через данный канал (в данном случае – все адреса MBII). Точно так же требуется настроить маршрутизатор M, которому тоже нужно знать адреса, доступные через соединение (все адреса в корпорации XYZ).

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

Возвращаясь к нашему примеру, предположим, что корпорация XYZ имеет одно соединение с региональным оператором и, следовательно, использует пространство адресов IP из выделенного этому региону блока. Далее предположим, что MBII является международной корпорацией с подключением к 6 различным провайдерам, которая выбрала второй из описанных в параграфе 5.4 вариантов и, следовательно, получила шесть разных блоков адресов. В этом случае все адреса, доступные в сети XYZ, можно описать одним префиксом (это предполагает, что достаточно указать в конфигурации маршрутизатора M единственный префикс, который будут представлять все адреса, доступные через данное соединение). Доступные адреса MBII могут быть описаны шестью префиксами (это предполагает, что в конфигурации маршрутизатора X требуется указать шесть адресных префиксов для представления адресов, доступных через данное соединение).

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

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

5.6 Изолированные маршрутные домены

В настоящее время очень большое число организаций имеет соединенные между собой сети, которые не подключены ни к одному из сервис-провайдеров. Такие организации, однако, могут иметь множество частных каналов, используемых для соединения с другими организациями. Эти организации не участвуют в глобальной маршрутизации и удовлетворяются доступностью тех организации, с которыми у них имеются соединения по частным каналам. Такие организации называют изолированными (zero-homed) доменами маршрутизации.

Изолированные домены можно рассматривать, как вырожденный вариант доменов с частными каналами, описанный в предыдущем параграфе. Эти домены также не создают проблем междоменной маршрутизации. Как было сказано выше, маршрутная информация, передаваемая по частным каналам, имеет весьма ограниченное распространение (обычно лишь в пределах маршрутного домена на другой стороне частного канала). Следовательно, здесь также не возникает требований по абстрагированию адресов, за исключением тех префиксов, которые передаются через частные каналы.

Однако весьма важно, чтобы изолированные домены использовали корректные и уникальные в глобальном масштабе адреса IP. Предположим, что изолированный домен соединен частным каналом с другим доменом маршрутизации. Этот домен, в свою очередь, соединен с сетью, использующей уникальные в глобальном масштабе адреса IP. Данный домен должен иметь возможность различать адреса IP в изолированном домене от всех прочих IP-адресов, к которым он имеет маршруты. Единственным способом гарантированно обеспечить такое различие является использование в изолированном домене уникальных в глобальном масштабе адресов IP6.

5.7 Континентальное агрегирование

В целях дальнейшего снижения объемов данных, требуемых для междоменной маршрутизации, может использоваться еще один уровень иерархии. Континентальное агрегирование может оказаться весьма полезным, поскольку границы континентов определяют естественные барьеры для топологии соединений и административных границ. Таким образом, это создает естественную границу для другого уровня агрегирования данных междоменной маршрутизации. Для решения этой задачи нужно сделать так, чтобы каждый континент получил соответствующее подмножество адресного пространства. Провайдеры (как прямые, так и косвенные) каждого континента будут получать адресные блоки из таких подмножеств. Отметим, что эта схема имеет множество исключений, когда сервис-провайдеры (как прямые, так и косвенные) работают на нескольких континентах одновременно. Эти исключения должны рассматриваться аналогично ситуациям с многодомными доменами маршрутизации, описанным выше.

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

Для примера предположим, что Европе выделен префикс <194.0.0.0 254.0.0.0> так, что европейская маршрутизация включает также более длинные префиксы <194.1.0.0 255.255.0.0> и <194.2.0.0 255.255.0.0>. Все более длинные европейские префиксы могут быть анонсированы через трансатлантический канал в Северную Америку. Маршрутизатор в Северной Америке будет агрегировать эти маршруты и анонсировать только один префикс <194.0.0.0 255.0.0.0> в северо-американскую систему маршрутизации. Пакеты, адресованные хосту 194.1.1.1 будут проходить через северо-американскую систему маршрутизации и сталкиваться с маршрутизатором, который выполнял агрегирование европейских префиксов. Если префикс <194.1.0.0 255.255.0.0> недоступен, маршрутизатор будет отбрасывать эти пакеты и передавать сообщения ICMP Unreachable без загрузки трансатлантического канала.

5.8 Проблемы смены адресов

Распределение адресов IP с учетом подключения к TRD важно для обеспечения требуемого масштабирования междоменной маршрутизации в сети, содержащей миллионы маршрутных доменов. Однако распределение, основанное на топологии, предполагает, что для обеспечения максимальной эффективности маршрутизации в результате такого распределения некоторые изменения в топологии могут потребовать смены адресов.

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

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

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

Отметим также, что возможное требование смены адресов в результате изменения топологии предполагает, что полезно принимать во внимание возможные изменения топологии прежде, чем завершится процесс выделения адресов. Например, в случае маршрутного домена, который изначально имеет одно подключение, но планирует стать многодомным в будущем, разумно получать адреса IP с учетом предполагаемой в будущем топологии.

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

В течение переходного периода важно, чтобы пакеты, использующие старые адреса, маршрутизировались корректно даже после изменения топологии. Это достигается путем использования в междоменной маршрутизации принципа наибольшего соответствия (longest match).

Для примера предположим, что корпорация XYZ была изначально подключена только к региональной сети NorthSouthNet. Представители XYZ обратились к администрации NorthSouthNet и получили префикс IP, из пространства, выделенного на региональную сеть NorthSouthNet. Однако по ряду причин корпорация XYZ решила разорвать контракт с NorthSouthNet и напрямую подключиться к сети общего пользования NewCommercialNet. В результате перехода корпорация XYZ получила префикс IP из адресного пространства NewCommercialNet. Старый префикс XYZ предполагает, что трафик для XYZ следует маршрутизировать в сеть NorthSouthNet, которая больше не имеет прямого соединения с корпорацией XYZ.

Если прежний TRD (NorthSouthNet) и новый TRD (NewCommercialNet) являются смежными и могут кооперироваться, переход может быть очень простым. В этом случае пакеты, маршрутизируемые в XYZ по старым адресам, могут направляться в сеть NorthSouthNet, которая будет напрямую пересылать их в сеть NewCommercialNet, а та, в свою очередь, в XYZ. В этом случае только сетям NorthSouthNet и NewCommercialNet требуется знать, что старые адреса указывают на получателей, которые более не подключены непосредственно к NorthSouthNet.

Если старый и новый TRD не являются смежными, ситуация несколько осложняется, но по-прежнему существует несколько способов организации корректной пересылки трафика.

Если старый и новый TRD соединены между собой через другие транзитные домены, эти промежуточные домены могут согласовать корректную пересылку трафика для XYZ. В качестве примера предположим, что сети NorthSouthNet и NewCommercialNet не соединены напрямую, но обе подключены к магистральной сети BBNet. В этом случае всем трем сетям NorthSouthNet, NewCommercialNet и BBNet нужно будет поддерживать специальную запись для XYZ, чтобы трафик, направленный по старым адресам корпорации XYZ, пересылался через сеть NewCommercialNet. Однако остальным доменам маршрутизации не требуется знать о новом местоположении XYZ.

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

Те организации, которые ведут достаточно много дел с корпорацией XYZ, также могут включить специальную запись в свои таблицы маршрутизации для обеспечения оптимальной маршрутизации пакетов в сеть XYZ. Для примера предположим, что некая коммерческая магистральная сеть OldCommercialNet имеет множество заказчиков, обменивающихся трафиком с XYZ и эта третья сеть TRD напрямую связана как с NorthSouthNet, так и с NewCommercialNet. В этом случае OldCommercialNet будет сохранять одну запись для всего трафика, адресованного в NorthSouthNet, но в таблицу может быть добавлена одна (более специфичная) запись для обеспечения корректной маршрутизации пакетов, направленных по старым адресам XYZ.

Независимо от используемого для упрощения смены адресов метода, задача состоит в том, чтобы информация о старых адресах XYZ, хранящаяся в сети, была заменена данными о новых адресах. Разумно предполагать, что пройдут недели или месяцы и нужная информация разойдется по распределенной системе каталогов. Обсуждение каталога, равно как и других методов смены адресов, выходит за рамки этого документа.

Другой сложностью, связанной с переходом, является организация соответствующих агентств по адресации. Для того, чтобы не задерживалось развертывание этой схемы адресации, если не было создано подходящее агентство на соответствующем уровне, агентство более высокого уровня может выделить адреса вместо агентства более низкого уровня. В качестве примера предположим, что континентальное агентство уже получило блок адресов и сервис-провайдеры на этом континенте уже известны, но еще не создали своих агентств по распределению адресов. Континентальное агентство может предвидеть (возможно, на основе информации от провайдеров), что тот или иной провайдер в конце концов создаст свое агентство. Тогда континентальное агентство может действовать от имени этого провайдера, пока тот не готов поддерживать свое агентство по адресации.

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

5.9 Взаимодействие с маршрутизацией на основе правил

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

6. Рекомендации

Мы полагаем, что нынешний экспоненциальный рост Internet будет сохраняться или даже ускорится в обозримом будущем. Кроме того, мы ожидаем стремительной интернационализации Internet. Возможность масштабирования системы маршрутизации зависит от использования абстракции данных, основанной на иерархической адресации IP. Поскольку в Internet вводится архитектура CIDR [1], выбор иерархической структуры IP-адресации следует делать с большой осторожностью.

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

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

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

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

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

6.1 Рекомендации для плана распределения адресов

Мы ожидаем, что публичные соединения между частными доменами маршрутизации будут обеспечиваться различными TRD, включая (но не ограничиваясь):

  • магистральные (backbone) сети (Alternet, ANSnet, CIX, EBone, PSI, SprintLink);
  • множество региональных и национальных сетей;
  • множество коммерческих общедоступных сетей (PDN7).

Эти сети не будут образовывать строго иерархическую структуру (например, следует ожидать организации прямых соединений между региональными сетями) и все эти типы сетей могут использовать прямые международные соединения. Однако предполагается, что общее число таких TRD сохранится (в обозримом будущем) достаточно небольшим, чтобы использовать для этого набора TRD «плоское» пространство адресов. Эти TRD будут использоваться для организации соединений между различными доменами маршрутизации, каждый из которых может представлять собой единую корпорацию, часть корпорации, университетский кампус, государственную организацию или организацию другого типа.

Кроме того ожидается, что некоторые частные компании могут использовать выделенные частные TRD для организации соединений внутри своей компании.

Мы полагаем, что абсолютное большинство доменов маршрутизации будет подключено только к одному из TRD. Это обеспечит возможность иерархического агрегирования адресов на базе TRD. Следовательно, мы настоятельно рекомендуем иерархическое распределение адресов на основе префиксов, выделенных отдельным TRD.

Для поддержки континентального агрегирования адресов мы рекомендуем для всех TRD на каждом континенте выделять адреса из соответствующих континентальных префиксов.

Предлагаемая в этом документе схема распределения адресов предполагает, что часть пространства адресов IP следует выделить для каждого TRD (явно включая магистральные и региональные сети). Для тех краевых доменов маршрутизации, которые соединенны с одним TRD, следует выделять префиксы из адресного пространства соответствующих TRD.

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

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

6.2 Рекомендации для многодомных доменов маршрутизации

Для многодомных доменов маршрутизации существует несколько возможных вариантов, описанных в параграфе 5.4. Эти методы различаются объемом информации, которую нужно поддерживать для обеспечения междоменной маршрутизации, а также организацией таких маршрутов. В дополнение к сказанному, организации, на которые будет ложиться основная тяжесть решения этой задачи, будут разными для разных вариантов решения. Например, решения могут различаться по:

  • ресурсам, используемым на маршрутизаторах внутри TRD;
  • административным издержкам для персонала TRD;
  • сложности настройки основанной на правилах междоменной маршрутизации в каждом краевом маршрутном домене.

Используемое решение может влиять на реальные маршруты, по которым будут передаваться пакеты, а также на доступность резервных маршрутов при возникновении отказов на основном пути.

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

6.3 Рекомендации по администрированию адресов IP

Связанный с данным документ [3] содержит рекомендации по администрированию адресов IP.

7. Благодарности

Авторы рады отметить существенный вклад в эту работу, сделанный авторами RFC 1237 [2] (Richard Colella, Ella Gardner и Ross Callon). Важные концепции (и значительные фрагменты текста) были непосредственно заимствованы из этого документа.

Авторы рады отметить важный вклад в работу членов групп Federal Engineering Planning Group (FEPG) и International Engineering Planning Group (IEPG). Данный документ также отражает концепции, высказанные на конференции IETF Addressing BOF (Cambridge, MA) в июле 1992 г.

Мы выражаем благодарность Peter Ford (Los Alamos National Laboratory), Elise Gerich (MERIT), Steve Kent (BBN), Barry Leiner (ADS), Jon Postel (ISI), Bernhard Stockman (NORDUNET/SUNET), Claudio Topolcic (CNRI) и Kannan Varadhan (OARnet) за их комментарии и обзор данного документа.

8. Литература

[1] Fuller, V., Li, T., Yu, J., and K. Varadhan, «Supernetting: an Address Assignment and Aggregation Strategy», RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.

[2] Colella, R., Gardner, E, and R. Callon, «Guidelines for OSI NSAP Allocation in the Internet», RFC 1237, JuNIST, Mitre, DEC, July 1991.

[3] Gerich, E., «Guidelines for Management of IP Address Space», RFC 1466, Merit, May 1993.

[4] Cerf, V., «IAB Recommended Policy on Distributing Internet Identifier Assignment and IAB Recommended Policy Change to Internet «Connected» Status», RFC 1174, CNRI, August 1990.

9. Вопросы безопасности

В документе не обсуждаются какие-либо вопросы безопасности.

10. Адреса авторов

Yakov Rekhter

T.J. Watson Research Center, IBM Corporation

P.O. Box 218

Yorktown Heights, NY 10598

Phone: (914) 945-3896

EMail: yakov@watson.ibm.com

Tony Li

cisco Systems, Inc.

1525 O’Brien Drive

Menlo Park, CA 94025

EMail: tli@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Transit routing domain.

2Имеются в виду не те компании, которые сегодня называют провайдерами, поскольку они обеспечивают услуги доступа в Internet. В данном случае термин «провайдеры» относится к сетевым операторам, обеспечивающим передачу трафика между сетями. Прим. перев.

31997 год. Прим. перев.

4Не использующей многоуровневую иерархию. Прим. перев.

5Предполагается, что все TRD имеют маршруты друг к другу.

6В настоящее время отношение к вопросу адресов, используемых в частных сетях, несколько изменилось и описано в RFC 1918. Для связи с сетями, использующими публичные адреса IP, частные сети могут воспользоваться трансляцией сетевых адресов (NAT). Прим. перев.

7Public Data Network




RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)

Network Working Group            Internet Engineering Steering Group
Request for Comments: 1517                         R. Hinden, Editor
Category: Standards Track                             September 1993

Заявление о применимости для реализации бесклассовой доменной маршрутизации CIDR

Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)

PDF

Статус документа

В данном RFC содержится спецификация стандарта, предложенного сообществу Internet; документ служит приглашением к дискуссии в целях совершенствования и развития данной спецификации. Информацию о текущем состоянии стандартизации для этого протокола вы можете найти в документе «Internet Official Protocol Standards». Документ может распространяться без ограничений.

1. Введение

В последние годы сеть Internet развивается и растет, делая очевидными некоторые весьма серьезные проблемы масштабирования. К таким проблемам относятся:

  • Нехватка адресного пространства для сетей класса B. Одной из основных причин этого является отсутствие класса адресов, подходящего по числу адресов для организаций средних размеров. Сети класса C могут включать до 254 адресов (слишком мало), а сети класса B позволяют адресовать до 65534 хостов, что является явным избытком для организации средних размеров. В результате блоки адресов класса B используются неэффективно.

  • Избыток маршрутной информации. Размеры и скорость роста таблиц маршрутизации в маршрутизаторах Internet превосходят возможности существующих программ (и людей) по эффективному управлению этими таблицами.

  • Общая нехватка номеров IP для сетей.

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

Исполнительный комитет IESG2 после обсуждения с IETF3 в июне 1992 принял CIDR в качестве временного решения проблемы взрывного роста размеров таблиц маршрутизации [1].

2. Компоненты архитектуры

Архитектура CIDR описана в следующих документах:

  • «An Architecture for IP Address Allocation with CIDR» [2]

  • «Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy» [3]

Первый из этих документов представляет общий обзор архитектуры CIDR, а во втором описываются конкретные схемы выделения адресов.

В дополнение к этому документ «Guidelines for Management of IP Address Space» [4] содержит специфические рекомендации по выделению адресов IP, совместимые с требованиями [2] и [3], а в документе «Status of CIDR Deployment in the Internet» [5] описывается план развертывания рекомендаций [4] в сети Internet. Оба документа [4] и [5] следует рассматривать как рекомендации, а не определения.

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

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

3. Применимость CIDR

Архитектура CIDR применима к любой группе соединенных между собой доменов, которые поддерживают протокол IP версии 4 [6] [7]. CIDR не требует перехода всех доменов Internet на использование CIDR. Эта архитектура предполагает, что некоторые из существующих доменов Internet просто невозможно перевести на использование CIDR. Несмотря на это, CIDR будет обеспечивать связность с такими фрагментами, хотя оптимальные маршруты с такие места могут быть изменены.

Данный документ (Applicability Statement) требует полной поддержки CIDR от доменов Internet, обеспечивающих магистральный и транзитный сервис, для того, чтобы обеспечить существенное замедление роста4 требовательности к ресурсам со стороны маршрутизаторов, обеспечивающих глобальную связность Internet.

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

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

4. Литература

[1] Gross, P., and P. Almquist, «IESG Deliberations on Routing and Addressing», RFC 1380, IESG Chair, IESG Internet AD, November 1992.

[2] Rekhter, Y., and T. Li, «An Architecture for IP Address Allocation with CIDR», RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems, September 1993.

[3] Fuller, V., Li, T., Yu, J., and K. Varadhan, «Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy», RFC 1519, BARRNet, cisco, Merit, and OARnet, September 1993.

[4] Gerich, E., «Guidelines for Management of IP Address Space», RFC 1466, Merit, May 1993.

[5] Topolcic, C., «Status of CIDR Deployment in the Internet», RFC 1467, CNRI, August 1993.

[6] Postel, J., «Internet Protocol — DARPA Internet Program Protocol Specification», STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

[7] Braden, R., Editor, «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, IETF, October 1989.

5. Вопросы безопасности

Вопросы безопасности не рассматриваются в данном документе.

6. Адрес автора

Robert M. Hinden

Sun Microsystems

2550 Garcia Ave, MS MTV5-44

Mt. View, CA 94043

Phone: (415) 336-2082

Fax: (415) 336-6015

EMail: hinden@eng.sun.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Classless Inter-Domain Routing

2The Internet Engineering Steering Group – Исполнительный комитет IETF. Прим. перев.

3Internet Engineering Task Force. Прим. перев.

4Более медленное по сравнению со скоростью роста числа выделенных номеров IP.

5На сайте www.protocols.ru имеется перевод спецификации на русский язык. Прим. перев.




RFC 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describingthe Format of Internet Message Bodies

RFC: 1521

Оригинал: MIME — Multipurpose Internet Mail Extensions

Другие версии: RFC 1341, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049

Категория: Проект стандарта

Дата публикации:

Авторы: N. Borenstein, N. Freed

Перевод: Антон Воронин

Источник

Документ представляет собой неполный русский перевод спецификации RFC 1521 «MIME — Multipurpose Internet Mail Extensions. Part one. Mechanismes for Specifying and Describing the Format of Internet Message Bodies», а также конспект некоторых других документов, касающихся применения стандарта MIME.

MIME означает «Multipurpose Internet Mail Extensions» (Многоцелевые расширения почтового стандарта Internet). Этот стандарт описывает как пересылать по электронной почте исполняемые, графические, мультимедийные, смешанные данные. Типичные применения MIME — пересылка графических изображений, аудио, документов Word, программ и даже просто текстовых файлов, то есть, когда важно, чтобы входе пересылки не производилось никаких преобразований над данными. MIME также позволяет размечать письмо на части различных типов так, чтобы получатель (почтовая программа) мог определить, что делать с каждой из частей письма.

Как читать письма в стандарте MIME? Т.к. MIME используется всего несколько лет, еще существуют старые почтовые программы, которые не понимают MIME. Однако, растет число почтовых программ, имеющих встроенную поддержку MIME (одна из самых популярных — «Pine», разработанная в Вашингтонском университете и реализованная для платформ UNIX, VMS, DOS, Windows). К тому же в некоторых почтовых системах имеются специальные шлюзы, обеспечивающие MIME-трансляцию. Но даже если у вас нет возможности использовать MIME-совместимую почтовую программу и нет доступа к подобному шлюзу, то можно также воспользоваться рядом программ, способных интерпретировать письма в MIME, сохраненные почтовой программой в файле. Например, програма «munpack», созданная в университете Carnegie Mellon. Существуют ее версии для Unix, PC, Macintosh, Amiga.

Долгое время для кодирования бинарных файлов в 7-битный формат (чтобы обеспечить их пересылку по почтовой системе Internet) использовалась кодировка UUENCODE, имеющая ряд технических ограничений. Стандарт MIME предполагает использовние более устойчивой кодировки «Base64», которая специально разработана для обеспечения сохранности данных, пересылаемых по email, при различных преобразованиях, имеющих место в ходе прохождения почтовых шлюзов.

Оглавление

1. Введение

Со времени опубликования в 1982 г., стандарт RFC 822 определил и полностью или частично внедрил формат текстовых писем в почтовой системе Internet. Но с расширением его использования, обнаружился ряд ограничений, заметно ограничивающих удовлетворение пользовательских потребностей. В частности, возможность пересылки нетекстовых данных, например, аудио и графики, посто не была упомянута в RFC 822, описывавшем лишь формат текстовых сообщеий. И даже в случае текста, RFC 822 обошел вниманием нужды пользователей, использующих расширенный набор символов, что характерно для азиатских и большинства европейских языков. Итак, требовалась дополнительная спецификация. Основное ограничение RFC 822 — относительно короткие строки и 7-битная символьная таблица. Пользователям дляотправки нетекстовых данных приходилось конвертировать тело своего письма в 7-битную форму с помощью UUENCODE, BINHEX и др.

Более очевидными стали ограничения RFC 822 при разработке почтовых шлюзов между хостами, использующими стандарт RFC 822 и хостами, использующими стандарт X.400. X.400 имеет механизмы для включения нетекстовых данных в тело письма. В настоящее время стандарты для перевода почтовых сообщений из X.400 в RFC 822 предполагают, что нетекстовые части тела письма должны быть сконвертированы (но не закодированы) в ASCII формат, либо должны быть «выброшены» из письма с уведомлением об этом получателя. А потеря информации крайне не желательна для пользователя.

MIME разработан как расширяемый механизм с расчетом на то, что набор пар content-type/subtype будет расти со временем. Некоторые другие поля заголовка MIMЕ, включая имена наборов символов, также, вероятно, получат большее число возможных значений. С этой целью MIME определяет процесс регистрации через Internet Assigned Numbers Authority (IANA), как центр регистрации этих значений. Описание процесса регистрации можно найти в приложении E RFC 1521.

2. Замечания, соглашения и обобщения

Термины «сообщение» и «письмо» являются синонимами. Термин «часть письма» или «часть тела письма» подразумевает одну из частей письма, разбитого на части разных типов данных. Часть тела письма, в свою очередь, имеет тело и заголовок, так что имеет смысл говорить о теле части тела письма. В дальнейшем, при отсутствии оговорок, «телом» будем называть тело рассматриваемого в данный момент объекта — части письма либо всего письма. Как уже ясно, формат MIME-сообщения, в общем случае, рекурсивен.

3. Поле заголовка «MIME-Version»

Поскольку старый стандарт RFC 822 все еще используется, а MIME возможно, изменится и дополнится в будущем, почтовой программе необходимо знать, применен ли новый стандарт в конкретном письме или нет. Поэтому в заголовок ввелено новое поле «MIME-Version», объявляющее версию стандарта, в соответствии с которым написано данное письмо.

Все почтовые сообщения, составленные в соответствии с MIME-стандартом, должны иметь это поле в своем заголовке, например:

MIME-Version: 1.0

Так как возможно, в будущем формат заголовка письма может расшириться, формально содержание поля «MIME-version» дается следующим образом:

версия := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Т.о., будущие значения версии формата, которые могут заменить «1.0», должны быть целыми числами, разделенными точкой. Если письмо получено со значением версии MIME, отличным от «1.0», оно не будет рассматриваться почтовой программой, как соответствующее данной спецификации.

Важно, что поле заголовка «MIME-Version», должно располагаться в самом начале письма. Это не обязательно для каждой из частей тела письма в случае многочастевого письма, но обязательно для заголовков частей типа «message», если и только если эта часть сама по себе декларирована как соответствующая спецификации MIME.

Не возможно полностью определить как почтовая программа, поддерживающая MIME, должна интерпретировать письмо, имеющее значение MIME-version, отличное от «1.0». Но, как минимум, почтовая программа должна предупредить пользователя о том, что письмо написано в незнакомом ей формате.

Все поля заголовка, включая MIME-Version, Content-type, и т.д., должны соответствовать общим синтаксическим правилам, определенным в RFC 822. В частности, допускается включение комментариев (т.е., следующие 2 примера эквивалентны):

MIME-Version: 1.0
MIME-Version: 1.0 (Generated by GBD-killer 3.7)

4. Поле заголовка «Content-Type»

Назначение этого поля — наиболее полное описание данных, содержащихся в теле, с тем, чтобы почтовый агент (программа) получателя могла выбрать соответствующий механизм для их обработки. Впервые это поле было определено в RFC 1049, но имело более простой синтаксис.

Данное поле включает в себя идентификаторы типа и подтипа, а также может содержать некоторую вспомогательную информацию, которая может потребоваться для конкретного типа данных. После идентификаторов типа и подтипа оставшаяся часть поля — просто набор параметров, заданных в порядке «атрибут/значение». Набор параметров зависит от типа данных. (В частности, не может быть глобально-значимых параметров, справедливых сразу для всех типов содержимого ьела письма. Глобальные механизмы в MIME-модели реализованы с помощью введения дополнительных полей «Content-*»). Очередность параметров значения не имеет. В числе определенных параметров — «charset», декларирующий символьный набор (кодировку, кодовую страницу — это все синонимы) тела письма. Комментарии допускаются.

Вообще, поле Content-Type самого верхнего уровня используется для объявления общего типа данных, в то время как подтип определяет специальный формат для данных этого типа. Так, значение «image/xyz» поля Content-Type сообщает пользовательской программе, что данные являются графическим изображением (image), даже если эта почтовая программа не имеет понятия о специальном формате «xyz» этой картинки. Но эта информация может быть использована программой, например, чтобы решить, показывать ли пользователю строковые данные неизвестного подтипа — показ таких данных может быть оправдан для незнакомых подтипов текста, но не для незнакомых подтипов графики, аудио или видео. По этой причине, данные зарегистрированного подтипа аудио, графики, текста или видео не должны содержать внутри себя части другого подтипа — для содержания в письме данных одного типа, но разных подтипов следует использовать тип «multipart» или «application».

Хотя многие параметры (модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр «boundary» применим только с типом «multipart», а параметр «charset» может использоваться с несколькими типами).

Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться за счет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегистрированный тип содежимого, ему должно быть дано имя, начинающееся с «X-«, чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.

Правильное заполнение поля Content-Type:

содержимое := "Content-Type"  ":"  тип  "/"  подтип  *(";" параметр)
             ; нечувствительное к регистру букв задание типа и подтипа

тип :=     "application"     / "audio"
         / "image"           / "message"
         / "multipart"       / "text"
         / "video"           / признак нестандартного типа
         ; Все значения нечувствительны к регистру букв

признак нестандартного типа :=  x- / iana-

iana- := <общепринятый признак расширения, зарегистрированный соответ-
          ственно приложению "E" RFC 1521>

x- := <Два последовательных символа "X-" или "x-", без пробела
       или другого символа между ними>

подтип := слово    ; регистр безразличен

параметр := атрибут "=" значение

атрибут := слово   ; регистр безразличен

значение := слово / строка в кавычках

слово := любые ASCII-символы кроме  пробелов,  Ctrl-последова-
тельностей и специальных символов

Специальные символы:=  "(" / ")" / "<" / ">" / "@"
                    /  "," / ";" / ":" / "\" / <">
                    /  "/" / "[" / "]" / "?" / "="
; Эти символы используются в строке значений параметров

Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов «/», «?», «=» и отсутствием символа «.».

Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными — в зависимости от параметра. Например, значения границ multipart-письма являются чувствительными, а значение «access-type» для message/External-body не является.

Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:

  1. Нестандартные значения (начинающиеся с «X-«) могут быть определены по договоренности для двух или более общающихся друг с другом почтовых агентов (программ) без какой-либо внешней регистрации и стандартизации.
  2. Новые стандартные значения подтипов должны быть документированы, зарегистрированы и опробованы в IANA, как описано в приложении «E» RFC 1521. Если новый подтип предлагается для широкого использования, формат, описываемый им, должен быть описан в опубликованной спецификации и, возможно, предложен к стандартизации.

Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:

text — текстовая информация. Основой подтип — «plain» — соответствует обычному неформатированному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуализацию, но для понимания идеи содержания можно обойтись и без дополнительного ПО. Возможные подтипы могут описывать легко читаемые форматы различных текстовых процессоров.

multipart — содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимонезависимых типов. Изначально определено четыре подтипа:

  1. «mixed» — основной;
  2. «alternative» — для представления одних и тех же данных в разных форматах;
  3. «parallel» — если разные части документа должны просматриваться одновременно;
  4. «digest» — если каждая из частей тела письма имеет тип «message».

message — письмо в письме. Тело, содержащее данные типа «message», само является письмом или частью письма, полностью отформатированного в соответствии со стандартом RFC 822, которое, в свою очередь, может содержать свое собственное поле заголовка «Content-Type».
Подтипы:

  1. «rfc822» — основной;
  2. «partial» — определен для частично-цитируемых писем для предотвращения фрагментирования тел содержащихся писем в случае слишком большой их общей длины для возможностей почтового транспорта;
  3. «External-body» — используется, чтобы указать, что тело письма очень большое и находится вне письма.

image — графические данные. Графика требует соответствующего устройства вывода (графический дисплей, принтер, факс) для отображения своей информации. Изначально определены два подтипа для наиболее распространенных графических форматов — jpeg и gif.

audio — звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип — «basic».

video — видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единственный изначально определенный подтип — «mpeg».

application — как правило, неинтерпретируемый двоичный код либо информация, предназначенная для обработки почтовой программой.
Подтипы:

  • «octet-stream» — основной подтип; предназначен для неинтерпретируемых двоичных данных, для которых рекомендуемым действием является предложение пользователю сохранить в файл на диске.
  • «PostScript» — дополнительный подтип; применяется при пересылке PostScript-документов в теле письма.

По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как «Content-type: text/plain; charset=us-ascii». Это значение полагается, если поле Content-type не определено. Поэтому почтовая программа получателя может неверно истолковать содержимое письма, если при отправке не было указано поле Content-type, но на самом деле текст письма имеет другую кодировку или даже тип.

При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip’ом и обработаный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. «text/plain; charset=us-ascii».

Необходимо учесть, что в будущем ожидается заметное увеличение числа регистрированных типов и особенно подтипов содержимого писем. Если почтовая программа встретит неизвестное ей значение поля Content-type, она должна интерпретировать содержимое этого письма как «application/octet-stream» (см.выше).

5. Поле заголовка Content-Transfer-Encoding

Многие типы данных, пересылаемых через email требуют «натурального» представления, то есть, 8-битный набор символов либо двоичный код (что для машины — одно и то же, только представимо для пользователя по-разному). В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.

Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлемый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.

В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно «ужать» бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: «читабельный» и «плотно ужимающий».

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

конвертация := "Content-Transfer-Encoding" ":" механизм

механизм :=     "7bit"  ;
               / "quoted-printable"
               / "base64"
               / "8bit"
               / "binary"
               / x-token

Значения не чувствительны к регистру букв, то есть, Base64, BASE64 и bAsE64 — одно и то же. Значение «7BIT» означает, что тело письма уже имеет 7-битный формат и не тренбует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.

Значения «8bit», «7bit» и «binary» означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы. В частности:

«7bit» означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.

«8bit» означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).

«Binary» означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может не соблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.

Хотя на первый взгляд разница в значениях Content-Transfer-Encoding может показатся неважной — ведь все они означают, что никакого преобразования нет, но четкая разметка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и особенности работы, число которых со временем растет.

Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованного транспорта почты Internet, для которого является приемлемым включение в тело письма некодированных двоичных данных. Таким образом, значение «binary» фактически не является легальным в Internet. Но в соответствии с MIME, при использовании почтовой системой транспорта, умеющего работать с двоичными данными, в случае, когда необходимо послать двоичные данные по e-mail, необходимо указать это в заголовке в поле Content-Transfer-Encoding.

Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.

Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс «X-» («x-«), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем. Использование X-значений позволяется только как результат взаимосоглашения между взаимодействующими системами.

Если поле Content-Transfer-Encoding появляеися в заголовке тела какой-то части письма, оно применяется только к содержимому этой части. Если письмо (часть письма) имеет тип «multipart» или «message», то поле Content-Transfer-Encoding может иметь в качестве своего значения только длину символа («7bit», «8bit» и т.д.) или «binary».

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

Все кодирующие механизмы, определенные в спецификации MIME, кодируют любые данные в символьную форму. Так, к примеру, полагая, что тело письма (части письма) имеет поля заголовка вроде:

Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64

то это означает, что тело письма представляет собой ASCII-код base64 текстовых данных, которые в нормальном виде имеют языковую кодировку ISO-8859-1, и будут в этой языковой кодировке после декодирования.

Все множество определенных значений поля content-transfer-encoding кроме начинающихся с префикса «X-«, зарезервировано в IANA для будущего использования. Частные соглашения по значениям content-transfer-encoding также настоятельно не рекомендуются.

Некоторые значения Content-transfer-encoding могут использоваться только с определенными типами (поле Content-Type). В частности, запрещено использовать любые значения кроме «7bit», «8bit», или «binary» с любым типом, рекурсивно включающим заголовки с полем Content-Type (как правило, это типы «multipart» и «message»). Все кодирования, необходимые для содержимого тел многочастного письма должны быть произведены на более низком уровне.

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

Замечание по переводу кодов: Конверторы quoted-printable и base64 разработаны так, что данные после их применения легко взаимоконвертируемы. Единственный нюанс, возникающий в подобной ретрансляции — признак конца строки. При конвертации из quoted-printable в base64 перевод строки должен быть заменен последовательностью CRLF. Соответственно и наоборот, но ТОЛЬКО при конвертации текстовых данных.

5.1. Механизм конвертации «Quoted-Printable»

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

В Quoted-Printable байты должны быть рпедставлены в соответствии со следующими правилами:

Правило №1 (обычное 8-битное представление): Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предворяемых знаком «=». При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.

Правило №2 (Буквенное представление): Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с ‘!’ по ‘<‘ и с ‘>’ по ‘~’).

Правило №3 (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы «Табуляция» и «Пробел», но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.

Правило №4 (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF. Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.

Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлеии текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.

ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется ‘мягкий’ перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:

Now's the time for all folk to come to the aid of
their country.

то в Quoted-Printable encoding он может быть представлена следующим образом:

Now's the time =
for all folk to come=
 to the aid of their country.

Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.

Поскольку символ дефиса («-«) представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов «=_», которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)

Замечание: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует). Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз — экранировать ASCII-символы.

!"#$@[\]^`{|}~

в соответствии с правилом #1.

Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.

Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как «=0D=0A», в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.

Синтаксис данных в quoted-printable описывается следующим образом:

quoted-printable := ([*(простой текст / ПРОБЕЛ / ТАБУЛЯЦИЯ) простой текст]
                     ["="] CRLF)
     ; Максимальная длина строки — 76 символов, включая CRLF

 простой текст := байт /<любой ASCII-символ "=", ПРОБЕЛ или ТАБУЛЯЦИЯ>
     ; символы, не перечисленные в приложении B к RFC 1521 как  безопас-
     ; ные для почты, также не рекомендуются к использованию

байт := "=" 2(ФИФРА / "A" / "B" / "C" / "D" / "E" / "F")
     ; байт используется для символов > 127, =, ПРОБЕЛ, или ТАБУЛЯЦИЯ,
     ; и рекомендуется для представления любых символов, не  перечислен-
     ; ных в приложении B к RFC 1521 как безопасные для почты

5.2. Механизм конвертации Base64

Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного «чистого» текста.

Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ «=» используется для обозначения функции спец. обработки).

Примечание: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 — часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.

Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.

Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта («.», CR, LF) и для синтаксиса вложенных тел MIME («-«).

                    Таблица 1: Алфавит Base64

Значение Код    Значение Код    Значение Код    Значение Код
       0 A            17 R            34 i            51 z
       1 B            18 S            35 j            52 0
       2 C            19 T            36 k            53 1
       3 D            20 U            37 l            54 2
       4 E            21 V            38 m            55 3
       5 F            22 W            39 n            56 4
       6 G            23 X            40 o            57 5
       7 H            24 Y            41 p            58 6
       8 I            25 Z            42 q            59 7
       9 J            26 a            43 r            60 8
      10 K            27 b            44 s            61 9
      11 L            28 c            45 t            62 +
      12 M            29 d            46 u            63 /
      13 N            30 e            47 v
      14 O            31 f            48 w            = (заполнитель)
      15 P            32 g            49 x
      16 Q            33 h            50 y

Выходной поток (закодированные бфайты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.

Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель ‘=’. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа ‘=’; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов ‘=’; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ ‘=’.

Т.к. символ ‘=’ является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.

Любые бессмысленные последовательности в коде Base64 вроде «=====» должны быть игнорированы.

Если кодируемый текст не находится в канонической форме. то перед конвертацией в Base64 необходимо сначала все концы строк заменить стандартной последовательностью CRLF. Предпочтительнее эту функцию встроить в кодировщик Base64, нежели заставлять пользователя производить предварительную канонизацию текста другими средствами.

Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ ‘-‘.

6. Дополнительные Content- поля заголовка

6.1. Необязательное поле Content-ID

При создании почтового агента верхнего уровня может быть желательно позволить одному телу иметь ссылку на другое. Для этого поля могут быть помечены с помощью поля заголовка «Content-ID», синтаксически идентичного полю «Message-ID»:

идентификатор :=  "Content-ID" ":" идентификатор письма

Как и значения поля Message-ID, значения поля Content-ID должны быть абсолютно уникальными (для всего мира).

Такой идентификатор может быть использован для идентификации тела письма (части письма) в нескольких контекстах, в часности, для кэширования данных, указываемых с помощью механизма message/external-body. Хотя поле Content-ID является необязательным в общем случае, его использование необходимо в реализациях, генерирующих данные, имеющие дополнительный тип «message/external-body» (поле Content-type). Каждое тело такого типа должно обязательно иметь в своем заголовке поле Content-ID для обеспечения ссылки на такие данные.

Значение поля Content-ID имеет специальную семантику в случае типа multipart/alternative. (См. соотв. пункт).

6.2. Необязательное поле Content-Description

Возможность ассоциировать некоторую описательную информацию с данными часто очень желательна. например, может быть полезным описать тело, содержащее графическое изображение, как «a picture of the Space Shuttle Endeavor.» Этот текст и может быть помещен в поле заголовка Content-Description.

описание := "Content-Description" ":" *текст

Описание должно иметь языковую кодировку US-ASCII, хотя механизм, определенный в RFC-1522 может быть использован для не-US-ASCII значений.

7. Предопределенные значения поля Content-Type

7.1. Тип ‘Text’

Тип ‘text’ предназначен для пересылки текстовых материалов. Это значение поля — по умолчанию. Для обозначения языковой кодировки текста используется параметр «charset» для некоторых подтипов, включая основной подтип, «text/plain», соответствующий простому (неформатированному) тексту. В Internet’овской почте значением Content-Type по умолчанию является следующее: «text/plain; charset=us-ascii». Если текст является размеченным и нет соответствующего ПО для корректного визуального представления этого текста пользователю, имеет смысл сообщить ему подтип этих текстовых данных.

7.1.1. Параметр ‘charset’

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

Спецификации любых новых подтипов типа ‘text’ должны определять, будет ли этот новый подтип использовать параметр «charset» либо наоборот, будет запрещать его использование. Любое тело, не содержащее внутри себя других, должно целиеом быть в одной языковой кодировке. В частности, создатели новых подтипов должны уделить внимание многбайтным символьным наборам.

Дополнительно к предопределенным новые языковые кодировки могут быть зарегистрированы через IANA, хотя стандартизация их использования требует опробирования IESG (см. RFC-1340). Если используется 8-битная языковая кодировка (например, koi8 или cp866), то необходимо наличие поля заголовка Content-Transfer-Encoding для обеспечения передачи через ряд протоколов, в частности, SMTP.

Необходимо заметить, что управляющие символы (0-31, 127), включая DEL, не имеют определенного значения за исключением последовательности CRLF (13,10), означающей конец строки. Два символа де-факто широко употребляются: FormFeed (12), означающий, что следующий за ним текст должен начинаться на новой странице; и TAB (9), часто, но не всегда означающий «перевести курсор на следующий ближайший столбец после данной позиции, где номер столбца кратен воьсми». Любое другое использование управляющих символов или DEL в теле должно быть в рамках частного соглашения между отправителем и получателем. Но такие соглашения крайне не рекомендуются и по возможности должны быть заменены другими возможностями MIME.

Существует огромное количество языковых кодировок, что не является положительным фактом. В дальнейшем предполагается ввести универсальную многобитную языковую кодировку, поддерживающую все языки мира. К сожалению, существующая практика говорит о том, что возможно, еще долгое время электронной почте придется иметь дело с многими кодировками. По этой причине предопределены имена для наиболее распространенных языковых кодировок:

  • US-ASCII
  • ISO-8859-X — где «X» — цифра от 1 до 9 включительно, означающая номер версии кодировки ISO-8859

Параметр «charset» был определен в основном для текстовых данных, но возможно, для бинарных данных тоже может потребоваться указать языковую кодировку, в этом случае должен использоваться тот же синтаксис те же значения.

Почтовое программное обеспечение должно руководствоваться принципом наименьшего набора символов, то есть, если письмо пишется как-бы в восьмибитной ISO-8859-1, но в письме используются символы лишь некоторого поднабора, например, семибитного US-ASCII, то почтовая программа должна автоматически определить имя символьной кодировки как US-ASCII. В этом случае уменьшится нагрузка в сети и увеличаися шансы, что получатель прочтет письмо без искажений.

7.1.2. Подтип ‘Text/plain’

Это основной подтип, соответствующий простому (неформатированному) тексту. Значение поля Content-Type для почты Internet по умолчанию — «text/plain; charset=us-ascii». Это тип данных, соответствующий RFC 822.

Других предопределенных подтипов для типа ‘text’ нет.

Формальный синтаксис для типа ‘text’:

тип := "text" "/" подтип [";" "charset" "=" имя языковой кодировки]

подтип := "plain" / расширение (не предопределенный подтип)

имя языковой кодировки:= "us-ascii"/ "iso-8859-1"/ "iso-8859-2"
       / "iso-8859-3" / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"
       / "iso-8859-7" / "iso-8859-8" / "iso-8859-9" / расширение
       (не предопределенная кодировка)

7.2. Тип ‘multipart’

Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтакс письма RFC 822 (то есть, иметь заголовок,ь пустую строку и тело), но должна иметь открывающую и закрывающую границы.

Часть письма не должна интерпретироваться как настоящее письмо RFC 822. Вообще, для части письма наличие заголовка не обязательно, так что она может начинаться и с пустой строки, но при этом, все признаки, описываемые в заголовке, имеют значение по умолчанию. Для частей письма имеют смысл только поля, описывающие содержимое, то есть. начтинающиеся с «Content-«. Все остальные поля, необходимые в заголовке верхнего уровня, обычно игнорируются в частях письма при обработке почты, более того, в некоторых почтовых шлюзах они могут быть просто удалены. Для экспериментальных и частных целей могут использоваться «X-» поля, но информация, в них заложенная, может быть потеряна при прохождении некоторых почтовых шлюзов.

Замечание: Различие между письмом RFC 822 и частью письма MIME является маленькой, но важной. Шлюз между почтой Internet и X.400, например, должен иметь возможность отличить часть письма, содержащую графическое изображение, от части письма, содежащей вложенное письмо, телом которого является графическое изображение. Для представления последнего соответствующая часть письма должна иметь «Content-Type: message» и ее тело после пустой строки должно являться вложенным письмом со своим собственным полем заголовка «Content-Type: image». Схожесть синтаксиса обеспечивает легкость конверсии от письма к части письма, но различие между ними должно быть усвоено производителями ПО.

Граница части письма не должна появляться внутри самой части письма.

Все существующие и будущие подтипы типа «multipart» должны иметь идентичный синтаксис. Они могут различаться своей семантикой. Это требование гарантирует, что совместимые пользовательские агенты смогут по крайней мере распознать и разделить части многочастного письма, даже имеющего неизвестный им подтип.

Как упомянуто в определении поля Content-Transfer-Encoding, использование других значений кроме «7bit», «8bit» или «binary» запрещено для типа «multipart». Почтовые шлюзы и другие почтовые агенты часто вносят изменения в заголовки верхнего уровня. В частности, они могут добавлять, убирать, переупорядочивать определенные поля. Такие изменения запрещены для заголовков частей письма, находяшихся внутри тела типа «multipart».

7.2.1. Multipart: общий синтаксис

Поле Content-Type многочастного письма требует одного параметра, «boundary», который определяет границы вложения. Границей является строка, состоящая из двух символов «-» (десятичный код 45) и значения параметра ‘boundary’ из поля заголовка Content-Type.

Замечание: Два символа «-» используются для совместимости с более ранним методом вложения писем, описанным в RFC 934 и для облегчения поиска границ. Однако, многочастные письма MIME не полностью совместимы с RFC 934; в частности, они не подчиняются соглашению RFC 934 по экранированию строк символом «-«, так как с каждым новым уровнем экранирования длина строк увеличивается. А поскольку SMTP-транспорты часто обрезают длинные строки, этот механизм становится неприменимым в случае многоуровневой структуры письма типа ‘multipart’.

Вниманию производителей ПО: синтаксис параметров поля Content-Type таков, что зачастую необходимо значения границ в параметре ‘boundary’ заключать в кавычки. Это не всегда требуется, но никогда не повредит. Программистам следует изучить синтаксис внимательно, чтобы не допустить ошибок в поле Content-Type. Типичное поле Content-Type для типа ‘multipart’ может выглядеть следующим образом:

Content-Type: multipart/mixed;
     boundary=gc0p4Jq0M2Yt08jU534c0p

Но в следующем примере содержится ошибка:

Content-Type: multipart/mixed;
     boundary=gc0p4Jq0M:2Yt08jU534c0p

(из-за двоеточия), которая может быть исправлена следующим образом:

Content-Type: multipart/mixed;
     boundary="gc0p4Jq0M:2Yt08jU534c0p"

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

--gc0p4Jq0M:2Yt08jU534c0p

Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может неоканчиваться концом строки, что принципиально важно в случае бинарных данных. Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.

Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.

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

--gc0p4Jq0M2Yt08jU534c0p--

Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.

Замечание: Эти области приамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME’овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.

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

В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет:

From: Nathaniel Borenstein
To:  Ned Freed
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple
boundary"

Это приамбула. Должна быть игнорирована
--simple boundary

Это простой ASCII-текст.
Он НЕ оканчивается признаком конца строки.
--simple boundary
Content-type: text/plain; charset=us-ascii

Это простой ASCII-текст.
Он оканчивается признаком конца строки.

--simple boundary--
Это эпилог. Тоже должен игнорироваться MIME-программами.

Часть письма, в свою очередь, также может иметь тип ‘multipart’, то есть. быть многочастным телом, но при этом метки границ, использующиеся во внешнем и во внутреннем multipart-телах, должны отличаться друг от друга.

Использование типа ‘multipart’ в одночастном письме может быть полезно в некоторых контекстах и не запрещено.

Единственным обязательным параметром для типа ‘multipart’ является параметр ‘boundary’, состоящий из 1-70 символов без хвостовых пробелов (которые могут быть удалены в процессе пересылки, и тогда почтовая программа получателя не сможет разделить вложенные части).

граница := 0*69<символов границы> символ_границы_кроме_пробела

символ границы := символ_границы_кроме_пробела / " "

символ_границы_кроме_пробела := ЦИФРА / БУКВА ЛАТИНСКОГО АЛФАВИТА / "'"
              / "(" / ")" / "+" /"_" / "," / "-"
              / "." / "/" / ":" / "=" / "?"

Общий вид многочастного тела — следующий:

многочастное тело := приамбула  вложения  признак_конца  эпилог

вложение := разделитель  часть_тела  CRLF

разделитель := "--"  метка_границы  CRLF
               ; метка границы должна браться из поля Content-Type.
               ; Не должно быть пробелов между "--" и меткой границы.

признак конца := "--"  метка_границы  "--"  CRLF
               ; Опять, без пробела перед "--",

приамбула := игнорируемый текст

эпилог := игнорируемый текст

игнорируемый текст := *(*текст CRLF)

часть_тела := <письмо RFC 822, со всеми необязательными полями
              заголовка>

ЗАМЕЧАННИЕ: В некоторых транспортах такие ограничения RFC 822, как использование тольеко печатных символов в теле, могут не действовать. Ослабления таких ограничений должны быть истолкованы как локальные расширения определения тела письма настолько, насколько они поддерживаются почтовым транспортом и адекватно документированы в поле заголовка Content-Transfer-Encoding. Однако, ни при каких обстоятельствах в заголовках как письма, так и его частей, не должно содержаться каких-либо символов, кроме US-ASCII.

7.2.2. Основной подтип «multipart/mixed»

Это основной подтип для типа ‘multipart’, он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу ‘mixed’.

7.2.3. Подтип «multipart/alternative»

Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику.

Почтовые системы должны распознавать, что данные из разных частей взаимозаменяемы. Системы должны выбрать наиболее подходящий вариант для локальной платформы и других условий, в некоторых случаях, с согласия пользователя. Как и в предыдущем случае, порядок частей в письме существенен. В этом случае альтернативы располагаются в порядке уменьшения отличия от оригинала. Обычно, выбирается последняя часть (альтернатива) из тех, которые имеют тип, поддерживаемый локальной системой получателя.

Multipart/alternative может быть использована, к примеру, для пересылки текста в некотором гипотетическом формате:

From:  Nathaniel Borenstein
To: Ned Freed
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42

--boundary42

Content-Type: text/plain; charset=us-ascii

   ... Здесь содержится версия простым текстом ....
--boundary42
Content-Type: text/richtext

   .... Здесь содержится версия с разметкой RFC 1341 ...
--boundary42
Content-Type: text/x-whatever

   .... Здесь содержится версия в гипотетическом формате ...
--boundary42--

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

Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных (иначе зачем было бы его изобретать?), пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив. В случае, если одна из альтернатив сама имеет тип ‘multipart’ и содержит подчасти неизвестных типов, пользовательский агент может выбрать, показывать ли эту альтернативу, предыдущую или обе.

Замечание: С точки зрения программиста, может показаться более удобным располагать альтернативы в обратном порядке, но данный порядок позволяет устаревшим не-MIME’овским почтовым программам отобразить в первую очередь наиболее понятный вариант.

Замечание по семантике поля ‘content-id’ в письме multipart/alternative: Рекомендуется, чтобы каждая часть имела уникальное значение поля Content-ID в случае, если содержимое этих частей не является идентичным. Однако, там, где содержащаяся информация идентична (например, если несколько частей типа «application/external- body» определяют альтернативные пути доступа к одним и тем же внешним по отношению к письму данным), должно использоваться одно и то же значение Content-ID, чтобы оптимизировать работу кэширующего механизма на системе получателя. Однако, не рекомендуется, чтобы значения Content-ID, использующиеся для частей, отличались от значения Content-ID, использующегося в заголовке верхнего уровня, если такое поле в нем присутствует.

7.2.4. Подтип «multipart/digest»

Этот подтип идентичен подтипу ‘multipart/mixed’, но имеет другую семантику. Например, для ‘digest’ значением по умолчанию является не «text/plane», а «message/rfc822».

В соответствии с этим подтипом, письмо-дайджест может выглядеть следующим образом:

From: Moderator-Address
To: Recipient-List
MIME-Version: 1.0
Subject:  Internet Digest, volume 42
Content-Type: multipart/digest;
     boundary="---- next message ----"

------ next message ----

From: someone-else
Subject: my opinion

   ... тело вложенного письма ...

------ next message ----

From: someone-else-again
Subject: my different opinion

   ... тело другого вложенного письма ...

------ next message ------

7.2.5. Подтип «multipart/parallel»

Отличие этого подтипа от «multipart/mixed», в частности, состоит в том, что порядок расположения частей письма не принципиален.

Данные этого подтипа должны отображаться одновременно, если платформа получателя обладает соответствующими возможностями. Однако, почтовый агент отправителя должен сознавать, что программа получателя может не иметь подобных возможностей и отобразить все части письма последовательно.

7.2.6. Другие подтипы типа «multipart»

В будущем ожидается введение новых подтипов. Программистам рекомендуется интерпретировать незнакомые подтипы типа ‘multipart’ аналогично «multipart/mixed».

Формальный синтаксис поля Content-Type для данных типа «multipart»:

multipart-тип := "multipart" "/" multipart-подтип
                 ";" "boundary" "=" метка_границы

multipart-подтип := "mixed" / "parallel" / "digest"
               / "alternative" / подтип-расширение

Полный пример Multipart-письма

Данный пример иллюстрирует письмо из пяти частей: две — простой текст, одна — вложенное multipart-письмо, одна — размеченный текст и одна — вложенное письмо, содержащее текст в не-US-ASCII языковой кодировке. Третья часть (вложенное multipart-письмо) состоит из двух частей, требующих параллельного представления пользователю, — графическое изображение и звуковой фрагмент.

MIME-Version: 1.0
From: Nathaniel Borenstein
To: Ned Freed
Subject: A multipart example
Content-Type: multipart/mixed;
     boundary=unique-boundary-1

Это область преамбулы multipart-письма. Почтовые программы, понимающие
формат multipart, должны игнорировать все, что в ней  находится.  Если
же вы при получении подобного письма видите этот текст на экране,  вам
следует сменить почтовую программу.
--unique-boundary-1

   ...Здесь находится некоторый текст...
[Обратите внимание, что предшествующая  пустая  строка  означает,  что
поля заголовка не были заданы,  и  это — простой  текст  в  языковой
кодировке US ASCII.]

--unique-boundary-1
Content-type: text/plain; charset=US-ASCII

Это  часть  предыдущей  части,  но  иллюстрирующая   ясную,    а    не
подразумеваемую типизацию содержимого.

--unique-boundary-1
Content-Type: multipart/parallel;
     boundary=unique-boundary-2

--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64

   ... кодированный в base64 одноканальный звуковой фрагмент для час-
       тоты 8000 Hz в формате mu-law....

--unique-boundary-2
Content-Type: image/gif
Content-Transfer-Encoding: base64

   ... здесь  находится    кодированное    в    base64    графическое
       изображение....

--unique-boundary-2--

--unique-boundary-1
Content-type: text/richtext

Это текст с разметкой
в соответствии с определением RFC 1341
Неправда ли, он крут?

--unique-boundary-1
Content-Type: message/rfc822

From: (имя отправителя в US-ASCII)
To: (адрес в US-ASCII)
Subject: (subject в US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable

   ... Некоторый текст в ISO-8859-1 ...

--unique-boundary-1--

7.3. Тип ‘message’

При пересылке почты часто возникает необходимость включить внутрь письма другое письмо. Для этого и используется тип ‘message’.

Основной подтип — «rfc822» — не требует параметров в поле Content-Type. Дополнительные подтипы — «partial» и «External-body» — предполагают наличие параметров.

Замечание: Для перенаправляемой и возвращаемой почты можно было бы определить отдельные подтипы, однако, такая почта может пересылаться как multipart-письмо, в котором первая часть содержит некоторую пояснительную текстовую информацию, а другая, имеющая тип ‘message/rfc822’, содержит перенаправляемое/возвращаемое письмо. Подобный способ перенаправления/возвращения почты сохраняет информацию о типе оригинального письма и позволяет ему быть корректно представленным получателю, и поэтому настоятельно рекомендуется.

7.3.1. Основной подтип ‘message/rfc822’

Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей «From», «Subject» и, по крайней мере, одного поля «To».

Не смотря на использование числа «822», тело, имеющее подтип ‘message/rfc822’, может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо ‘message/rfc822’ может быть MIME-письмом.

7.3.2. Подтип ‘message/partial’

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

Для этого подтипа необходимо указание трех параметров:

  1. «id» — уникальный идентификатор, позволяющий обнаружить остальные части послания.
  2. «number» — целое число, означающее номер части послания.
  3. «total» — целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.

Пример: часть 2 3-х частного послания имеет следующие варианты заголовка:

Content-Type: Message/Partial;
     number=2; total=3;
     id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Content-Type: Message/Partial;
     id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
     number=2

Но часть 3 обязательно должна содержать параметр «total»:

Content-Type: Message/Partial;
     number=3; total=3;
     id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Необходимо заметить, что нумерация частей начинается с 1, а не с 0.

Когда подобным образом разбитые части собираются вместе, они образуют полное MIME-письмо, содержимое которого может иметь любой другой тип и, соответственно, свое поле заголовка Content-Type, описывающее этот тип.

Семантика partial-письма должна быть та же, как в обычном письме с содержимым данного типа, а не как в письме, содержащем «внутреннее» письмо. Это позволяет, например, переслать большой аудио-файл ввиде нескольких более мелких, остающихся, тем не менее, видимыми получателю как обычные аудио-письма, а не как вложенные аудио-письма.

При «сборке» таких посланий в пункте назначения должны учитываться следующие правила:

  1. Все поля заголовка части 1, кроме начинающихся с «Content-» и специальных «Message-ID», «Encrypted» и «MIME-Version» должны быть скопированы в заголовок нового (общего) письма.
  2. Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с «Content-«, а также поля «Message-ID», «Encrypted» и «MIME-Version», должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.
  3. Заголовки второй и последующих частей целиком игнорируются.

Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом:

   X-Weird-Header-1: Foo
   From: Bill@host.com
   To: joe@otherhost.com
   Subject: Audio mail
   Message-ID:
   MIME-Version: 1.0
   Content-type: message/partial;
        id="ABC@host.com";
        number=1; total=2

   X-Weird-Header-1: Bar
   X-Weird-Header-2: Hello
   Message-ID:
   MIME-Version: 1.0
   Content-type: audio/basic
   Content-transfer-encoding: base64

... здесь имеет место быть первая часть закодированных аудио-данных ...

А вторая может выглядеть так:

From: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: Content-type: message/partial; id=»ABC@host.com»; number=2; total=2 … здесь имеет место быть вторая часть закодированных аудио-данных …

После того, как расколотое послание воссоздано заново для отображения получателю, оно должно выглядеть следующим образом:

   X-Weird-Header-1: Foo
   From: Bill@host.com
   To: joe@otherhost.com
   Subject: Audio mail
   Message-ID:
   MIME-Version: 1.0
   Content-type: audio/basic
   Content-transfer-encoding: base64

... первая часть закодированных аудио-данных ...
... вторая часть закодированных аудио-данных ...

Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа «message» никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде. Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим «8-бит» и «binary», запрещается их использование для данных message/partial.

Многие почтовые агенты могут автоматически фрагментировать большие письма.

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

Поле заголовка «Encrypted» вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial.

7.3.3. Подтип ‘Message/External-Body’

Этот подтип указывает на то, что тело не содержится в самом письме, а на него есть ссылка. Параметры подтипа описывают способ доступа к данным тела письма.

Письмо (часть письма) этого подтипа состоит из заголовка, двух последовательных концов строки и заголовка вложенного письма. Если встречается другая пара концов строки, она означает конец заголовка вложенного письма. Однако, поскольку тело вложенного письма является внешним, оно не следует за концом заголовка. Например,

Content-type: message/external-body; access-
type=local-file;

     name="/u/nsb/Me.gif"

Content-type:  image/gif
Content-ID:
Content-Transfer-Encoding: binary

ТЕЛА НЕТ!

Область в конце, которую можно назвать «призрачным телом», игнорируется для большинства писем подтипа ‘external-body’. Однако, в нее можно помещать дополнительную информацию, как например, в случае, когда параметр ‘access-type’ равен «mail-server». Во всех остальных случаях призрачное тело игнорируется.

Единственный всегда обязательный параметр для ‘message/external-body’ — «access-type». Остальные параметры могут быть или не быть обязательными в зависимости от значения параметра «access-type».

Значение этого параметра — слово, нечувствительное к регистру букв, означающее механизм доступа, с помощью которого файл или данные могут быть получены. Значения могут быть следующими (но не ограничиваются этим рядом): «FTP», «ANON-FTP», «TFTP», «AFS», «LOCAL-FILE» и «MAIL-SERVER». Будущие возможные значения, кроме экспериментальных, начинающихся с «X-«, должны быть зарегистрированы в IANA.

Дополнительно, следующие три параметра являются необязательными для всех способов доступа:

EXPIRATION — Дата (RFC 822 «date-time» синтаксис допускает 4 цифры в этом поле), после которой существование внешних данных не гарантируется.

SIZE — размер (в байтах) данных. Позволяет получателю решить, расходовать ли ресурсы на считывание внешних данных. Размер указывается для канонической формы данных (то есть, до применения каких-либо преобразований).

PERMISSION — нечувствительное к регистру букв поле, говорящее о том, ожидается или нет, что клиент может перезаписывать данные. По умолчанию или когда этот параметр имеет значение «read», полагается, что клиент не имеет на это права, и что если данные однажды считаны, то больше они не понадобятся. Если PERMISSION имеет значение «read-write», любая локальная копия может рассматриваться не более как кэш. «read» и «write» — единственные предопределенные значения для PERMISSION.

Вложенные заголовки во ВСЕХ телах типа message/external-body ДОЛЖНЫ включать поле заголовка Content-ID для задания уникального идентификатора, указывающего на внешние данные.

Обозначения, описывающие данные типа external-body, такие как имена файлов или команды mail-сервера, должны быть в символьном наборе US-ASCII.

Как и для типа message/partial, тело типа message/external-body должно иметь значение content-transfer-encoding «7-bit» (по умолчанию). В частности, даже в системах, поддержиавющих 8-битный транспорт, применение content-transfer-encoding «8-bit» и «binary» запрещено для данных типа message/external-body.

7.3.3.1. Типы доступа «ftp» и «tftp»

Тип доступа по FTP или TFTP означает, что тело сообщения доступно как внешний файл по протоколу FTP [RFC-959] или TFTP [RFC-783] соответственно. Для этих типов доступа обязательны следующие дополнительные параметры:

NAME — Имя файла, содержащего данные тела письма.

SITE — Полный доменный адрес или псевдоним компьютера, с которого файл может быть получен по указанному протоколу.

Перед тем, как начнется считывание данных по FTP, пользователь обычно должен быть спрошен на предмет логина и пароля для машины, указанной в параметре ‘site’. По причинам безопасности логин и пароль не указываются как параметры Content-Type и должны быть получены от получателя письма.

Дополнительно определены следующие необязательные параметры:

DIRECTORY — каталог, содержащий тело письма на удаленной машине.

MODE — Нечувствительное к регистру букв строка, указывающая режим передачи данных. Допустимые эначения для типа доступа TFTP:

NETASCII, OCTET и MAIL. Для типа доступа FTP: ASCII, EBCDIC, IMAGE и LOCALn, где n — десятичное целое число, обычно 8. Эти значения соответствуют типам представления A, E, I и Ln, определенным FTP-протоколом. Заметьте, что «BINARY» и «TENEX» не являются допустимыми значениями для параметра MODE. Вместо них должны использоваться «OCTET», «IMAGE» или «LOCAL8». Если параметр MODE отсутствует, значением по умолчанию является «NETASCII» для TFTP и «ASCII» для FTP.

7.3.3.2. Способ досупа «anon-ftp»

Этот способ доступа идентичен «ftp», за исключением того, что пользователю не требуется указывать свой логин и пароль для удаленной машины. FTP-протокол будет использоваться с логином «anonymous» и email-адресом получателя вместо пароля.

7.3.3.3. Способы доступа «local-file» и «afs»

Способ доступа «local-file» означает, что тело письма доступно как файл на локальной машине. «afs» означает, что тело доступно как файл через общую файловую систему AFS. В обоих случаях требуется единственный обязательный параметр:

NAME — Имя файла, содержащего данные тела письма.

Следующий необязательный параметр может быть использован для локализации ссылки на файл и содержит адрес сайта или сайтов, на которых данный файл виден:

SITE — Доменный адрес машины или машин, на которых возможен доступ к файлу данных. Допускаются маски с использованием звездочки вместо части доменного имени, например, «*.bellcore.com», для обозначения набора машин, на которых файл виден напрямую. Единственная звездочка вместо всего доменного имени может означать, что файл, где би он ни был, виден через глобальную файловую систему.

7.3.3.4. Способ доступа «mail-server»

Применяется, когда тело письма доступно через почтовый сервер. Обязательный параметр для этого способа доступа:

SERVER — email-адрес mail-сервера, с которого могут быть запрошены данные тела письма.

Так как почтовые серверы предполагают множество различных синтаксисов, некоторые из них могут быть многострочными, полная команда, которую нужно послать на mail-сервер, не включается как параметр в однострочное поле ‘content-type’. Вместо этого она помещается в мнимое тело, когда значением поля ‘content-type’ является ‘message/external-body’, и параметр ‘access-tyoe’ имеет значение ‘mail-server’.

Необязательный параметр для этого способа доступа:

SUBJECT — Subject, который будет использован в заголовке письма-запроса, которое почторый клиент получателя пошлет на указанный почтовый сервер для получения данных тела письма. Заметьте, что помещение адреса сервера в subject не рекомендуется, однако, известны mail-серверы, требующие этого.

MIME-стандарт не определяет синтаксиса обращения к почтовому серверу. Поэтому он допускает включение полной команды для mail-сервера в мнимое тело.

В отличие от других способов доступа, доступ через mail-сервер не синхронен, и данные могут быть получены в непредсказуемый момент в будущем. По этой причине важно иметь механизм, обеспечивающий вставку полученных от mail-сервера данных в исходное письмо. Mail-сервер при отправке запрошенных данных должен использовать то же самое значение поля Content-ID в заголовке письма с возвращаемыми данными, какое было в первоначальном «бестелесном» письме, чтобы облегчить работу этого механизма.

7.3.3.5. Примеры и дополнительные пояснения

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

Если внешнее тела письма доступно посредством нескольких различных механизмов, отправитель может включить несколько частей типа message/external-body в письмо типа multipart/alternative.

Однако, механизм external-body не должен быть ограничен получением удаленных файлов. Например, можно представить использование видеосервера с внешними ссылками на видеофрагменты.

Если письмо / часть письма имеет тип «message/external-body», то оно / она будет содержать поля заголовка вложенного письма. Тело само по себе неходится где-либо во вне. Это значит, что если тело типа «message/external-body» содержит два последовательных конца строки (CRLF), то все, что идет далее, не является чстью сообщения и просто должно игнорироваться. Однако, этот «хвост» — удобное место для каких-либо дополнительных данных, которые не могут быть помещены в поле заголовка Content-Type. В частности, если значение «access-type» есть «mail-server», то «хвост» может содержать команды, посылаемые затем mail-серверу по адресу, на который указывает параметр SERVER.

Поля заголовка вложенного письма, которые на самом деле являются телом общего письма типа «message/external-body», должны нести информацию о типе содержимого внешнего (удаленного) тела, если оно не является простым ASCII-текстом (что подразумевается по умолчанию), поскольку эти внешние данные сами по себе не имеют заголовка, опрпеделяющего их тип. Также, необходимо указывать Content-transfer-encoding, если он имеет значение, отличное от «7-bit». Так, полное письмо типа message/external-body, ссылающееся на документ в формате PostScript, может выглядеть следующим образом:

From: Whomever
To: Someone
Subject: whatever
MIME-Version: 1.0
Message-ID:
Content-Type: multipart/alternative; boundary=42
Content-ID:

--42
Content-Type: message/external-body;
     name="BodyFormats.ps";
     site="thumper.bellcore.com";
     access-type=ANON-FTP;
     directory="pub";
     mode="image";
     expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID:

--42
Content-Type: message/external-body;
     name="/u/nsb/writing/rfcs/RFC-MIME.ps";
     site="thumper.bellcore.com";
     access-type=AFS
     expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID:

--42
Content-Type: message/external-body;
     access-type=mail-server
     server="listserv@bogus.bitnet";
     expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID:

get RFC-MIME.DOC

--42--

В приведенных примерах значение Content-transfer-encoding для внешних данных в формате postscript полагается по умолчанию как «7bit».

Заголовки общего и вложенного(их) писем (имеющих внешнее тело) должны удовлетворять тем же правилам, что и для типа message/partial во избежание путаницы.

Поскольку внешнее тело не пересылается в виде почты, то оно не обязано удовлетворять требованиям длины строк и иметь 7-битную форму, оно может быть просто бинарным файлом. Поэтому поле Content-Transfer-Encoding не является необходимым, хотя его наличие допускается.

Тело письма типа «message/external-body» обрабатывается в сответствии с основным синтаксисом стандарта RFC 822, в частности, все, что идет до первой последовательной пары концов строки (CRLF), является заголовком письма, а все, что идет после, является «мнимым» телом письма, которое игнорируется для большинства типов доступа.

Формальный синтаксис поля заголовка ‘content-type’ для данных типа ‘message’ — следующий:

message_тип := "message" "/" message_подтип

message_подтип := "rfc822"
                / "partial" 2-3 partial_параметра
                / "external-body" 1 external_параметр
                / расширение (не предопределенный подтип)

partial_параметр := (";" "id" "=" значение)
                 /  (";" "number" "=" 1*ЦИФРА)
                 /  (";" "total" "=" 1*ЦИФРА)
; id и number требуются всегда; total требуется для последнего  фрагмен-
; та послания.

external_параметр := (";" "access-type" "=" тип_доступа)
                   / (";" "expiration" "=" дата-время)
             ; Дата-время должны быть экранированы кавычками
                   / (";" "size" "=" 1*Цифра)
                   / (";"  "permission"  "="  ("read"  /  "read-write"))
             ; Значение permission нечувствительно к регистру букв
                   / (";" "name" "=" значение)
                   / (";" "site" "=" значение)
                   / (";" "dir" "=" значение)
                   / (";" "mode" "=" значение)
                   / (";" "server" "=" значение)
                   / (";" "subject" "=" значение)
; access-type требуется всегда; все остальное — в зависимости от  значе-
; ния access-type

тип_доступа := "ftp" / "anon-ftp" / "tftp" / "local-file"
               / "afs" / "mail-server" /
               / расширение (непредопределенный параметр)
; Нечувствителен к регистру букв

7.4. Тип ‘Application’

Этот тип используется для данных, неподпадающих под остальные категории, в частности, для данных, обрабатываемых прикладными почтовыми программами. Это информация, которая должна быть обработана соответствующим приложением для того, чтобы принять наглядную либо исполняемую для получателя форму. Предполагаемое использование для этого типа включает в себя пересылку файлов по почте, таблицы, данные для почтовых систем расписания, языки для «активной» (вычислительной) почты. (Последняя, в частности, может поднять проблемы безопасности, которые должны быть поняты разработчиками ПО и рассмотрены ниже в параграфе «Application/PostScript»).

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

Подобные приложения могут быть определены как подтипы для типа «application». Изначально предопределено два подтипа: «octet-stream» и «PostScript».

В общем, подтип для ‘application’ зачастую может быть именем приложения, для которого предназначены пересылаемые данные. Однако, это не означает, что любое имя прикладной программы может свободно использоваться как подтип для ‘application’. Такие употребления (кроме подтипов, начинающихся с «x-«) должны быть зарегестрированы в IANA.

7.4.1. Основной подтип ‘Application/Octet-Stream’

Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):

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

PADDING — число заполняющих битов, добавленных к битовому потоку, содержащему данные, для формирования байтно-ориентированных данных. Полезно при заключении в тело битового потока, когда общее число битов не кратно восьми, то есть, размеру байта.

Дополнительный параметр, «conversions», определенный в [RFC-1341], был исключен в последствии.

В RFC 1341 также определен параметр «NAME», указывающего имя файла, которое должно быть использовано при сохранении данных на диск. Но он опять же был отменен в ожидании введения отдельного поля заголовка Content-Disposition, которое будет определено в ближайшем будущем.

Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, — просто предложить записать данные в файл без какого-либо преобразования, или. возможно, произвести его в соответствии с указанием пользователя.

Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля «Content-Type» (например, в параметре «interpreter=»), использующей в качестве входных данных тело письма.

7.4.2. Подтип ‘Application/PostScript’

Тип «application/postscript» означает, что пересылается PostScript-документ и требует специальной программы для его обработки. В настоящий момент используются два языка — level 1 и более поздний — level 2.

PostScript-документы представляют собой интерпретируемые программы, которые могут содержать операторы обращения к диску и действий с файлами. Поэтому PostScript-документы представляют потенциальную опасность для системы получателя.

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

7.4.3. Другие подтипы типа Application

Ожидается, что многие подтипы типа ‘Application’ будут введены в будущем. MIME-совместимые почтовые программы должны интерпретировать любой незнакомый им подтип как эквивалент ‘application/octet-stream’.

Формальный синтаксис дла поля ‘content-type’ для данных типа ‘application’ дается следующим образом.

application_тип :=  "application" "/" application_подтип

application_подтип := ("octet-stream" *stream_параметр)
                    / "postscript" / расширение (непредопределенный под-
                    тип)

stream_параметр :=  (";" "type" "=" значение)
                    / (";" "padding" "=" число_дополняющих_битов)

число_дополняющих_битов := "0" / "1" /  "2" /  "3" / "4" / "5" / "6" /
                           / "7"

7.5. Тип ‘Image’

Этот тип означает, что тело письма содержит графический объект. Его подтипы соответствуют конкретным графическим форматам. Их значения нечувствительны к регистру букв. Два предопределенных подтипа — «jpeg» для формата JPEG с кодированием JFIF, и «gif» — для формата GIF.

Формальный синтаксис поля ‘Content-Type’:

image_тип := "image" "/" ("gif" / "jpeg" / подтип-расширение)

7.6. Тип ‘Audio’

Этот подтип означает, что тело содержит аудио-данные. Хотя пока еще нет консенсуса по «идеальному» аудио-формату для компьютеров, сейчас имеется сильная потребность в универсальном формате.

Предопределенный подтип — «basic» введен в ответ на это требование, обеспечивая минимальный примитивный аудио-формат. Ожидается определение в дальнейшем более «богатых» форматов, обеспечивающих более высокое качество воспроизведения.

Содержимое тела, имеющего подтип «audio/basic», — аудио-данные в 8-битной форме, кодированные с использованием ISDN mu-law. Формат, соответствующий этому подтипу, предполагает максимальную частоту звучания 8000 Hz и единственный канал.

Формальный синтаксис для поля ‘Content-Type’:

audio_тип := "audio" "/" ("basic" / подтип-расширение)

7.7. Тип ‘Video’

Этот тип означает, что в теле письма содержится анимационное изображение, возможно, со звуком и цветом. Термин «video» используется безотносительно к технологии получения подвижного во времени изображения. Подтип «mpeg» указывает на видео, кодированное в соответствии со стандартом MPEG.

Хотя MIME-стандарт запрещает смешение разнородных мультимедийных данных в одном теле (письма или части письма), многие так называемые «video»-форматы включают синхронизированный звук, что допускается для подтипов типа «video».

Формальный синтаксис для поля ‘Content-Type’:

video-type := "video" "/" ("mpeg" / подтип-расширение)

7.8. Экспериментальные значения поля ‘Content-Type’

Значение типа, начинающееся с «X-«, считается частным, предназначенным для использования по договоренности между двумя или более почтовыми системами. Публично определенные (регестрированные) значения никогда не должны начинаться с префикса «X-«.

В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.

Все определенные на сегодняшний день типы и подтипы

text multipart message application image audio video
plain mixed rfc822 octet-stream jpeg basic mpeg
richtext alternative partial postscript gif quicktime
enriched digest external-body oda ief
tab-separated-values parallel news atomicmail tiff
appledouble andrew-inset
header-set slate
wita
dec-dx
dca-rft
activemessage
rtf
applefile
mac-binhex40
news-message-id
news-transmission
wordperfect5.1
pdf
zip
macwriteii
msword
remote-printing

Значения полей Content-Type и subtype, а также другие параметры заголовка являются чувствительными к регистру букв, если только не оговорены исключения для конкретного значения параметра.

II. Применение возможностей MIME в транспортных почтовых системах

Хотя новые возможности, предоставляемые MIME, ориентированы в основном на пользовательские почтовые программы, однако, транспортные системы тоже могут воспользоваться преимуществами MIME.

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

Чтобы заниматься реализацией любого из механизмов, описанных ниже, необходимо ознакомиться с отличием между службой почтового транспорта и шлюзовой службой. В основном, почтовый транспорт ответственен за перемещение почтовых сообщений в пределах пространства почтовых сетей, подобных друг другу. С другой стороны, почтовые шлюзы совершают обмен почтой между двумя принципиально отличными почтовыми пространствами, в том числе и через неэлекторнные службы (как бумажная почта, например).

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

II.1. Непринятая почта

К сожалению частой обязанностью транспортных служб является отсылка почты обратно отправителю. Такое может произойти, если почту невозможно доставить или если она не удовлетворяет требованиям шлюза (слишком большой объем, например).

Раньше не было стандартных правил для отказа от принятия почтовых сообщений. Это было досадной, но не главной проблемой для текстовых сообщений. Для нетекстовых, однако, недостаток в стандартном формате отказа от приема является более критичным, потому что типично возвращенные пиьсма представляются их отправителю как текст, и пользователь, просматривающий картинку или звук, как если бы они были текстом, редко бывает счастлив от этого.

MIME позволяет легко инкапсулировать письма в том смысле, что полностью сохраняется их семантика. Простейший путь добиться этого — каждое возвращаемое письмо помещать в тело письма с типом «multipart/mixed», которое содержало бы две части — текстовую, содержащую пояснение причины отказа в принятии оригинального письма и вложение самого этого письма.

Подчеркивается, что транспорные программы вообще не нуждаются в распознавании структуры возвращаемого письма. От них лишь требуется правильно вложить его. Следующий пример показывает, как любое MIME-письмо может быть вложено (инкапсулировано) в письмо возврата так, что вся информация в нем будет корректно воспроизведена, если получатель (он же первый отправитель) будет читать его с помощью MIME-ориентированной почтовой программы:

From: Mailer-Daemon
Subject: Rejected Message
Content-type: multipart/mixed; boundary=unique-boundary

--unique-boundary
Content-type: text/plain; charset=us-ascii

Посланное Вами письмо не принято. Детали отказа следующие:

From: Nathainel Borenstein
Message-ID: <12345@bellcore.com>
To: bush@whitehouse.gov
Subject: I know my rights!
Rejection-reason: Прием почты из Вашей организации  запре-
    щен.

Оригинальное письмо прилагается ниже.
--unique-boundary
Content-type: message/rfc822

Здесь находится ВОЗВРЩАЕМОЕ ПИСЬМО  ПОЛНОСТЬЮ,  начиная  с
заголовка.

--unique-boundary--

В данном примере единственная вещь, которая не берется из стандартного набора фраз, это выбор метки границы. Фраза «unique-boundary» должна быть заменена строкой, не появляющейся ни в одной из частей сообщения.

ВАЖНО: Формат, приведенный выше, — лишь один из возможных путей отсылки непринятых писем с использованием MIME.

II.2. Разбиение (фрагментация) и сборка больших писем

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

В частности, к ним относится MIME-тип «message/partial», который можно использовать для автоматического разбиения и сборки больших писем. Эта функция может поддерживаться полностью как на уровне пользовательских почтовых агентов, так и транспортными службами, которые могут его использовать для обеспечения полее разумного поведения при шлюзовании почты.

Ниже приводится пример, показывающий, как простое коротенькое письмо может быть разбито на два письма типа «message/partial». На практике, конечно, данное свойство разумно применять лишь для очень больших писем.

Первоначальное письмо:

From:  Nathaniel Borenstein
To: Ned Freed:
Subject: a test message
Content-type: image/gif
Content-Transfer-Encoding: base64

R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M

может быть обратимо преобразовано в следующие два message/partial- -письма:

From:  Nathaniel Borenstein


To: Ned Freed
Subject: a test message
Content-type: message/partial; id="xyx@host.com";
     number=1; total=2

Content-type: image/gif
Content-Transfer-Encoding: base64

R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV

и

From:  Nathaniel Borenstein
To: Ned Freed
Subject: a test message
Content-type: message/partial; id="xyx@host.com";
     number=2; total=2

uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M

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

Фрагментирование и сборка писем могут быть выполнены, в зависимости от обстоятелств, как отправляющей, так и принимающей системой, в зависимости от того, какая из них знает больше о способностях другой.

II.3. Использование или удаление указателей External-Body (внешнего тела)

Другой MIME-тип, ориентированный на слишком большие письма, это «message/external-body». Он обеспечивает почтовым транспортным службам, оптимизировать почтовый траффик в своей системе. Однако, когда почта пересекает медленный и дорогой участок, например, звено спутниковой связи через Тихий океан, может иметь смысл считать указываемые данные и передать их в качестве действительного тела письма, либо скопировать в новое, более доступное место, соответствующим образом изменив ссылку в заголовке письма. Поскольку спецификация данного типа допускает наличие даты аннулирования ресурса, почтовый транспорт может идти на компромисс между пропускной способностью своей системы и ее дисковым пространством, отданным под хранение внешних данных писем, чтобы оптимизировать использование этих внешних данных.

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

Например, приведенное ниже письмо содержит ссылку на внешние PostScript-данные:

From:  Nathaniel Borenstein
To: Ned Freed
Subject: The latest MIME draft
Content-Type: message/external-body;
     name="BodyFormats.ps";
     site="thumper.bellcore.com";
     access-type=ANON-FTP;
     directory="pub";
     mode="image";
     expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript

Шлюз в Австралию может выбрать — скопировать ли файл в какой-либо австралийский FTP-архив, изменив соответствующие параметры в заголовке письма, или оставить все без изменений, или считать данные и вложить их в письмо целиком:

From:  Nathaniel Borenstein
To: Ned Freed
Subject: The latest MIME draft
Content-type: application/postscript

%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
274,4270,9938586,21462)
и так далее...

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

Кроме того, вместо замены ссылки на внешние данные их натуральным включением в письмо, можно трансформировать оригинальное письмо в письмо типа «multipart/alternative», содержащее как ссылку на внешние данные, так и копию этих данных. Это означает, что при перенаправлении письма другому пользователю перенаправлена будет только та часть, которая содержит ссылку. Кроме того, получатель, хоть и получит данные сразу целиком, все равно не потеряет информацию о местоположении оригинального ресурса, и при необходимости сможет скачать более новую его версию в будущем. Это иллюстрируется следующим примером:

From:  Nathaniel Borenstein
To: Ned Freed
Subject: The latest MIME draft
Content-type: multipart/alternative; boundary=foo

--foo
Content-Type: message/external-body;
     name="BodyFormats.ps";
     site="thumper.bellcore.com";
     access-type=ANON-FTP;
     directory="pub";
     mode="image";
     expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
--foo
Content-type: application/postscript

%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
274,4270,9938586,21462)
etc...
--foo--

Аналогично, в случае, когда внешние данные копируются транспортной системой на локальный FTP, можно сделать в письме две части типа ‘external-body’, что позволит получателю выбрать, с какого из FTP предпочтительнее забирать тело письма.

II.4. Преобразование графических и других форматов

В настоящее время MIME определяет два графических формата — image/gif и image/jpeg. Первый — более удобен для многих пользователей, понятен многим системам, и отображается довольно быстро. Последний гораздо более компактен и потому менее сказывается на увеличении траффика.

Почтовые транспортные системы могут оптимизировать и траффик, и удобства получателей разумной трансляцией этих форматов (а также других, которые могут быть добавлены в будущем). Если письмо типа image/gif пересылается на длинную дистанцию, оно может быть перетранслировано в image/jpeg. Когда же данные типа image/jpeg получены системой, в которой находится получатель, для конечной доставки, они снова могут быть перетранслированы в GIF для удобств получателя.

Подобные преобразования форматов также рекомендуются и для аудио-данных.

Если преобразование выполнено, настоятельно рекомендуется добавлять каким-либо образом (например, в поле заголовка Received) информацию об истории преобразований документа, в письме содержащегося.

Однако, трансляция форматов обычно ограничивается шлюзовыми службами и менее предпочтительна для обычных транспортных служб. Причем, те службы, которые выполняют преобразования, должны распознавать поле Conterent-Conversion, в котором отправитель может разрешить либо запретить любые преобразования форматов данных, поскольку многие пользователи принципиально неприемлют преобразования, так как считают, что при некоторые из них могут привести к ухудшению качества документа:

Content-Conversion: prohibited

или:

Content-Conversion: permitted

По умолчанию (если это поле отсутствует) предполагается значение ‘permitted’.

II.5. Надежное кодирование данных

В некоторых случаях при прохождении через шлюз данные могут не сохранить своего вида к следующему шагу транспортировки. К примеру, почта проходящая через шлюз ASCII -> EBCDIC, может потерять информацию, содержащую некоторые спецсимволы. В подобных случаях шлюз может обеспечить данным сохранность, применив один из MIME-алгоритмов — base64 или quoted-printable к телу письма или его части. Это, как правило, трансформация без потерь, но необходимо добиться, чтобы результирующее письмо целиком отвечало стандарту MIME, даже если изначально оно таковым не было (в частности, должно быть добавлено поле заголовка MIME-Version).

Ссылки

[US-ASCII] Coded Character Set — 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[ATK] Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, Prentice-Hall, 1990.
[GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc., Columbus, Ohio, 1990.
[ISO-2022] International Standard — Information Processing — ISO 7-bit and 8-bit coded character sets — Code extension techniques, ISO 2022:1986.
[ISO-8859] Information Processing — 8-bit Single-Byte Coded Graphic Character Sets — Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
[ISO-646] International Standard — Information Processing — ISO 7-bit coded character set for information interchange, ISO 646:1983.
[MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.
[PCM] CCITT, Fascicle III.4 — Recommendation G.711, Geneva, 1972, «Pulse Code Modulation (PCM) of Voice Frequencies».
[POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985.
[POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Edition, 1990.
[X400] Schicker, Pietro, «Message Handling Systems, X.400», Message Handling Systems and Distributed Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.
[RFC-783] Sollins, K., «TFTP Protocol (revision 2)», RFC 783, MIT, Июнь 1981.
[RFC-821] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 821, USC/Information Sciences Institute, Август 1982.
[RFC-822] Crocker, D., «Standard for the Format of ARPA Internet Text Messages», STD 11, RFC 822, UDEL, Август 1982.
[RFC-934] Rose, M., and E. Stefferud, «Proposed Standard for Message Encapsulation», RFC 934, Delaware and NMA, Январь 1985.
[RFC-959] Postel, J. и J. Reynolds, «File Transfer Protocol», STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
[RFC-1049] Sirbu, M., «Content-Type Header Field for Internet Messages», STD 11, RFC 1049, CMU, Март 1988.
[RFC-1421] Linn, J., «Privacy Enhancement for Internet Electronic Mail: Part I — Message Encryption and Authentication Procedures», RFC 1421, IAB IRTF PSRG, IETF PEM WG, Февраль 1993.
[RFC-1154] Robinson, D. и R. Ullmann, «Encoding Header Field for Internet Messages», RFC 1154, Prime Computer, Inc., Апрель 1990.
[RFC-1341] Borenstein, N., and N. Freed, «MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies», RFC 1341, Bellcore, Innosoft, Июнь 1992.
[RFC-1342] Moore, K., «Representation of Non-Ascii Text in Internet Message Headers», RFC 1342, University of Tennessee, Июнь 1992.
[RFC-1343] Borenstein, N., «A User Agent Configuration Mechanism for Multimedia Mail Format Information», RFC 1343, Bellcore, Июнь 1992.
[RFC-1344] Borenstein, N., «Implications of MIME for Internet Mail Gateways», RFC 1344, Bellcore, Июнь 1992.
[RFC-1345] Simonsen, K., «Character Mnemonics & Character Sets», RFC 1345, Rationel Almen Planlaegning, Июнь 1992.
[RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and D. Crocker, «SMTP Service Extension for 8bit-MIME transport», RFC 1426, United Nations Universit, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, Февраль 1993.
[RFC-1522] Moore, K., «Representation of Non-Ascii Text in Internet Message Headers» RFC 1522, University of Tennessee, Сентябрь 1993.
[RFC-1340] Reynolds, J., and J. Postel, «Assigned Numbers», STD 2, RFC 1340, USC/Information Sciences Institute, Июль 1992.