Является ли порядок байтов в сети бессмысленным под IPv6?
Если мы используем 32-разрядное целое число для хранения адреса IPv4, то необходимо учитывать порядок байтов целого числа.
Однако, поскольку встроенный 128-битный целочисленный тип отсутствует практически на всех платформах, адрес IPv6 должен храниться в байтовом массиве, поэтому я считаю, что порядок следования байтов больше не является проблемой.
Я прав? Или есть соответствующая функция htonlXXX для IPv6?
Решение
IPv6 требует сетевой порядок байтов для адресов ipv6. hton и ntoh — все о преобразовании адреса из того, как он хранится в вашем коде, в способ его хранения в пакете (и наоборот). Таким образом, проблема заключается в том, как он хранится в вашем коде.
Кроме того, определение адреса IPv6 в коде может позволить больше способов адресации, чем просто массив байтов:
struct in6_addr
{
union
{
__u8 u6_addr8[16];
__u16 u6_addr16[8];
__u32 u6_addr32[4];
} in6_u;
#define s6_addr in6_u.u6_addr8
#define s6_addr16 in6_u.u6_addr16
#define s6_addr32 in6_u.u6_addr32
};
IPv6-адреса для пользователя представлены в виде 8 16-битных значений. Если в вашем коде адрес хранится как 8 16-битных значений, то вам нужно будет использовать htons для каждого 16-битного значения, когда вы помещаете его в пакет с помощью массива u6_addr16 [], и использовать ntohs при получении каждого 16 -битное значение из u6_addr16 [].
Эти ссылки полезны:
http://msdn.microsoft.com/en-us/library/ee175867.aspx
http://en.wikipedia.org/wiki/IPv6_address (особенно схема в правом верхнем углу)
Другие решения
Сетевой порядок байтов был полезен в 2 ситуациях. Во-первых, вы можете использовать его по указанному адресу. Во-вторых, вы должны учитывать порядок байтов отправляемых вами данных. Вы правы, говоря в комментариях, что TCP — это просто поток байтов, но многие протоколы определяют порядок байтов чисел как порядок сети.
Однако, поскольку встроенный 128-битный целочисленный тип отсутствует практически на всех платформах, адрес IPv6 должен храниться в байтовом массиве, поэтому я считаю, что порядок следования байтов больше не является проблемой.
Это не следует; Когда вы создаете байтовый массив, вам все еще нужно решить, упаковать ли вы данные в порядке 0123456789ABCDEF или FEDCBA976543210. Правильный порядок байтов все еще требуется, просто такие функции, как ntohl() а также htonl() не применимы при генерации 128-битного адреса.
Если вы генерируете двоичный адрес из формы «презентация», используя inet_ntop () например, вам не нужно самим определять порядок следования байтов для любого типа адреса. Порядок байтов по-прежнему важен, но API его обработает.
Конкретная причина, по которой вы должны уделять пристальное внимание порядку байтов при обработке адресов IPv4 и номеров портов, заключается в том, что структуры sockaddr_in а также in_addr иметь члены данных с целочисленными типами, большими, чем charи чье содержимое должно быть в сетевом порядке байтов.
Даже с IPv4 вы можете не беспокоиться о порядке байтов адресной части этого — используйте inet_aton или же inet_pton заполнить in_addr прямо из строки. Последняя функция тоже делает адреса IPv6 (заполняя in6_addr).
При использовании IPv6 вам все еще нужно htons для номера порта, и вам потребуется преобразование хост / сеть, если вы решите получить доступ к in6_addr кусками больше байта.
Как вы говорите, если ваша платформа не имеет 128-битного типа, то вы не можете получить доступ к in6_addr как один 128-битный блок таким образом, чтобы вы могли получить доступ in_addr как один 32-битный кусок. Но если какой-то сетевой интерфейс / реализация с 128-битным типом когда-либо решит предоставить 128-битное представление, то, надеюсь, он также обеспечит соответствие ntohX а также htonX функции.
struct in6_addr{
uint8_t s6_addr[16];//128bit ipv6 address
};
Благодаря этой структуре то, что вы считаете правильным.