Локальный адрес IPv6 со встроенной областью действия в OSX

Question

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

Вот строка из / sbin / ifconfig для OSX после автоматической настройки интерфейсов(:

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

выглядиткак значение для scope (5) было вставлено сразу после fe80.

Этот же код в Linux возвращает адрес ipv6 без каких-либо дополнительных данных.

Мне задаются два вопроса: 1)законно написать адрес IPv6, как это?2) Документировано ли поведение OSX где-нибудь?

Ссылки, пожалуйста!

Answer 1

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

Мой ответ на этот другой вопрос может быть полезным.

---

Редактировать : Я только что понял тонкость в этом вопросе.Стек IPv6 BSD внутренне хранит индекс интерфейса во 2-м 16-битном слове локального IPv6-адреса канала.Это должно никогда выходить на провод.Это на самом деле нарушение RFC, , потому что локальные адреса ссылок определены как имеющие 0 битов в этой области .(именно поэтому, между прочим, они могут избегать хранения здесь дополнительной информации) Я считаю, что это ошибка, и область действия должна действительно быть сообщена остальной части системы каким-либо другим способом.Таким образом, вы, вероятно, должны проверить это и раздеть это вручную.

---

Редактировать 2 : Я пошел и откопал место в источнике ядра, где они установили это значение :

  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-битного адреса, а не полагаться на какие-то метаданные.