Кратко

  • RFC 5121 задаёт отдельный IPv6-канал и уникальный префикс для каждой мобильной станции, но исходная рекомендация по MAC-derived IID позднее была обновлена RFC 8064.
  • Политика генерации IID, IPv6-адрес, CID, сервисный поток, туннель и L3-канал должны иметь разные идентичности и историю.
  • Согласование одной convergence sublayer доказывает способ переноса; топология, адресация, ND, multicast, MTU и фактический результат пакета требуют собственных квитанций.

В первоначальном тексте RFC 5121 у мобильной станции есть 48-битный MAC-адрес, из которого предписывалось строить modified EUI-64 interface identifier. Одновременно допускались случайные идентификаторы из механизмов privacy extensions. Спустя годы RFC 8064 формально обновил документ и рекомендовал не включать стабильные адреса канального уровня в стабильные IPv6 IID.

Если инвентаризация использует IID как главный ключ для самого канала, такое обновление выглядит как исчезновение старого объекта и появление нового. Но сетевая модель говорит иное. Канал связывает мобильную станцию и access router; префикс относится к этому каналу; несколько адресов и IID могут существовать в его рамках. Изменение способа построения адреса не обязано менять транспортные соединения или топологию.

Идентичность — это набор отношений

RFC 5121 рекомендует point-to-point модель. Каждая мобильная станция принадлежит отдельному IPv6-каналу, даже если несколько станций используют одну базовую станцию. Для каждого MS/host link должен назначаться уникальный префикс или набор префиксов; обычно речь идёт об одном или нескольких /64 с on-link flag.

Надёжная запись не объявляет один атрибут вечной сущностью. Она хранит link ID, endpoints, префикс, действующие адреса, политику IID и интервалы их валидности. Тогда переход от MAC-derived IID к privacy-aware или semantically opaque схеме становится заменой политики, а не переписыванием прошлого.

DHCP или AAA могут делегировать префикс, но это меняет механизм доставки, не принадлежность. Аналогично временный IPv6-адрес меняет наблюдаемое значение, но не создаёт новый L3-канал. История должна позволять спросить: какой адрес был действителен на каком канале в конкретный момент и по какой политике он появился.

Одна sublayer не является всей топологией

IEEE 802.16 допускает перенос IPv6 через IP-specific Packet CS и через Ethernet-related путь. RFC 5121 ограничен IP CS. Станция и база обмениваются capabilities при регистрации, а при создании transport connection указывают выбранную convergence sublayer.

Если обе стороны поддерживают IP CS, она служит default. Если доступны IP CS и Ethernet CS, стороны должны использовать IP CS. На одном канале они согласуют не более одной convergence sublayer для IPv6. Если общей возможности нет, соединение не создаётся и хост не может передавать IPv6 по этому пути.

Это важная, но узкая квитанция. Реализация базовой станции должна поддерживать Standards Track encapsulations, однако режимы могут быть выключены конфигурацией. Следовательно, «реализовано», «включено», «согласовано» и «использовано данным пакетом» — разные события. Ни одно из них не говорит, какой IID был выбран или кому принадлежит префикс.

Несколько CID остаются под одним каналом

Generic MAC header сам не объявляет тип payload. Classifier сопоставляет пакет с service flow и transport connection по адресам, Next Header, traffic class, диапазонам портов и другим полям. Соединение обозначается CID, причём между той же станцией и базой может существовать несколько CID.

Если access router и база совмещены, совокупность соединений к одной станции образует один канал. Если они разнесены, RFC 5121 рекомендует туннель с гранулярностью не грубее одной станции или service flow. Туннели вместе с радиосоединениями формируют point-to-point link.

Система, которая использует CID как идентичность канала, создаёт лишние L3-объекты. Система, которая объединяет несколько станций в неразличимом туннеле, теряет изоляцию. Правильный ledger связывает, но не отождествляет link, station, service flow, CID и tunnel.

DAD зависит от двух фактов, а не от имени модели

Point-to-point характер может сделать Duplicate Address Detection избыточным для некоторых global addresses, но RFC 5121 называет две предпосылки. Объявленный префикс должен быть уникален для данного канала. Access router не должен автоконфигурировать собственный global address из этого префикса.

Если автоматизация просто видит метку p2p и отключает DAD, она заменяет факты названием. После переиспользования префикса, изменения туннеля или миграции router эти предпосылки нужно проверить заново. Решение без сохранённого основания быстро превращается в наследуемый риск.

Обновление IID-политики усиливает эту мысль. Нельзя считать MAC-derived IID гарантией уникальности навсегда и строить вокруг него исключение. Доказательство должно опираться на текущие условия из спецификации и текущий способ формирования адресов.

Сон изменяет наблюдаемость, а не требования к доказательству

Станция может перейти в idle mode, после чего радиоканал разбирается и для доставки требуется paging. Частые Router Advertisements будили бы устройство, поэтому RFC 5121 допускает длинные интервалы. Access router также не должен слать периодические MLD queries спящему хосту.

Отсутствие трафика может означать корректный сон или потерянное состояние. Нужно хранить событие перехода, paging state, последнее действительное RA, multicast memberships и trigger повторной проверки. Без контекста монитор либо ломает энергосбережение, либо считает недоступность нормальной тишиной.

Размер пакета также имеет несколько источников истины

Рекомендуемый default IPv6 MTU равен 1500 octets. Другое значение требуется объявить в ND MTU option; Path MTU Discovery может обнаружить меньший предел дальше по пути. Конфигурация, объявление и реально прошедший размер — три квитанции.

В тексте RFC одиннадцатибитный Len связывается с MAC PDU размером 2048 bytes. Errata 1768 предлагает 2047 как максимальное представимое значение, но имеет статус “Held for Document Update”, не Verified. Нельзя молча заменить исходник и нельзя скрыть известное уточнение. Следует сохранить текст, арифметическое замечание и процедурный статус, а эксплуатационный предел проверить пакетами и Packet Too Big.

Эволюция без потери истории

Тонкий общий контракт может фиксировать endpoints канала, выбранную форму переноса, стабильные ссылки между flow, CID, tunnel и prefix, а также способ экспорта событий. Политика IID, paging, classifiers и локальная автоматизация могут меняться независимо.

Главное — не превращать одну удобную идентичность в абсолютную. Capability описывает возможность. Negotiation — выбор. CID — transport connection. Prefix — адресное пространство канала. IID — часть адреса по конкретной политике. Packet capture — наблюдение. User outcome — результат услуги. Система остаётся управляемой, пока умеет соединять эти слои без их подмены.

Источники