Should we negotiate ADD_ADDRESS as a separate transport parameter?

[huitema]

The ADD_ADDRESS frame is required in the NAT Traversal scenario, but it is also useful for "server initiated path creation" -- a classic multipath scenario. See for example the issue "(Should servers be allowed to open new paths)[https://github.com/quicwg/multipath/issues/47]" in the QUIC Multipath Extension repository. This draft negotiates ADD_ADDRESS and PUNCH_ME_NOW with a single parameter. Supporting one implies supporting the other. That may or may not be the right solution. I anticipate that this point will be raised during adoption discussions in the QUIC WG. It would be good to document the issue in a future version of the draft.

Most scenarios of "server initiated path creation" require traversing the client side NAT. This is one of the reasons why this type of path creation was punted to a further version is the QUIC Multipath draft -- or why only the client initiates Path Migration in RFC 9000. We can argue that such path creation also traverses a server side NAT, or at a minimum a server side firewall. If it does, then bundling ADD_ADDRESS and PUNCH_ME_NOW is natural. As an example, servers deployed as Virtual Machines in big servers farms are typically behind a firewall, which will only allow traffic though a few specific port numbers such as 80 or 443. Establishing a path that uses a different port will require firewall traversal.