Протокол IP, Протоколи, Інтернет-технології, статті

Радик Усманов, www.free.net

Реферат: Документ містить російський переклад специфікації мережного протоколу IP
(Internet Protocol) – Основного протоколу міжнародної комп’ютерної мережі
Internet. Оригінальний документ відомий, як
RFC791.

Примітки редактора

Оригінальна версія документа RFC791 розміщується на сервері ISI
(Information Sciences Institute):


URL – info.internet.isi.edu/in-notes/rfc/files/rfc791.txt

  RFC 791 Internet протокол   Проект Darpa Internet   Специфікація протоколу   Вересень 1981
приготовлено для Агенства розширених оборонних дослідницьких проектів Офіс технологій обробки інформації
1400 Wilson Boulevard
Arlington, Virginia 22209
Інститутом Інформатики Університету Південної Кароліни
4676 Admiralty Way
Marina del Rey, California 90291

Зміст Передмова 1. Введення 1.1 Обгрунтування 1.2 Мета 1.3 Інтерфейси 1.4 Дія 2. Огляд 2.1 Зв’язок з іншими протоколами 2.2 Сценарій роботи 2.3 Опис функцій 2.4 Шлюзи 3. Специфікація 3.1 Формат заголовка Internet 3.2 Обговорення 3.3 Інтерфейси Додаток А: Приклади і сценарії Додаток Б: Порядок передачі даних Тлумачний словник Посилання
Передмова Даний документ встановлює Internet протокол в стандарті DOD. Він заснований на шести попередніх версіях специфікації протоколу ARPA Internet, і з них в значній мірі запозичений його текст. Разом з тим в цю роботу внесено багато змін, що стосуються як термінології, так і власне викладу матеріалу. Це видання висвітлює адресацію, обробку помилок, коди опцій, а також безапасность, історію і підтримку властивостей протоколу Internet. Джон Постел (Jon Postel) Редактор
Протокол Internet Програма DARPA Internet Специфікація протоколу
1. Введення 1.1 Обгрунтування Протокол Internet створений для використання в об’єднаних системах комп’ютерних комунікаційних мереж з комутацією пакетів. Такі системи були названі “catenet” [1]. Протокол Internet забезпечує передачу блоків даних, називаних датаграми, від відправника до одержувачам, де відправники та одержувачі є хост-комп’ютерами, ідентифікованими адресами фіксованої довжини. Протокол Internet забезпечує при необхідності також фрагментацію і складання датаграм для передачі даних через мережі з малим розміром пакетів.
1.2 Мета Протокол Internet спеціально обмежений задачами забезпечення функцій, необхідних для передачі бітового пакета (датаграми Internet) від відправника до одержувача через об’єднану систему комп’ютерних мереж. Немає механізмів для збільшення вірогідності кінцевих даних, управління протоколом, синхронізації або інших послуг, зазвичай пріненяемих в протоколах передачі від хоста до хосту. Протокол Ineternet може узагальнити послуги підтримуючих його мереж з метою надання послуг різних типів і якостей.
1.3 Інтерфейси Даний протокол отримав назву відповідно до протоколів передачі інформації між хост-комп’ютерами в міжмережевий середовищі. Протокол викликає в локальній мережі протоколи для передачі датаграми Internet на наступний шлюз або хост-одержувач. Наприклад, модуль TCP викликав би модуль Internet з тим, щоб отримати сегмент TCP (включаючи заголовок TCP і дані користувача) як інформаційну частину Internet пакета. Модуль TCP забезпечив би адреси та інші параметри в заголовку модуля Internet в якості параметрів розглянутого виклику. Модуль Internet в цьому випадку створив би датаграму Internet і вдався б до послуг локальної мережі для передачі датаграми Internet. Наприклад, у випадку мережі ARPANET модуль Ineternet викликав би локальний мережевий модуль, який би додавав до датаграм Internet провідник типу 1822 [2], створюючи повідомлення ARPANET для передачі на IMP. Адреса ARPANET вийшов би з адреси Intenet за допомогою інтерфейсу локальної мережі і ставився б до деякого хост-комп’ютера в мережі ARPANET, який міг би бути шлюзом в інші мережі.
1.4 Дія Протокол Internet виконує дві головні функції: адресацію і фрагментацію. Модулі Internet використовують адреси, вміщені в заголовок Internet, для передачі Internet датаграм їх одержувачам. Вибір шляху передачі називається маршрутизацією. Модулі Internet використовують поля в заголовку Internet для фрагментації і відновлення датаграм Internet, коли це необхідно для їх передачі через мережі з малим розміром пакетів. Сценарій дії полягає в тому, що модуль Internet змінює розмір на кожному з хостів, задіяних в internet-комунікації і на кожному з шлюзів, які забезпечують взаємодію між мережами. Ці модулі дотримуються загальних правил для інтерпретації полів адрес, для фрагментації і збірки Internet датаграм. Крім цього, дані модулі (і особливо шлюзи) мають процедури для прийняття рішень про маршрутизації, а також інші функції. Протокол Internet обробляє кожну Internet датаграму як незалежну одиницю, не має зв’язку ні з якими іншими датаграм Internet. Протокол не має справу ні з сполуками, ні з логічними ланцюжками (віртуальними або будь-якими іншими). Протокол Internet використовує чотири ключових механізму для формування своїх послуг: завдання типу сервісу, часу життя, опцій і контрольної суми заголовка. Тип обслуговування використовується для позначення необхідної послуги. Тип обслуговування – це абстрактний або узагальнений набір параметрів, який характеризує набір послуг, що надаються мережами, і складових власне протокол Internet. Цей спосіб позначення послуг повинен використовуватися шлюзами для вибору робочих параметрів передачі в конкретної мережі, для вибору мережі, використовуваної при наступному переході датаграми, для вибору наступного шлюзу при маршрутизації мережевої Internet датаграми. Механізм часу життя служить для вказівки верхньої межі часу життя Internet датаграми. Цей параметр встановлюється відправником датаграми і зменшується в кожній точці на прохідному датаграммой маршруті. Якщо параметр часу життя стане нульовим до того, як Internet датаграма досягне одержувача, ця датаграма буде знищена. Час життя можна розглядати як годинниковий механізм самознищення. Механізм опцій надає функції управління, які є необхідними або просто корисними при певних ситуаціях, проте він непотрібний при звичайних коммінікаціях. Механізм опцій надає такі можливості, як тимчасові штампи, безпека, спеціальна маршрутизація. Контрольна сума заголовка забезпечує перевірку того, що інформація, яка використовується для обробки датаграм Internet, передана правильно. Дані можуть містити помилки. Якщо контрольна сума невірна, то Internet датаграма буде зруйнована, як тільки помилка буде виявлена. Протокол Internet не забезпечує надійності комунікації. Не має механізму підтверджень ні між відправником та одержувачем, ні між хост-комп’ютерами. Не мається контролю помилок для поля даних, тільки контрольна сума для заголовка. Не підтримується повторна передача, немає управління потоком. Виявлені помилки можуть бути оголошені за допомогою протоколу ICMP (Internet Control Message Protocol) [3], який підтримується модулем Internet протоколу.

