Пробивка отверстий UDP по-прежнему требуется в IPv6, даже без NAT?

Предпосылки (переходите к вопросу)

IPv4 нуждался в NAT для сохранения адреса. Свойства брандмауэра NAT также были полезны для безопасности. Правила брандмауэра IPv4 NAT: «блокировать входящий пакет. remote-address:port -> local-address:port, если не отправлен исходящий пакет local-address:port -> remote-address:port в течение последних X секунд ".

Для однорангового приложения UDP это требует, чтобы вводящий сервер выполнял пробивку отверстий NAT. Для Client подключиться к Server (оба за брандмауэром NAT, FW), нам нужно, чтобы произошли следующие шаги:

                           periodic
                          keep-alive
                Introducer <------>
Client    FW                  FW    Server
------------------------------------------
       request
     introduction
       -------> Introducer
Client    FW                  FW    Server
       --------------------->X
         request connection
------------------------------------------
                            notify
                         introduction
                    [Client address:port]
                Introducer ------->
Client    FW                  FW    Server
------------------------------------------
Client    FW                  FW    Server
       <---------------------------
                  hello
------------------------------------------
Client    FW                  FW    Server
       --------------------------->
            request connection
------------------------------------------
Client    FW                  FW    Server
       <---------------------------
             accept connection
------------------------------------------
Client    FW                  FW    Server
       <-------------------------->
            periodic keep-alive

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

Мои вопросы:

Q1: Если правила брандмауэра IPv6 такие же, как правила брандмауэра IPv4 NAT (только без бита трансляции адресов), то правильно ли я думаю, что одноранговое приложение по-прежнему требует точно такого же процесса пробивки отверстий UDP?

2 квартал: Являются ли стандартные / готовые правила брандмауэра для большинства домашних маршрутизаторов IPv6 такими же, как правила брандмауэра IPv4 NAT, кратко изложенные вверху? Если есть другие, то как же так? Существуют ли какие-либо из них, которые имеют поведение по умолчанию accept-all-incoming-packets?

Ссылки

Они поддерживают точку зрения, согласно которой домашние маршрутизаторы IPv6 должны иметь / могут иметь правила брандмауэра, подобные NAT:

Переход на IPv6 подразумевает отказ от NAT. Это хорошая вещь?

Одно большое повышение безопасности, которое вы получаете с NAT, заключается в том, что он вынуждает вас использовать конфигурацию запрета по умолчанию. Чтобы получить через него какую-либо услугу, вы должны явно пробить дыры. ... Правильно настроенный брандмауэр предоставляет точно такие же услуги, что и шлюз NAT.

http://www.brynosaurus.com/pub/net/p2pnat/

Брандмауэры IPv6 по-прежнему обычно блокируют нежелательный входящий трафик по умолчанию, что делает пробивку дыр полезным даже для приложений IPv6.

(следующие ссылки отключены, потому что у меня достаточно очков, чтобы сделать 2)
http://tools.ietf.org/html/rfc5128

Даже будущий «мир чистого IPv6» может по-прежнему включать брандмауэры, которые используют аналогичное поведение фильтрации NAT, но без преобразования адресов. Поведение фильтрации мешает работе приложений P2P. По этой причине приложения IPv6, которые используют методы, описанные в этом документе для обхода NAT, могут также работать с некоторыми межсетевыми экранами, которые имеют поведение фильтрации, подобное NAT.

http://stackoverflow.com/questions/4647633/nat-traversal-and-ipv6

Брандмауэры не исчезнут в ближайшее время, c.f. http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16 «Рекомендуемые простые функции безопасности в оборудовании в помещениях клиента для предоставления домашних IPv6-услуг в Интернете». ... Вы можете ожидать, что вездесущие брандмауэры будут продолжать мешать протоколам приложений и потребуют от вас выполнения тех же основных методов обхода, которые влечет за собой IPv4 / NAT, чтобы поддерживать записи состояния в промежуточных ящиках на пути ваших приложений.

http://news.ycombinator.com/item?id=8229327

Люди продолжают говорить, что вместо взлома NAT у вас должен быть собственный IPv6 с брандмауэром для того же или лучшего уровня защиты. Но разве межсетевой экран IPv6 с отслеживанием состояния не создает тех же проблем, что и NAT? Придется ли мне по-прежнему использовать пакеты поддержки активности или протоколы, такие как PCP, чтобы фактически использовать P2P?

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

Однако они, похоже, предполагают, что в IPv6 не будет никаких правил брандмауэра, подобных NAT, или что процесс пробивки отверстий не нужен:

http://www.raknet.net/raknet/manual/ipv6support.html

NAT Punchthrough не требуется при использовании исключительно IPV6. Если вам известен IP-адрес системы, вы можете подключиться к ней напрямую, даже если эта система находится за маршрутизатором.

http://www.zerotier.com/blog/?p=226

Это уродливый обходной путь к фундаментальному ограничению, и чем скорее IPv6 сделает его устаревшим, тем скорее мы сможем начать действительно развертывать Интернет-протоколы нового поколения. ... Поскольку NAT почти всегда отслеживает состояние, требуются частые пакеты keepalive для удержания всех соединений открытыми. ... Если вы не отправляете пакет примерно раз в 120 секунд (для обычных NAT), ваше соединение будет забыто и будет сброшено. Пользователи за NAT, которые используют SSH, вероятно, обнаружили это при попытке оставить сеансы SSH открытыми в течение длительного времени, а SSH (как и большинство протоколов) имеет опцию поддержки активности протокола, доступную в качестве обходного пути.