The steps to communicate with a IPV4 TCP client and a IPV6 TCP server are as follows:
1.ipv6 Create a IPV6 listener socket after the server starts, we assume that the server bundles the wildcard address to the socket
2.ipv4 client calls GetHostByName to find a record of the server host. The server host has both an A record and a AAAA record, because it supports both IPV4 and IPV6, but the IPV4 customer needs only a record of a
3. Customer calls connect, causing the client host to send a IPV4 syn to the server host
4. The server host receives the IPV4 SYN for the IPV6 listener socket, sets a flag indicating that this connection should use the IPV6 address of the IPv4 map, and then responds with a IPv4 syn/ack. After the connection is established, the address returned by the accept to the server is the IPV6 address of the IPV4 map.
5. When the server host sends a TCP subsection to the IPV6 address of the IPV4 map, its IP stack generates a IPV4 with the destination address for the mapped IPv4 address to send datagrams. As a result, all communication between the customer and the server uses IPV4 's load datagram.
6. Unless the server is shown checking that the IPV6 address is not a IPv4 mapped IPv6 address (in6_is_addr_v4mapped), it never knows that it is communicating with a IPV4 client. This detail is handled by a dual protocol stack. Similarly, IPV4 customers do not know that they are communicating with a IPV6 server
A supportive assumption of the above scenario is that the dual-stack server host has both a IPV4 address and a IPV6 address. This hypothesis is not a problem until all IPV4 addresses are exhausted.
The IPV6 UDP server also has a similar situation, but the address format of each datagram may vary. For example, if the IPV6 server receives a datagram from a IPV4 customer, the address returned by Recvfrom will be the IPV6 address of the customer's IPV4 map. The server calls SendTo with the IPV6 address of the IPv4 map to give a response to this client request. This address format tells the kernel to send a IPV4 datagram to the customer. However, the next datagram that the server receives may be a IPv6 datagram, and Recvfrom will return the customer's IPV6 address. If the server responds, the kernel generates a IPV6 datagram.
If you receive a IPV4 datagram that is destined for a IPv4 socket, no special processing is required. The IPV4 datagram is exchanged between the client and the server.
If you receive a IPV6 datagram that is destined for a IPv6 socket, no special processing is required. The IPV6 datagram is exchanged between the client and the server.
If you receive a IPV4 datagram that is destined for a IPv6 socket, the kernel takes the IPV6 address of the IPV4 map corresponding to the source IPV4 address of the datagram as the peer Recvfrom address returned by accept (TCP) or IPV6 (UDP). The IPV4 datagram is exchanged between the client and the server.
The opposite is not possible because, in general, an IPV6 address cannot be represented as an IPv4 address.
If a IPV6 TCP client specifies a IPV4 mapped IPv6 address to invoke Connect, or a IPv6 UDP client specifies a IPV4-mapped IPv6 address to invoke SendTo, Then the kernel detects this mapped address and sends a IPV4 datagram instead of a IPv6 datagram.
Neither connect nor call Sendto,ipv4 customers can specify a IPV6 address because the 16-byte IPv6 address exceeds the 4-byte length of the SOCKADDR_IN member structure in IPV4 's IN_ADDR structure.
Most dual-stack hosts should use the following rules when working with listening sockets:
1.ipv4 listener sockets can only accept foreign connections from IPV4 customers.
2. If the server has a IPV6 listener socket that is bound to a wildcard address, and the socket does not have the IPV6_V6ONLY socket option set, the socket can accept external connections from IPV4 clients and accept incoming connections from IPV6 customers. For connections from IPV4 customers, the server-side local address will be the IPV6 address of the IPV4 map corresponding to a local IPV4 address.
3. If the server has a IPV6 listener socket and is bound on a non-IPv6 address other than the IPV6 address of the IPv4 map, or a wildcard address on which it is bound, the ipv6_v6only socket option is also set. Then the socket can only accept incoming connections from IPV6 customers.
There is a small class of IPV6 application processes that must be clear about whether they communicate with IPV4 to the end. These applications need to know that the address to the end is not a IPv4 mapped IPv6 address.
The IPV6 server on the dual-stack host can serve both IPV4 customers and IPV6 customers. The IPV4 client is still sending the IPV4 datagram to the server, but the server's protocol stack translates the address of the client host into a IPV6 address of the IPV4 map, because the IPV6 server only handles the IPV6 socket address structure.
Similarly, IPV6 customers on dual-stack hosts can communicate with IPV4 servers. The client's parser returns all the A records of the server host as the IPV6 address of the IPV4 map to the customer, and the customer specifies that one of these addresses calls connect will cause the double stack to send a IPv4 SYN sub-section.
Only a small number of customers and servers need to know the specific protocol to use for the end, such as FTP, and whether the peer is using IPV4 can use in6_is_addr_v4mapped macros to determine.