2. Огляд 2.1 Зв’язок з іншими протоколами Наступна діаграма ілюструє місце протоколу Internet в ієрархії протоколів.
+——+ +—–+ +——+ +—–+
|Telnet| | FTP | | TFTP | … | … |
+——+ +—–+ +——+ +—–+
| | | |
+—–+ +—–+ +—–+
| TCP | | UDP | … | … |
+—–+ +—–+ +—–+
| | |
+————————–+
| Internet Protocol & ICMP |
+————————–+
|
+————————+
| Local Network Protocol |
+————————+
Рис. 1 Взаємодія протоколів Протокол Internet взаємодіє з одного боку з протоколами передачі інформації між хост-комп’ютерами, а з іншого – з протоколами локальної комп’ютерної мережі. При цьому локальна мережа може бути малої комп’ютерною мережею, що бере участь у створенні великої мережі, такий як
ARPANET.
2.2 Сценарій роботи Схему дій для передачі датаграми від однієї прикладної програми до іншої можна проілюструвати наступним чином: Припустимо, що перенесення буде включати проходження одного проміжного шлюзу. Відправляє прикладна програма готує свої дані і викликає свій локальний Internet модуль для відправки цих даних як датаграми, а в якості аргументів цього виклику передає адресу одержувача та інші параметри. Модуль Internet готує заголовок датаграми і стикується з ним дані. Модуль Internet визначає локальний мережевий адресу, відповідний даною адресою Internet. В даному випадку це адреса шлюзу. Модуль передає дану датаграму та адресу в локальній мережі в розпорядження інтерфейсу локальної мережі. Інтерфейс локальної мережі створює відповідний цієї мережі заголовок і з’єднує з ним датаграму. Потім він передає по локальній мережі отриманий таким чином результат. Датаграма досягає хост-комп’ютер, який грає роль шлюзу і розташований у вершині мережі. Інтерфейс локальної мережі відокремлює цей заголовок і передає датаграму на модуль Internet. Модуль Internet визначає з Internet адреси, що датаграма повинна бути спрямована на хост-комп’ютер у другій мережі. Модуль Internet визначає адресу хоста-одержувача в локальній мережі. Він звертається до інтерфейсу локальної мережі з тим, щоб вона переслала цю датаграму за призначенням. Інтерфейс створює заголовок локальної мережі і з’єднує з ним датаграму, а потім результат на спрямовувати на хост-одержувач. На хості-одержувача інтерфейс локальної мережі удалает заголовок локальної мережі і передає залишився на Internet модуль. Модуль Internet визначає, що розглянута вище датаграма призначена для прикладної програми на цей хості. Модуль передає дані прикладної програмі у відповідь на системний виклик. В якості результату цього виклику передаються адресу одержувача та інші параметри.
прикладна програма прикладна програма
\ / модуль Internet модуль Internet модуль Internet
\ / \ /
LNI-1 LNI-1 LNI-2 LNI2
\ / \ / локальна мережа 1 локальна мережа 2
Рис. 2 Шлях передачі датаграми
2.3 Опис функцій Функція або мета протоколу Internet полягає в передачі датаграми через набір об’єднаних комп’ютерних мереж. Це здійснюється за допомогою передачі датаграм від одного модуля Internet до іншого до тих пір, поки не буде досягнутий одержувач. Модулі Internet знаходяться на хостах і шлюзах системи Internet. Датаграми прямують з одного модуля Internet на інший через конкретні комп’ютерні мережі, засновані на інтерпретації Internet адрес. Таким чином, одним з важливих механізмів протоколу Internet є Internet адресу. При передачі повідомлень з одного Internet модуля на інший датаграми можуть мати потребу в проходженні через мережі, для яких максимальний розмір пакета менше, ніж розмір датаграми. Щоб подолати цю складність, в протокол Internet включений механізм фрагментації. Адресація. У протоколі зроблено розмежування між іменами, адресами і маршрутами [4]. Ім’я показує шуканий нами об’єкт. Адреса показує його місцезнаходження. Internet має справу з адресами. Переклад імен в адреси є завданням протоколів більш високого рівня (прикладних програм або протоколів передачі синхронізації з хоста на хост). Власне модуль Internet здійснює відображення адрес Internet на адреси локальної мережі. Створення карти адрес локальної мережі для отримання маршрутів – завдання процедур нижчого рівня (процедур локальної мережі або шлюзів). Адреси мають фіксовану довжину чотирма октету (32 біта). Адреса починається з мережевого номера, за яким слід локальну адресу (Званий полем залишку “rest”). Існують три формати або класу адрес Internet. У класі a найстарший біт нульовий. Наступні 7 біт визначають мережу. а останні 24 біта – локальний адресу. У класі b самі старші два біти дорівнюють відповідно 1 і 0, наступні 14 біт визначають мережу, а останні 16 біт – локальний адресу. У класі c три самих старших біта рівні відповідно 1,1 і 0, наступні 21 біт визначають мережу, а останні 8 біт – локальний адресу. При відображенні карти Internet адрес на адреси локальної мережі слід дотримуватися обережності. Одиничний хост-комп’ютер повинен вміти працювати так, як якщо б на його місці існувало кілька окремих хост-комп’ютерів для використання кількох адрес Internet. Деякі хост-комп’ютери будуть також мати кілька фізичних інтерфейсів (multi-homing). Таким чином, слід забезпечити кожен хост-комп’ютер кількома фізичними мережевими інтерфейсами, що мають по кілька логічних адрес Internet. Приклади побудови карти адрес можна знайти в документі “Address
Mapping” [5]. Фрагментація. Фрагментація Internet датаграми необхідна, коли ця датаграма виникає в локальній мережі, що дозволяє працювати з пакетами великого розміру, і потім повинна пройти до одержувача через іншу локальну мережу, яка обмежує пакети меншим розміром. Internet датаграма може бути позначена як нефрагментіруемая. Будь Internet датаграма, позначений таким чином, не може бути фрагментована модулем Internet ні за яких умов. Якщо ж Internet датаграма, позначена як нефрагментіруемая, тим не менше не може досягти одержувача без фрагментації, то замість цього вона буде зруйнована. Фрагментація, перенесення та збирання в локальній мережі, невидимі для модуля Internet протоколу, називаються внутрішньо-фрагментацією і можуть бути завжди використані [6]. Необхідно, щоб Internet процедури фрагментації і збірки могли розбивати датаграму на майже будь-яку кількість частин, які згодом могли б бути знову зібрані. Одержувач фрагмента використовує поле ідентифікації для того, щоб бути переконаним в тому, що фрагменти різних датаграм не будуть переплутані. Поле зсуву фрагмента повідомляє одержувачеві положення фрагмента в вихідної датаграм. Зсув фрагмента і довжина визначають шматок вихідної датаграми, принесений цим фрагментом. Прапор “more fragments” показує (За допомогою перезавантаження) поява останнього фрагмента. Ці поля дають достатню кількість інформації для складання датаграм. Поле ідентифікації дозволяє відрізнити фрагменти однієї датаграми від фрагментів інший. Модуль Internet, що відправляє Internet датаграму, встановлює в поле ідентифікації значення, яке має бути унікальним для даної пари відправник – одержувач, а також час, в перебігу якого датаграма буде активне в системі Internet. Модуль протоколу, що відправляє нерозчленовану датаграму, встановлює в нуль прапор “more fragments” і зсув у фрагменті. Щоб розчленувати велику Internet датаграму, модуль протоколу Internet (наприклад, шлюз), створює дві нові Intenet датаграми і копіює вміст полів Internet заголовка з великої датаграми в обидва нових Internet заголовка. Дані зі старої датаграми діляться на дві частини по межі на черговому восьмому октеті (64 біта). Отримана таким чином друга частина може бути кратна 8 октетам, а може і не бути, але перша частина кратна завжди. Замовляється кількість блоків першої частини NFB (кількість блоків фрагмента). Перша частина даних поміщається в Першими нову Internet датаграму, в поле загальної довжини поміщається довжина перший датаграми. Прапор “more fragments” встановлюється в одиницю. Друга частина даних поміщається в другу новостворену Internet датаграму, в поле загальної довжини заноситься довжина другий датаграми. В поле зсуву фрагмента в другій Internet датаграм встановлюється значення такого ж поля у вихідній великий датаграм, збільшене на
NFB. Ця процедура може бути узагальнена на випадок багаторазового розщеплення вихідної датаграми. Щоб зібрати фрагменти Internet датаграми, модуль протоколу Internet (наприклад, модуль на хост-комп’ютері) об’єднує Internet датаграми, що мають однакові значення в полях ідентифікатора, відправника, одержувача та протоколу. Власне об’єднання полягає в приміщенні даних з кожного фрагмента в позицію, зазначену в заголовку Internet пакета в поле “fragment offset”. Перший фрагмент буде мати в поле “fragment offset” нульове значення, а останній фрагмент буде мати прапор “more fragments”, знову встановлений в нуль.
2.4 Шлюзи За допомогою шлюзів протокол Internet здійснює передачу датаграм між мережами. Шлюзи також підтримують протокол шлюз-шлюз (GGR) [7] для координації маршрутизації і передачі іншій керуючої інформації для протоколу Internet. Немає потреби тримати на шлюзі протоколи більш високого рівня, а функції GGP додаються до можливостей IP модуля.

