Linux API. Исчерпывающее руководство

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

Краткую историю протокола IPv6 можно найти на странице www.laynetworks.com/IPv6.htm.

В связи с существованием протоколов IPv4 и IPv6 напрашивается вопрос: «А что насчет IPv5?» Такой версии никогда не существовало. Заголовок каждой IP-датаграммы включает четырехразрядное поле для хранения номера версии (IPv4-датаграммы всегда хранят в этом поле значение 4), а номер 5 был выделен для экспериментального протокола Internet Stream Protocol (его вторая версия, известная как ST-II, описана в документе RFC 1819). Данный протокол, ориентированный на соединения, был создан в 1970-х и предназначался для передачи голоса, видео и распределенного моделирования. В связи с тем что номер 5 уже был занят, наследником протокола IPv4 стала версия 6.

На рис. 54.2 показан сырой сокет (SOCK_RAW), который позволяет приложениям взаимодействовать непосредственно на уровне IP. Мы не станем рассматривать здесь сырые сокеты, поскольку большинство приложений задействует транспортные протоколы (TCP или UDP). Больше подробностей можно узнать в главе 28 книги [Stevens et al., 2004]. Одним из показательных примеров использования сырых сокетов является консольная программа sendip (http://www.earth.li/projectpurple/progs/sendip.html), позволяющая создавать и передавать IP-датаграммы с произвольным содержимым (с опциональной поддержкой UDP-датаграмм и TCP-сегментов).

Протокол IP передает датаграммы

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

Отправляющий узел может подменить исходный адрес пакета. Это является основой для простой DoS-атаки по протоколу TCP, известной как SYN-флуд (англ. SYN-flood). [Lemon, 2002] описывает детали такой атаки и меры защиты от нее, предпринимаемые современными реализациями TCP.

Реализация протокола IP может устанавливать ограничение на максимальный размер датаграммы. Существует также минимальный размер, который реализация обязана поддерживать; он равен размеру буфера повторной сборки IP. В IPv4 это ограничение установлено на уровне 576 байт, а в IPv6 — 1500 байт.

Протокол IP не поддерживает соединения и является ненадежным

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

Протокол IPv4 вычисляет контрольную сумму заголовка, что позволяет определять связанные с ним ошибки. Однако ошибки, которые происходят с данными, передающимися внутри пакетов, остаются без внимания. Разработчики IPv6 отказались от контрольной суммы заголовка и возложили ответственность за проверку ошибок и надежность на протоколы более высокого уровня. (Протокол UDP тоже поддерживает контрольные суммы; в IPv4 эта возможность является опциональной, а в IPv6 — обязательной; вычисление контрольных сумм в протоколе TCP является обязательным вне зависимости от версии IP.)

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

Протокол IP не исключает фрагментации датаграмм

IPv4-датаграммы могут достигать 65 535 байт. Протокол IPv6 поддерживает датаграммы размером 65 575 байт (40 байт для заголовка, 65 535 — для данных) и позволяет передавать сообщения еще большего размера (так называемые джамбограммы — англ. jumbograms).