RFC 791 - Internet Protocol - Summary

RFC 791 был написан в 1981 году для DARPA (Defense Advanced Research Projects Agency) Университетом информационных наук Южной Калифорнии. Документ разбит на три раздела: Введение, Обзор и Спецификации. Хотя Введение и Обзор имеют очень хорошую информацию, это резюме будет сосредоточено на спецификациях, но выделит несколько разделов из обзора.

Заголовок

Как видно из статьи Frames and Packets на этом сайте, заголовок IP выглядит так:

Подробности заголовка

Как видите, дейтаграмма содержит несколько элементов. Функцией для каждого элемента является:

• RFC 791 специально относится к версии 4
• Internet Header Length (IHL) - Информирует принимающие системы о длине заголовка и о том, когда данные начинаются
• Тип обслуживания (TOS) - это 8-битное значение используется для качества обслуживания.
  • бит 0-2 для Прецедентности
    • 000 - Рутина
    • 001 - Приоритет
    • 010 - немедленно
    • 011 - Флэш
    • 100 - Flash Override
    • 101 - CRITIC/ECP
    • 110 - Управление Интернетом
    • 111 Сетевой контроль
  • бит 3 для нормальной задержки (0) или низкой задержки (1)
  • бит 4 для нормальной пропускной способности (0) или высокой пропускной способности (1)
  • бит 5 для нормальной надежности (0) или высокой надежности (1)
  • Когда RFC 791 был написан бит 6 и 7, где резервируется для будущего использования
• Общая длина - Это общая длина дейтаграммы в байтах до 65535 октетов. Однако система должна быть способна принимать не менее 567 октетов.
• Идентификация - используется при сборке фрагментированных дейтаграмм
• Флаги - используются с фрагментацией датаграмм
  • бит 0 зарезервирован и должен быть 0
  • бит 1, если он установлен на 0, позволяет фрагментировать дейтаграмму. При установке на 1 датаграмма не может быть фрагментирована
  • бит 2, если он установлен на 0, указывает на последний фрагмент. Если набрать еще 1 фрагмент
• Fragment Offset - сообщает системам, выполняющим фрагментацию дейтаграммы, где она может фрагментироваться
• Время, чтобы жить - указывается, как долго датаграмма может сохраняться в сети. Если он достигает 0, датаграмма должна быть удалена
• Протокол - Указывает протокол следующего уровня, используемый в дейтаграмме
• Header Checksum - проверяет дейтаграмму в каждой точке сети
• Адрес источника - 32 бита
• Адрес назначения - 32 бита
• Варианты - Существует множество вариантов IPv4, которые могут применяться или не применяться. Для получения дополнительной информации, пожалуйста, прочитайте полный RFC, а именно страницу 15 - 22
• В конце заголовка дейтаграмма заполнена 0's, пока она не закончится на 32-битной строке

Резюме RFC

Как и во всех RFC, этот RFC требует, чтобы любой индивдуал, который реализует IP-датаграмму, соответствовал стандарту, чтобы любая сторона могла взаимодействовать с дейтаграммой в различных системах. В разделе 3 схема адресации IPv4 обсуждается подробно, как и функции, описанные выше. В отношении IPv4 RFC определяет размеры сетей класса A, B и C. Класс А выделяет 7 бит для сети и 24 бита для хостов. Класс B выделяет 14 бит для сети и 16 бит для хостов. Класс C выделяет 21 бит для сети и 8 бит для хостов. В дополнение к схемам адресации конкретные функции фрагментации и повторной сборки дейтаграмм подробно обсуждаются в RFC. Определение того, что некоторые опции могут включаться или не включаться, когда пакет фрагментирован.

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