+——————————–+ | Internet протокол & ICMP & GGP |
+——————————–+
| |
+—————-+ +—————-+ | Локальна мережа | | локальна мережа |
+—————-+ +—————-+
Рис. 3 Протоколи шлюзів

3. Спеціфіація 3.1 Формат заголовка Internet Нижче приведена повна схема полів заголовка Internet

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рис. 4 Приклад заголовка Internet датаграми Зауважимо, що кожна позиція відповідає одному біту.
Version (версія) 4 біта Поле версії показує формат заголовка Internet. Даний документ описує версію 4. IHL (довжина Internet заголовка) 4 біта Довжина Internet заголовка вимірюється в словах по 32 біта кожен і вказує на початок поля даних. Зауважимо, що коректний заголовок може мати мінімальний розмір 5 слів. Type of Service (тип сервісу) 8 біт Тип сервісу визначає з допомогою якихось абстрактних параметрів тип необхідного обслуговування. Ці параметри повинні використовуватися для управління вибором реальних робочих характеристик при передачі датаграми через конкретну мережу. Деякі мережі здійснюють обслуговування з пріоритетом, який якимось чином дає перевагу для просування даної датаграми в порівнянні з усіма іншими. Реально вибір здійснюється між трьома альтернативами: малою затримкою, високою достовірністю і високою пропускною здатністю. біти 0-2 пріоритет біт 3 0 – нормальна затримка, 1 – мала затримка біт 4 0 – нормальна пропускна здатність, 1 – висока пропускна здатність біт 5 0 – звичайна достовірність, 1 – висока вірогідність біти 6-7 зарезервовані

