huitema
commented
4 years ago I think this can work with the current definition of new path request and new path response, but requires the definition of a "punch" frame, with parameters being:
- the ID of the path request to which it is responding
- the IP address and Port to which the punch is sent.
This gives the following exchange:
1) "Client" sends a new path request, specifying ID and list of addresses 2) "server" either accepts or decline. 3) if server accepts, server send path response, and also send a set of messages with punch frames to each of the IP addresses specified by the client in the new path request. 4) after client receives the message, it sends a bunch of punch frames to the addresses specified by the server in the new path response. 5) if the server receives a punch frame, it replies with another punch frame on the reverse path. (So migration actually starts from the client) 6) if the client receives a punch frame, it checks whether this is the first for the request. If it is not, it can be ignored. If it is, the client starts migration to the discovered path -- path challenge, etc.
nibanks
ICE (and Teredo) punch holes by sending gratuitous packets to the "guessed" address of the peer. Packets need to have a unique ID, which is carried in the response. This smells a lot like the definition of the challenge/response exchange, but there are differences:
One big question is "how many probes". If I remember correctly, some NAT traversal strategy try to defeat symmetric NAT by guessing the range of port numbers that the NAT might use, and have each node send "M" packets, such that M*M is larger than the size of the range. This exploits the birthday paradox to find a common hole.