Адрес локальной сети IPv6 с областью «встроенный» в OSX

Question

Я написал простой код, который использует ioctl SIOCGIFCONF для запроса всех сетевых интерфейсов в системе и, используя inet_ntop, возвращает текстовое представление найденного адреса. Странно то, что при обнаружении локального IPv6-адреса ссылки, версия OSX кода, похоже, встраивает область действия в адрес.

Вот строки из/SBIN/Ifconfig на OSX после autoconfiguring интерфейсов (:

en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 
     ether 00:17:f2:0b:52:73 
     inet6 fe80::217:f2ff:fe0b:5273%en1 prefixlen 64 scopeid 0x5 

и IP-адрес, возвращаемый IOCTL SIOCGIFCONF:

IPv6 адр: fe80: 5 :: 217 : f2ff: fe0b:. 5273

похоже, значение для сферы (5) была вставлена ​​непосредственно после fe80

Тот же самый код на Linux возвращает адрес IPv6 Wi любые дополнительные данные.

У меня есть два вопроса: 1) Можно ли написать адрес ipv6 следующим образом? 2) Является ли поведение OSX документированным где угодно?

Отзывы, пожалуйста!

Answer 1

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

Моим ответом на вопрос this other question может быть полезно.

---

Edit: Я просто понял, тонкость в этом вопросе. Стек BSD IPv6 внутренне сохраняет индекс интерфейса во втором 16-битном слове локального IPv6-адреса. Это должно никогда выйти на провод. Это фактически нарушение RFC, because link-local addresses are defined to have 0 bits in this area. (что, кстати, почему они могут уйти от хранения дополнительной информации здесь) Я считаю, что это ошибка, и область действия действительно должна быть передана остальной системе каким-то другим способом. Поэтому вы должны, вероятно, проверить его и разбить вручную.

---

Edit 2: Я пошел и выкопал place in the kernel source where they set this value:

466 static int 
    467 in6_ifattach_linklocal(
    468   struct ifnet *ifp, 
    469   struct ifnet *altifp, /* secondary EUI64 source */ 
    470   struct in6_aliasreq *ifra_passed) 
    471 { 
     ... 
    494     ifra.ifra_addr.sin6_family = AF_INET6; 
    495     ifra.ifra_addr.sin6_len = sizeof(struct sockaddr_in6); 
    496     ifra.ifra_addr.sin6_addr.s6_addr16[0] = htons(0xfe80); 
    497 #if SCOPEDROUTING 
    498     ifra.ifra_addr.sin6_addr.s6_addr16[1] = 0 
    499 #else 
    500     ifra.ifra_addr.sin6_addr.s6_addr16[1] = htons(ifp->if_index); /* XXX */ 
    501 #endif 

Обратите внимание на /* XXX */ на линии 500. ;-) Я думаю, что это был какой-то временный обходной путь/хак для правильной работы маршрутизации без перезаписи частей кода маршрутизации. При локальных адресах ссылок вам необходимо будет принимать решения о маршрутизации на основе исходных и целевых интерфейсов. Поместив if_index в это место по адресу, они могут, вероятно, просто выполнить самое длинное совпадение префикса только на 128-битном адресе, а не полагаться на какие-то метаданные.