0 1 2 3 4 5 6 7
+—–+—–+—–+—–+—–+—–+—–+—–+ | Пріоритет | D | T | R | 0 | 0 |
+—–+—–+—–+—–+—–+—–+—–+—–+
Пріоритет 111 – керування мережею 110 – межсетевое управління
101 – CRITIC/ECP 100 – більше, ніж миттєво 011 – миттєво 010 – негайно 001 – пріоритетно 000 – звичайний маршрут
Використання індикації затримки, пропускної здатності та достовірності може, в певному сенсі, збільшити вартість обслуговування. У багатьох мережах поліпшення одного з цих параметрів пов’язано з погіршенням іншого. Винятки, коли мало б сенс встановлювати два з цих трьох параметрів, дуже рідкісні. Тип обслуговування використовується для вказівки типу обробки датаграми при її проходженні через систему Internet. Приклади відображення типу обслуговування в протоколі Internet на реальні послуги, що надаються такими мережами, як AUTODIN II, ARPANET, SATNET і PRNET дані в документі “Service Mapping” [8]. Значення “Управління мережею” слід присвоювати пріоритету тільки для використання всередині локальної мережі. Управління та реальне використання цього аргументу має перебувати в злагоді з кожною застосовує його мережею. Аргумент “межсетевое управління” призначений тільки для використання шлюзами, що беруть на себе управління. Якщо вищеописані аргументи пріоритету знаходять застосування в якій-небудь мережі, то це означає, що дана мережа може управляти прийомом і використанням цих аргументів. Total Length (загальна довжина) 16 біт Загальна довжина – це довжина датаграми, виміряна в октетах, включаючи Internet заголовок і поле даних. Це поле може задавати довжину датаграми аж до 65535 октетів. У більшості хост-комп’ютерів і мереж настільки великі датаграми не використовуються. Всі хости повинні бути готові приймати датаграми аж до 576 октетів довжиною (чи приходять вони цілком або по фрагментах). Хостам рекомендується відправляти датаграми розміром більш ніж 576 октетів, тільки якщо вони впевнені, що приймає хост готовий обслуговувати датаграми підвищеного розміру. Значення 576 вибрано з тим, щоб відповідним чином обмежений блок даних передавався разом з необхідною інформацією в заголовку. Наприклад, цей розмір дозволяє заповнювати датаграму полем даних розміром в 512 октетів і заголовком в 64 октету. Найбільший Internet заголовок займає 60 октетів, а його типовий розмір складає всього 20 октетів, що залишає місце під заголовки протоколів більш високого рівня. Identification (ідентифікатор) 16 біт Ідентифікатор встановлюється отправітелеім для збирання фрагментів небудь датаграми. Flags (різні керуючі прапори) 16 біт біт 0 зарезервований, повинен бути нуль біт 1 (DF) 0 – можливо фрагментованість, 1 – заборона фрагментації біт 2 (MF) 0 – останній фрагмент, 1 – будуть ще фрагменти
0 1 2
+—-+—-+—-+
| 0 | DF | MF |
+—-+—-+—-+ Fragment Offset (зсув фрагмента) 13 біт Це поле показує, де в датаграм знаходиться цей фрагмент. Зсув фрагмента змінюється порціями по 8 октет (64 біта). Перший фрагмент має зміщення нуль. Time to Live (Час життя) 8 біт Це поле показує максимальний час, протягом якого датаграм дозволено перебувати в системі Internet. Якщо це поле має значення нуль, то датаграма повинна бути зруйнована. Значення цього поля змінюється при обробці заголовка Internet. Час вимірюється в секундах. Однак, оскільки кожен модуль, що обробляє датаграму, повинен зменшувати значення поля TTL принаймні на одиницю, навіть якщо він обрабативаетт цю датаграму менне, ніж за секунду, то поле TTL слід розуміти як максимальний інтервал часу, протягом якого датаграма може сущенствовать. Увагу слід звернути на руйнування датаграм, які не можуть досягти одержувача, а також на обмеження часу життя датаграми. Protocol (Протокол) 8 біт Це поле показує, який протокол наступного рівня використовує дані з Internet датаграми. Значення для різних протоколів наводяться в документі “Assigned Numbers” [9]. Header Checksum (Контрольна сума заголовка) 16 біт Оскільки деякі поля заголовка міняють своє значення (наприклад, час життя), це значення перевіряється і повторно розраховується при кожній обробці Internet заголовка. Алгоритм контрольної суми наступний: Поле контрольної суми – це 16 біт, що доповнюють біти в сумі всіх 16 бітових слів заголовка. Для обчислення контрольної суми значення цього поля встановлюється в нуль. Контрольну суму легко розрахувати і досвідченим шляхом довести її адекватність, однак це тимчасова міра і повинна бути замінена CRC процедурою в залежності від подальшого досвіду. Source Address (адреса відправника) 32 біта (див. частину 3.2) Destination Address (адреса одержувача) 32 біта (див. частину 3.2) Options (опції) поле змінної довжини Опції можуть з’явитися в датаграмах, а можуть і не з’являтися. Вони повинні підтримуватися всіма Internet модулями (хостами і шлюзами). Не обов’язково кожна конкретна датаграма несе опції, але нести їх все ж може. У деяких додатках опція секретності має бути присутня у всіх датаграмах. Поле опцій не має постояннойц довжини. Опцій може не бути, а може бути декілька. Існують два формати опції: – Одиничний октет із зазначенням типу опції – Одиничний октет із зазначенням типу опції, октет для вказівки довжини опції, і, нарешті, октети власне даних. Октет довжини поля враховує октет типу опції, сам себе і октети з даними для опції. Вважається, що октет типу опції складається з трьох полів: 1 біт прапор копіювання 2 біта клас опції 5 біт номер опції Прапор копіювання показує, що ця опція копіюється в усі фрагменти при фрагментації. 0 – не копіюється 1 – копіюється Класи опції 0 – управління 1 – резервоване 2 – налагодження та вимірювання 3 – резервоване Визначено такі опції Internet клас номер довжина опис 0 0 – Кінець списку опцій. Ця опція займає лише один октет, октет довжини відсутня. 0 1 – Ні операції. Ця опція займає лише один октет. Не має октету довжини. 0 11 лютого Безпека. Використовується для підтримки безпеки, ізоляції, поділу на групи користувачів (TCC), обробки кодів обмеження, соответсвующих DOD вимогам. 0 3 перем Втрата маршруту відправника. Використовується для передачі Internet датаграми, заснованої на наявною у відправника інформації 0 9 перем Визначення маршруту відправника. Використовується для передачі Internet датаграми, заснованої на наявною у відправника інформації 0 7 перем Запис маршруту. Використовується для відстеження прохідного Internet датаграммой маршруту. 0 8 4 Ідентифікатор маршруту. Використовується для підтримки ідентифікації потоку. 2 квітня перем Тимчасової штамп Internet. Окремі описи опцій
+——–+ Тип 0 | 00000000 | End of Option List (кінець списку опцій)
+——–+ Ця опція позначає кінець списку опцій. Він може не збігатися з закінченням Internet заголовка, позначається полем Internet header length. Ця опція використовується після всіх опцій, але не після кожній. Вона необхідна тільки в тому випадку, якщо кінець списку опцій не збігся із закінченням Internet заголовка. Може бути скопійований, внесений або видалений при фрагментації, або по небудь іншої причини.
+——–+ Тип 1 | 00000001 | No operation (немає дій)
+——–+ Ця опція може бути використана між іншими опціями. Її метою може служити, наприклад, вирівнювання черговий опції по 32 – бітної кордоні. Може бути скопійована, внесена або видалена при фрагментації і з якоїсь іншої причини. Тип 130 Security (безпека) Ця опція дає спосіб хост-комп’ютерів відправляти параметри, пов’язані з безпекою, закритістю, введенням обмежень і параметрами TCC (закритою групою користувачів). Формат цієї опції наступний: (довжина 11 октетів)
+——–+——–+—///—+—///—+—///—+—///—-+
|10000010|00001011|SSS…SSS|CCC…CCC|HHH…HHH| TCC |
+——–+——–+—///—+—///—+—///—+—///—-+ Поле S (security) 16 біт Вказує один з 16 рівнів безпеки (вісім з яких зарезервовано). 00000000 00000000 – некласифіковані 11110001 00110101 – конфіденційний
01111000 10011010 – EFTO
10111100 01001101 – MMMM
01011110 00100110 – PROG 10101111 00010011 – обмежений 11010111 10001000 – секретний 01101011 11000101 – особливо секретний 00110101 11100010 – резервоване 10011010 11110001 – резервоване 01001101 01111000 – резервоване 00100100 10111101 – резервоване 00010011 01011110 – резервоване 10001001 10101111 – резервоване 11000100 11010110 – резервоване 11100010 01101011 – резервоване Поле C (compartments) 16 біт Нульове значення у всіх позиціях використовується коли передача інформації не обмежена. Решта значення для цього поля можна отримати від Секретного Оборонного Агенства. Поле H (введення обмежень) 16 біт Значення для управління та внесення позначок є буквено- цифровими діграмм і визна в документі DIAM 65-19
“Standard Security Markings”. Поле TCC (поле управління перенесенням) 24 біта Дає засоби для відстеження процесу відділення, його значення контролюються групами зацікавлених передплатників. Значення TCC мають три поля для записів і можуть бути отримані з документа HQ DCA Code 530. Розглянутий тип повинен копіюватися при фрагментації. Ця опція з’являється в датаграм не більше одного разу. Тип 131 Loose Source and Record Route (Втрата відправника і запис маршруту)
+——–+——–+———+——- // ——+ | 10000011 | довжина | покажчик | дані про маршрут |
+——–+——–+———+——- // ——+ Опція втрати відправника і записи маршруту (LSRR) забезпечує засоби, що дозволяють відправникові Internet датаграми передавати інформацію, використовувану шлюзами при передачі датаграм по призначенням, а також записувати інформацію про маршрут. Опція починається з коду типу. Другий октет – октет довжини, яка враховує код типу опції і сам себе, а також октет покажчика. Третій октет є покажчиком на дані про маршрут, він визначає октет, з якого починається наступний адресу відправника, що підлягає обробці. Покажчик відраховується від початку даної опції, а його найменше допустиме значення
– 4. Дані про маршрут складаються з ряду Internet адрес. Кожен Internet адреса – це 32 біта або 4 октету. Якщо покажчик перевищує довжину, то маршрут відправника порожній (поле із записами маршрута заповнено), а маршрутизація повинна грунтуватися на значеннях поля з адресою одержувача. Якщо адреса, записаний в поле адреси одержувача, був досягнутий, а покажчик не перевищив довжину, то наступну адресу в маршруті відправника заміщає адресу в поле з адресою одержувача. Записаний адреса маршруту замінює тільки що використаний адресу відправника, а покажчик збільшується на 4. Записаний адресу маршруту є власним Internet адресою Internet модуля, відомим у зовнішньому оточенні, куди ця датаграма прямує. Ця процедура заміщення вихідного маршруту записаним маршрутом (Хоча при зворотному порядку він повинен використовуватися як маршрут відправника) означає, що дана опція (а також і весь IP заголовок) зберігає постійний розмір при проходженні датаграми по Internet системі. Ця опція називається втратою маршруту відправника (loose source route), оскільки шлюз або IP хост можуть використовувати будь-які маршрути через будь-яку кількість інших проміжних шлюзів для досягнення наступного адреси в розглянутому маршруті. При фрагментації опція повинна копіюватися. В датаграм вона повинна з’являтися не більше одного разу. Тип 137 Strict Source and Record Route (Уточнити відправник і записати маршрут)
+——–+——–+———+——- // ——–+ | 10001001 | довжина | покажчик | дані про маршрут |
+——–+——–+———+——- // ——–+ Опція “уточнити відправник і записати маршрут” (SSRR) дає засоби відправникові Internet датаграми для підтримки інформації про маршрутизації, яка повинна використовуватися шлюзами при передачі датаграми за призначенням, а також для запису цієї інформації. Опція починається з коду типу. Другий октет – довжина опції, яка враховує код типу опції і октет довжини, октет покажчика (3 октету з даними про маршрут). Третій октет є покажчиком на дані маршруту, визначальним октет, з якого починається наступну адресу відправника, що підлягає обробці. Покажчик відлічується з початку цієї опції, а найменше припустиме значення покажчика – 4. Дані про маршрут складаються з серії Internet адрес. Кожен Internet адреса – це 32 біта або 4 октету. Якщо покажчик перевищує довжину, то маршрут відправника порожній (записуваний маршрут повний), а маршрутизація грунтується на значенні поля з адресою одержувача. Якщо адреса в поле адреси отримувача було досягнуто, а покажчик не перевищує довжини, то наступну адресу в маршруті відправника заміщає адресу в поле з адресою одержувача, а записаний адресу маршрута заміщає тільки що використаний адоес відправника, покажчик збільшується на 4. Записаний адресу маршруту – це власний Internet – адреса Internet – модуля, як він був би розпізнаний у зовнішньому середовищі, куди ця датаграма прямує. Ця процедура заміщення маршруту відправника записаним маршрутом (хоча в зворотному порядку він повинен використовуватися як маршрут відправника) означає, що опція (і весь IP заголовок) зберігає постійний розмір при проходженні датаграми через Internet систему. Ця опція є точним маршрутом відправника, оскільки шлюз або IP хост повинен посилати дану датаграму безпосередньо на наступну адресу в маршруті відправника через безпосередньо з’єднану мережу, на адресу, що показує наступний шлюз або хост, зазначений в маршруті. Опція повинна копіюватися при фрагментації. З’являється не більше одного разу на датаграм. Тип 7 Record Route (Записати маршрут)
+——–+——–+———+——- // ——–+ | 00000111 | довжина | покажчик | дані про маршрут |
+——–+——–+———+——- // ——–+ Опція запису маршруту дає кошти для запису маршруту Internet датаграми. Опція починається з коду типу. Другий октет визначає довжину опції, яка враховує код типу опції, сам себе, октет покажчика і довжину трьох октетів з даними про маршрут. Третій октет є покажчиком на дані маршруту. Покажчик визначає октет, з якого починається наступне поле для розміщення адреси маршруту. Покажчик відраховується від початку даної опції, а його найменше допустиме значення – 4. Записуваний маршрут складається з серії Internet адрес. Кожен Internet адреса – це 32 біта або 4 октету. Якщо покажчик більше, ніж довжина опції, то поле з записуваних маршрутом заповнено. Хост – Комп’ютер, який створює цю опцію, повинен зарезервувати поле з даними про маршрут і достатнім розміром, з тим, щоб воно вмістило всі очікувані адреси. Розмір цієї опції не змінюється при додаванні адрес. Первісне вміст поля під дані про маршруті має бути нульовим. Коли Internet модуль направляє датаграму, він перевіряє її на присутність розглянутої опції з записуваних маршрутом. Якщо вона присутня, то він вставляє свій власний Internet адреса в якості розпізнаного у зовнішньому середовищі, куди ця датаграма спрямована. Вставка здійснюється в опцію запису маршруту, в то місце, на яке вказує октет покажчика. Покажчик потім збільшується на 4. Якщо поле з даними про маршрут уже заповнено (покажчик перевищує довжину), то датаграма направляється без вставки адреси в опцію заповнюваного маршруту. Якщо є якийсь простір, але недостатня для вставки повної адреси, то вихідна датаграма вважається помилковою і руйнується. І в тому, і в іншому випадку на хост-відправник надсилаються повідомлення про проблему з ICMP параметром [3]. При фрагментації не копіюється, присутній лише в першому фрагменті. В датаграм присутні не більше одного разу. Тип 136 (довжина 4) Stream Identifier (Ідентифікатор потоку)
+——–+——–+——————–+ | 10001000 | 00000010 | ідентифікатор потоку |
+——–+——–+——————–+ Ця опція дає кошти для підтримки 16-бітової SATNET ідентіфткаціі потоку в мережах, які парвоначально НЕ підтримували потокову концепцію. Опцтя повинна копіюватися при фрагментації. В датаграм з’являється не більше одного разу. Тип 68 Internet timestamp (Тимчасової штамп Internet)
+——–+——–+———+—–+—–+ | 01000100 | довжина | покажчик | oflw | flg |
+——–+——–+———+—–+—–+ | Internet адреса |
+—————————————+
| Timestamp |
+—————————————+
| | Довжина – це кількість октетів в опції, яке враховує октети типу, довжини, покажчика та overflow / flag (максимальна довжина 40 октетів). Покажчик – це кількість октетів від початку цієї опції до кінця тимчасових штампів, плюс одиниця (тобто він вказує на октет, з якого починається вільне місце для наступного тимчасового штампа). Найменше значення – 5. Поле тимчасового штампа вважається заповненим, коли покажчик перевищує довжину опції. Overflow (oflw, переповнення 4 біта) – це кількість IP модулів, які не можуть провести реєстрацію тимчасових штампів через відсутність вільного місця. Flag (flg, прапори 4 біта) – це 0 – залишати лише тимчасові штампи, розміщені в наступних друг за одним 32-бітових словах 1 – кожному тимчасовому штампу передує Internet адреса реєстрованого об’єкта 3 – поля Internet адрес визначено заздалегідь. IP модуль лише реєструє свій часовий штамп, якщо його власну адресу збігається з наступним зазначеним Inernet адресою. Timestamp – це вирівняний по правій межі 32-бітний тимчасової штамп в мілісекундах (щодо опівночі за Єдиним Часу). Якщо час в мілісекундах визначити неможливо або не може бути відрахувати щодо опівночі за Єдиним Часу, то може бути внесено будь-яке інше час в якості тимчасового штампа при умови, що найстарший біт в поле тимчасового штампа буде встановлений в одиницю (що указавает на використання нестандартного значення). Хост-відправник повинен створювати цю опцію так, щоб поля для тимчасових штампів були достатні для розміщення всієї очікуваної інформації. Розмір опції не змінюється при додаванні тимчасових штампів. Спочатку вміст поля під тимчасові штампи повинно бути заповнено нулями, або Internet адреси повинні чергуватися з нулями. Якщо поле з тимчасовими штампами вже заповнено (покажчик перевищує довжину опції), то датаграма передається без вставки тимчасового штампа, а лічильник переповнення збільшується на одиницю. Якщо є місце, але воно недостатньо для вставки повного тимчасового штампа, або ж лічильник переповнення сам переповнений, то вихідна датаграма розглядається як помилкова і знищується. І в тому, і в іншому випадку на хост-відправник має надсилатися повідомлення про проблему з ICMP параметром [3]. Опція тимчасового штампа не копіюється при фрагментації, а зберігається в першому фрагменті. В датаграм з’являється не більше одного разу. Padding (Вирівнювання) Вирівнювання Internet заголовка використовується для того, щоб переконатися в тому, Internet заголовок закінчується на 32-бітної кордоні. Варавніваніе здійснюється нулями.
3.2 Обговорення Реалізація протоколу повинна бути ясною. Кожна реалізація повинна передбачати роботу з іншими реалізаціями, створеними іншими людьми. Хоча мета цієї специфікації – уточнення даного протоколу, проте існує відмінність інтерпретацій. У загальному випадку реалізація повинна зберігати консерватизм в манері відправлення, а свобода існує лише в манері отримання інформації. А саме, реалізація повинна бути акуратною в посилці добре визначених датаграм і повинна приймати будь-яку датаграму, яку вона могла б інтерпретувати (тобто немає середовища для технічних помилок). Основні Internet служби орієнтовані на датаграми і забезпечують фрагментацію датаграм на шлюзах, збірку на модулі Internet протоколу на хості-одержувача. Звичайно, фрагментація та збирання датаграм в мережі або за попереднім погодженням між шлюзами також дозволена, оскільки це очевидно для Internet протоколів і протоколів більш високого рівня. Цей очевидний тип фрагментації і збірки називається фрагментацією, залежної від мережі (або Internet), і далі тут не обговорюється. Відправників та одержувачів на рівні хост-комп’ютера дозволяють відрізняти Internet адреси, а також поле протоколу. Передбачається, що кожен протокол буде визначати, чи є потреба в мультиплексировании на хості.
Адресація Щоб забезпечити гнучкість у привласненні адрес комптьютерним мереж і дозволити застосування великої кількості малих і середніх мереж, поле адреси кодується таким чином, щоб визначати мала кількість мереж з великою кількістю хостів, середня кількість мереж з середнім кількістю хостів і велика кількість мереж з малою кількістю хостів. Додатково є escape код для розширеного режиму адресації. Формати адресації Старші біти Формат Клас 0 7 біт в мережі, 24 біта для хостів А 14 жовтня біт в мережі, 16 біт для хостів В 110 21 біт для мережі, 8 біт для хостів З 111 перехід в розширений режим адресації Нульове значення в поле мережі означає дану мережу. Цей режим використовується тільки в певних ICMP повідомленнях. Розширений режим адресації невизначений. Обидві ці можливості зарезервовані для майбутніх реалізацій. Реальні значення, що привласнюються мережевим адресам, дані в документі “Assigned Numbers” [9]. Локальний адресу, присвоєний локальної мережі, повинен дозволяти одиночному фізичній хосту працювати як кілька окремих Internet хостів. А саме, повинен існувати проміжок між адресами Internet хостів і повинні бути присутніми інтерфейси між мережею і хостом, які дозволили б кільком Internet адресами відповідати одному інтерфейсу. Хост повинен мати можливість для підтримки декількох фізичних інтерфейсів і для обробки датаграм з будь-якого з них, як якщо б вони були адресовані до єдиного хосту. Карта відповідності між Internet адресами та адресами таких мереж, як ARPANET, SATNET, PRNET та ін описані в документі “Address Mapping”
[5].
Фрагментація і компонування Поле Internet ідентифікації (ID) використовується разом з адресаміотправітеля та одержувача, полями протоколу для ідентифікації фрагментів датаграми при збірці. Біт прапора More Fragments (MF) встановлюється, якщо датаграма НЕ є останнім фрагментом. Поле Fragment Offset ідентифікує розташування фрагмента щодо початку в первісної нефрагментірованной датаграм. Одиниця виміру – 8 октетів. Стратегія фрагментації розроблена так, щоб нефрагментірованная датаграма мала нулі у всіх полях з інформацією про фрагментації (MF = 0, Fragment Offset = 0). Якщо ж Internet датаграма фрагментіруется, то виділення інформації проводиться шматками і по межі 8 октет. Даний формат дозволяє використовувати 2 ** 32 = 8192 фрагментів по 8 октетів кожен, а в цілому 65536 октетів. Зауважимо, що це збігається з значенням поля загальної довжини для датаграми (звичайно, заголовок враховується в загальній довжині датаграми, але не фрагментів). Коли відбувається фрагментація, то деякі опції копіюються, а інші залишаються лише в першому фрагменті. Кожен Internet модуль повинен бути здатний передати датаграму з 68 октетів без подальшої фрагментації. Це відбувається тому, що Internet заголовок може включати до 60 октетів, а мінімальний фрагмент – 8 октетів. Кожен Internet – одержувач повинен бути в змозі прийняти датаграму з 576 октетів в якості єдиного шматка, або у вигляді фрагментів, що підлягають збірці. Процес фрагментації може вплинути на попередні поля (1) – поле опцій (2) – прапор “more fragments” (3) – зсув фрагмента (4) – поле довжини Internet заголовка (5) – поле загальної довжини (6) – контрольна сума заголовка Якщо біт прапора заборони фрагментації (Don’t Fragment – DF) встановлено, то Internet фрагментація даної датаграми заборонена, навіть якщо вона може бути зруйнована. Даний засіб може використовуватися для запобігання фрагментації в тих випадках, коли хост-одержувач не має достатніх ресурсів для складання Internet фрагментів. Одним із прикладів використання коштів заборони фрагментації повинна служити лінія, яка веде до малого хосту. Маленький хост може мати фмксірованную завантажувальну програму, яка приймає датаграму, поміщає в пам’яті, а потім ісполниет її. Процедури фрагментації і збірки найбільш просто описуються прикладами. Наступні процедури є навчальними реалізаціями. У наступних псевдопрограммах приймається наступна нотація: “= <" Означає "менше або дорівнює", "#" означає "не дорівнює", "=" означає "Одно", "<-" означає "встановлюється в". Крім цього, "з x по y" означає включно по x, але не включаючи y. Наприклад, вираз "з 4 по 7 "означало б включення 4,5 і 6, але не включало б 7. Приклад процедури фрагментації Датаграма найбільшого розміру, яка ще може бути передана через чергову локальну мережу, називається найбільшою переданої одиницею (maximum transmission unit - MTU). Якщо загальна довжина датаграми менше або дорівнює максимальній переданої одиниці, то датаграма передається наступним процедурам обробки. В іншому випадку перш вона розбивається на два фрагмента, причому перший з них буде мати максимальний розмір, відповідно до другий фрагмент буде поміщений залишок вихідної датаграми. Перший фрагмент відправляється на подальшу обробку, а другий повторно піддається тільки що розглянутої процедурою, якщо і його розмір виявиться занадто великим. Позначення: FO - зсув фрагмента IHL - довжина Internet заголовка DF - прапор заборони фрагментації MF - прапор появи додаткових фрагментів TL - загальна довжина OFO - старе зсув фрагмента OIHL-стара довжина Internet заголовка OMF - старе значення прапора поява додаткових фрагментів OTL - старе значення загальної довжини NFB - кількість блоків фрагментації MTU - максимальна довжина перенесення Процедура IF TL = ” означає повертається значення).
SEND(src,dst,prot,TOS,TTL,BufPTR,len,Id,DF,opt => result) де src – адреса відправника dst – адреса одержувача prot – протокол TOS – тип сервісу TTL – час життя BufPTR – покажчик буфера len – довжина даних у буфері Id – ідентифікатор DF – заборона фрагментації opt – опції result – відповідь: Ok – успішна посилка датаграми Error – помилка в аргументах функції або в локальній мережі Зауважимо, що тип сервісу TOS включає пріоритет, а вимога безпеки передається в якості опції.
RECV(BufPTR,prot => result,src,dst,TOS,len,opt) BufPTR – покажчик буфера prot – протокол result – відповідь: Ok – успішне отримання датаграми Error – помилка в аргументах len – довжина буфера src – адреса відправника dst – адреса одержувача TOS – тип сервісу opt – опції Коли користувач відправляє датаграму, він здійснює SEND виклик, супроводжуваний усіма аргументами. Модуль Internet протоколу після отримання цього виклику перевіряє аргументи, готує і відправляє повідомлення. Якщо аргументи в порядку, а датаграма прийнята локальною мережею, то виклик завершується успішно. Якщо ж агрумент невірні або датаграма не прийнята локальною мережею, то виклик завершується з помилкою. В останньому випадку повинен бути зроблений відповідний звіт про причину проблеми, проте деталі таких звітів відносяться вже до конкретних реалізацій. В момент, коли датаграма приходить на модуль Internet протоколу з локальної мережі, може бути присутнім очікує її RECV виклик від користувача – адресата, а може і не бути присутнім. У першому випадку дзвінок задовольняється посилкою інформації з датаграми до користувачеві. У другому випадку користувачу – адресату надсилається нагадування про чекає його датаграм. Якщо користувач – адресат не присутній, відправникові повертається ICMP повідомлення про помилку, а прийняті дані руйнуються. Нагадування користувачеві може бути виконано через псевдопрериваніе або за допомогою аналогічного механізму відповідно до конкретної операційною системою, що підтримує дану реалізацію. Зроблений користувачем запит RECV може бути негайно задоволений чекає цього датаграммой або ж він може бути затримано до отримання відповідної датаграми. Адреса відправника включається в запит на посилку, якщо відправляє датаграму хост-комп’ютер має декілька адрес (кілька фізичних сполук або ж чисто логічних адрес). Internet модуль повинен стежити за тим, щоб адреса отправітелоя був одним з дозволених адрес для даного хоста. Реалізація протоколу може допускати або навіть вимагати застосування запиту до Internet модулю для позначення зацікавленості, або ж, навпаки, використання виключно-якого класу датаграм (тобто всіх датаграм, які мають в поле протоколу певний занчение). Дана глава характеризує функції інтерфейсу між користувачем і Internet протоколом. Використовувані позначення аналогічні більшості процедур функцій викликів на мовах високого рівня, однак даний спосіб поводження з Internert протоколом не є правилом для запитів на обслуговування типу пасток (тобто SVC, UUO, EMT), або для будь-якої іншої форми спілкування між процесами.
Додаток А: Приклади і сценарії Приклад 1 Приклад мінімальної Internet датаграми, що несе дані
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service| Total Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time =123 | Protocol =1 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+ Рис. 5 Приклад Internet датаграми Нагадаємо, що кожна мітка означає місце для одного біта. Тут приведена Internet датаграма версії 4 Internet протоколу. Internet заголовок складається з п’яти 32 бітних слів, а загальна довжина датаграми складає 21 октет. Дана датаграма є повноцінною датаграммой (А не фрагментом).
Приклад 2 У даному прикладі ми показуємо спершу Internet датаграму проміжного розміру (452 ​​октету даних), а потім два Internet фрагмента, які могли б виникнути при фрагментації вихідної датаграми в разі, коли максимальна допустима одиниця пересилання становила 280 октетів.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service| Total Length = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time =123 | Protocol =6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис. 6 Приклад Internet датаграми Тепер наведемо перший фрагмент, який виникає при розщепленні вихідної датаграми по межі після 256 октету даних.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service| Total Length = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time =119 | Protocol =6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис. 7 Приклад Internet фрагмента і другий фрагмент
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=5 |Type of Service| Total Length = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time =119 | Protocol =6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис. 8 Приклад Internet заголовка
Приклад 3 Тут ми показуємо приклад, коли датаграма має опції
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=4 | IHL=8 |Type of Service| Total Length = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time =123 | Protocol =6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt. len. = 3 | option value | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. len. = 4 | option value | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. len. = 3 | option value | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис. 9 Приклад Internet датаграми
Додаток Б: Порядок передачі даних Порядок передачі заголовка і даних, описаних в даному документі, визначається на рівні октетів. У той час як діаграма позначає групу октетів, порядок їх передачі є таким же, як при читанні на англійською мовою. Наприклад, у такій діаграмі октети передаються в порядку номерів.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Рис. 10 Порядок передачі байтів Октет являє собою число, для котрого самий лівий біт на діаграмі є найстаршим або самим значущим бітом. Так біт, зазначений нулем, є найбільш значущим бітом. Наприклад, наступна діаграма являє число 170 (десяткове)
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+ Рис. 11 Старшинство бітів Аналогічно, якщо многооктетное поле представляє число, то самий лівий біт в цьому полі є значущим бітом. При передачі многооктетного чила самий значущий октет передається першим.
Тлумачний словник 1822 BBN доповідь 1822, “The Specification of the Interconnection of a Host and an IMP “. Специфікація взаємодії між хост-комп’ютером і мережею ARPANET. ARPANET провідник Керуюча інформація в ARPANET повідомленні для інтерфейсу між хост-комп’ютером і IMP процесором. ARPANET повідомлення Одиниця передачі між хост-комп’ютером і IMP процесором в мережі ARPANET. Максимальний її розмір приблизно 1012 октетів (8096 бітів). ARPANET пакет Одиниця передачі всередині мережі ARPANET між IMP процесорами. Максимальний розмір її близько 126 октетів (1008 біт). Destination (Одержувач) Адреса одержувача, поле в Internet заголовку.
DF Біт заборони фрагментації в поле прапорів. Flags (Прапори) Поле Internet заголовка, що містить різні керуючі біти. Fragment Offset (Зсув фрагмента) Це поле Internet заголовка вказує, до якого місця в Internet датаграм відноситься фрагмент.
GGP Gateway to Gateway Protocol – Протокол спілкування між шлюзами. Даний протокол спочатку використовувався шлюзами для управління маршрутизацією та іншими функціями шлюзів. header (заголовок) Керуюча інформація на початку повідомлення, сегмента, датаграми, пакета або блоку даних.
ICMP Internet Control Message Protocol – Протокол контрольних повідомлень Internet. Підтримуване Internet модулем, ICMP повідомлення передається від шлюзів до хост-комп’ютерів і між хост-комп’ютерами, використовується для звітів про помилки а також для створення припущень про маршрутизації. Identification (Ідентифікація) Поле Internet заголовка, що містить ідентифікує значення, призначене відправником, і служить для збірки фрагментів небудь датаграми.
IHL The Internet Header Length – Поле Internet заголовка. Представляє собою довжину Internet заголовка, виміряну в 32-бітових словах.
IMP The Interface Message Processor – Процесор повідомлень інтерфейсу. Пакетний перемикач мережі ARPANET. Internet Address (адреса Internet) Четирехоктетний (32 біта) адреса відправника або одержувача. Складається з поля мережі і поля локального адреси. Internet фрагмент Порція даних з Internet датаграми, забезпечена Internet заголовком. Local Address (локальний адреса) Адреса хост-комп’ютера всередині будь-якої мережі. Реальне відображення локальної адреси Internet на адреси хост-комп’ютерів в мережі досить довільне, що дозволяє відображати кілька локальних адрес на один хост-комп’ютер.
MF Прапор появи додаткових фрагментів, що міститься в поле прапорів Internet заголовка module (модуль) Реалізація, звичайно програмна, протоколу або інших процедур more-fragments flag (прапор додаткових фрагментів) Прапор, який показує, чи містить дана Internet датаграма заключну частину вихідної Internet датаграми. Прапор включений в поле прапорів Internet заголовка.
NFB The Number of Fragments Blocks – кількість блоків фрагментації з даними в Internet фрагменті. Іншими словами, довжина поля з даними. Одиниця виміру – 8 октет. octet (октет) байт з вісьмома бітами Options (опції) Поле опцій Internet заголовка, може містити кілька опцій. Кожна опція може мати довжину в кілька октет. Padding (Вирівнювання) Поле вирівнювання Internet заголовка, що використовується для того, щоб переконатися в тому, що дані починаються по межі 32-бітного слова. Вирівнювання здійснюється нулями. Protocol (Протокол) Для даного документа це ідентифікатор протоколу вищого рівня, поле в Internet заголовку. Rest (Залишок) Частина Internet адреси, яка вказує локальну адресу. Source (Відправник) Адреса відправника, поле Internet заголовка.
TCP Transmission Control Protocol – Протокол управління передачею. Протокол спілкування між хост-комп’ютерами для здійснення комунікацій в середовищі Internet. TCP сегмент Одиниця даних, що передається між TCP модулями (яка має TCP заголовок).
TFTP Trivial File Transfer Protocol: Простий протокол передачі файлів, створений для UDP. Time to Live (Час життя) Поле Internet заголовка, що показує верхню межу для часу існування даної Internet датаграми.
TOS Тип сервісу Total length (загальна довжина) Поле Internet заголовка Total Length, що визначає довжину датаграми в октетах, що включає Internet заголовок і дані.
TTL Час життя Type of Service (Тип сервісу) Поле Internet заголовка, що визначає тип сервісу для даної Internet датаграми.
UDP User Datagram Protocol. Протокол на рівні користувача для додатків, орієнтованих на транзакції. User (Користувач) Користувач Internet протоколу. Це може бути модуль протоколу більш високого рівня, прикладна програма або програма шлюзу. Version (версія) Поле версії, що визначає формат Internet заголовка.
Посилання [1] Cerf, V., “The Catenet Model for Internetworking,” Офіс технологій обробки інформації, Оборонне Агентство розширених дослідних проектів, IEN 48, липень 1978.
[2] Bolt Beranek and Newman, “Specification for the Interconnection of a Host and an IMP, “BBN Технічний звіт 1822, переглянутий у травні 1978.
[3] Postel, J., “Internet Control Message Protocol – DARPA Internet Program Protocol Specification, “RFC 792, USC / Інститут Інформатики, Вересень 1981.
[4] Shoch, J., “Inter-Network Naming, Addressing, and Routing,” COMPCON, комп’ютерне товариство IEEE, кінець 1978 року. [5] Postel, J., “Address Mappings,” RFC 796, USC / Інститут Інформатики, Вересень 1981.
[6] Shoch, J., “Packet Fragmentation in Inter-Network Protocols,” Computer Networks, v.3, n.1, січень 1979.
[7] Strazisar, V., “How to Build a Gateway”, IEN 109, Bolt Beranek and Newman, серпень 1979. [8] Postel, J., “Service Mappings,” RFC 795, USC / Інститут Інформатики, Вересень 1981. [9] Postel, J., “Assigned Numbers,” RFC 790, USC / Інститут Інформатики, Вересень 1981.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*