Hi Wen, I still doubt this will work with NAT at all, as incoming ICMP pings will be bounced by the NAT and never reach the host with the peer.
If only one peer is behind NAT, you will still absolutely need the ability to substitute the payload in the PONG for something else, so as to get any transmission going to the NATed peer, and even then the question is if the NATed peer will allow the PONG through if the payload fails to match the PING. Truncation is then just yet another issue. Please play with command-line / pcap / etc. tools as a proof-of-concept now. I would feel more comfortable with this if we had the following: 1) an "ICMP client" implementation that sends an ICMP ECHO request to an IP address given at the command line, with "Hello" in payload 2) an "ICMP server" implementation that sends an ICMP ECHO REPLY to an IP address given at the command line with "World" in payload and us confirming for _some_ NAT box (we should have plenty within the team) that when we run the client *behind* the NAT and send a packet to an unrestricted server (i.e. one of our university systems), and then use the ICMP server to send a "fake" reply back to the external IP of the NAT, the "World" packet does cross the NAT. We could use iptables to block the kernel's ICMP ECHO RESPONSE and wireshark to confirm the receipt of the "world" ICMP ECHO RESPONSE. That's the simplest scenario to demonstrate ICMP "works" with NAT. For me, this is important to know as for I the networks I use, they either have NAT involved or UDP/TCP are likely to work fine already. Naturally, I don't know about China with its IPv6 deployment, so if you have data that shows that ICMP will work in situations where TCP/UDP will not work, I'm willing to be educated ;-). My 2 cents Christian On 03/20/2015 05:24 PM, Wen Yuzhong wrote: > Hi Christian, > > My idea is encapsulating all the payload in the ICMP echo request packet, > so upon the system on the other side receives the Ping, the system will > response a Pong as normal, then the RAW socket interface will parse the > payload of the incoming ICMP echo request, and give the data to the upper > layer of GNUNet. For the firewall/NAT, this will be like a normal ICMP > conversation. In this way every Ping is matched with a Pong, we don't need > to deal with the duplicated Pong problem. > > However, as the frequency of the packet sending goes high, the channel > might be flooded by ICMP echo response packets. From my point of view, this > transport service is for *extreme* situations, so the throughput is not the > first priority. But as you pointed out, there should be a throughput > measurement, to see if this thing is really *useful* under certain overhead. > > ---------- > Best regards, > Wen _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
