From what I can tell, each process could get its own IP address, with loads of IP's to spare.
What would the drawbacks be?
Essentially, your host would become a router and each process is a host (in the current system).
Tcp – Could IPv6 make NAT / port numbers redundant
ipv6nat;protocol-theorytcpudp
Related Solutions
The NAT device will keep a table with currently open connections so that it can send return packets to the internal host that opened the connection. An entry in the state table could look something like this:
Internal Source IP | Internal S-Port | External S-Port | Destination IP | D-Port 192.168.1.12 10123 10123 203.0.113.1 5555
When a packet is received (from the external side) the NAT device will check the Source IP, Source Port and Destination Port of the packet and compare it to the Destination IP, D-Port and External S-Port fields in its connection table. When it finds a match it will forward the packet to Internal Source IP on Internal S-Port.
UDP hole punching depends on the fact that Internal and External Source Ports are the same. This is normally the case unless you have a second internal host that uses the same Source port to connect to the same external Destination/D-Port combination.
When we assume that Internal and External S-Port are the same then both clients A,B can communicate their source port to the rendezvous server which will then relay the information back to the other client respectively.
First: What you describe is NAT, not firewalling. A firewall just filters what can go through, a NAT device changes addresses in packets.
You almost answer the first question yourself. Yes, a NAT device needs to keep track of every session going through it. Most communication on the internet uses TCP or UDP. Both of these protocols use port numbers. A session is defined by source address, source port number, destination address and destination port number. The NAT device needs to maintain a mapping between which numbers on the inside correspond to which numbers on the outside. And then it has to match every packet to an entry in its mapping table and adjust the packet accordingly.
This is also why NAT devices are less than optimal: a normal router is stateless. It doesn't need to keep track of what happened previously and it doesn't need to adjust the numbers and addresses in the packet. If a router fails another router can take over immediately. When a NAT device fails the device that takes over doesn't have the same mapping table and all sessions break and have to be re-established.
Your second question is more complex. One option is to configure port forwarding in one of the NAT devices. Then you let A send a packet to the forwarded port on C. B will change the source address and port to one of its own. When the packet arrives at C it then adjusts the destination address and port so the packet is forwarded to D. Reply packets do exactly the same in the opposite direction.
If there is no port forwarding then it gets more difficult. You need to have the assistance of an external server E. Both A and D have to initiate connections to E. Then E has to coordinate setting up the session between A and D. A and D both send outbound packets to trick B and C into adding entries to their mapping tables. Once those mappings are in place they can communicate directly.
To summarise: the way things usually work is that for outbound packets you have a device that performs source NAT. It changes the source address and port of the internal device to one of its own. For inbound packets you have a device that performs destination NAT. It changes the destination address and port to what is in its mapping table. The mapping table is filled either by manual configuration, by a protocol that lets internal systems request a mapping (didn't talk about those, look up UPNP and PCP) or automatically when the NAT device creates an entry for an outbound packet.
Best Answer
IPv6 does not have a NAT standard as IPv4 does (NAT breaks the end-to-end premise of IP, and IPv6 was designed to restore that). There is an experimental RFC for IPv6 NAT, but it is a one-to-one NAT at the network layer, rather than something like the IPv4 NAPT that also translates port addresses, and, in fact, the experimental IPv6 NAT RFC expressly forbids that.
If you think about the various transport protocols, TCP and UDP use ports, which are really addresses for those transport protocols. Other transport protocols may use other addressing, and some use no addresses.
Your idea would possibly work with either TCP or UDP, but only one, and probably not with other transport protocols. IPv6 is connectionless, like UDP, so it may work with UDP, but TCP is connection-oriented, and it performs a lot of work that would otherwise need to be performed by the application.
There are requirements for both connectionless and connection-oriented transport protocols. The predecessor to IPv4 actually had the equivalent of IP and TCP as a single protocol, but it became necessary to split them because some transport protocols need to be connectionless.