Я задал один вопрос, уже связанный с назначением полезной нагрузки в сообщении Packet Too Big ICMPv6. why_PTB_payload
В соответствии с последней сертификацией IPv6 lo go я сталкивался с этим тестовым случаем, когда отправитель отправляет сообщение-запрос эхо-запроса ICMPV6 в пункт назначения с несколькими маршрутизаторами между ними и получателем (пункт назначения) ) получил эхо-запрос. затем
Приемник отправляет эхо-ответ ICMPv6, но получил слишком большое сообщение пакета ICMPV6 от маршрутизатора с неправильным / поддельным заголовком ответа эха, добавляющим к пакету (PTB) слишком большое сообщение в качестве полезной нагрузки , (Умышленная отправка неправильной полезной нагрузки).
Снова эхо-запрос ICMPv6, отправленный отправителем, теперь получатель начинает фрагментировать ответ эха из-за вышеуказанного шага 1 (т. Е. Без проверки полезной нагрузки PTB Приемник изменил значение MTU).
В соответствии с тестовым примером, мы не должны изменять MTU при получении неверной или поддельной полезной нагрузки в сообщении PTB (полезная нагрузка будет исходным пакетом, который не может быть переадресовано из-за меньшего значения MTU для пути)
Но этот поиск не нужен для проверки PTB для эхо-ответа и, похоже, не является подходящим вариантом использования, этот тестовый пример выглядит недействительным для меня, поскольку мы никогда не сохраняем состояние отправленного эхо-ответа ядром, чтобы проверить PTB в случае, если PTB несет неправильный заголовок ответа ICMPv6 в его полезной нагрузке.
Если это допустимый случай, то я хочу знать логический c, как мы можем реализовать это или нет тогда почему этот тестовый пример присутствует даже при сертификации IPV6 lo go.
Ссылка на документ, содержащийся в g тестовый набор IPv6LogoCertificationTestCases (номер тестового набора v6L C .4.1.12)