В настоящее время мы работаем с академическим сетевым протоколом, который модифицирует и частично шифрует пакеты IPv6, а также устанавливает каналы для обеспечения маршрутизации без источника.
Мы запустили прототип, и он работает с сообщениями IPv6, если мы помещаем полезную нагрузку сообщения непосредственно в полезную нагрузку IP-пакета (например, отправляем привет, мир).
Однако мы не можем использовать хорошо зарекомендовавшие себя инструменты, такие как ping или iperf3, так как сообщения получают адресат, но ответы не отправляются.
Нам интересно, сможем ли мы протестировать некоторые особенности прототипа.
Насколько я понимаю, нет никакого смысла оценивать потерю пакетов, так как сам протокол не вводит причины потери пакетов, кроме отключения узла на маршруте.
Кроме того, на самом деле не имеет смысла измерять пропускную способность данных, поскольку это зависит от связи между двумя сторонами.
Сам протокол также не вводит причин для джиттера, потому что все сообщения обрабатываются одинаково, таким образом, опять же, это атрибут, связанный с сетью.
Задержка также в основном связана с проблемами, связанными с сетью, но мы можем измерить время, необходимое прототипу для изменения сообщения.
В настоящее время мы запускаем его на виртуальных машинах. Он использует правила iptables для перехвата пакетов и передачи их в nfqueue, который модифицирует пакеты с помощью python.
Вместо этого я предложил провести теоретический анализ: подсчитать дополнительные байты, которые добавляются поверх обычных IPv6-пакетов, попытаться рассчитать дополнительные затраты на производительность (как?) и попытаться сузить сделанное, какие атаки осуществимы, а какие нет. , по отношению к обычному IPv6.
- Какие функции имеет смысл тестировать?
- Помимо размера пакета и затрат на производительность, что еще можно теоретически проанализировать?
P.S.: Я надеюсь, что он вписывается в эту категорию, так как он, похоже, не вписывается в сетевую инженерию.