I am running my program on Solaris.
Do I need to configure my machine to run a socket program using IPV6 APIs.
Are the IPV6 APIs backward compatible?
for eg can I use AF_INET6 for both the protocols IPV4 n 6 ?
No, you cannot set an OS option to control that behavior. The application code has to be specifially written to use the IPv6 APIs and differentiate between IPV4 and IPv6 connections.
No, the IPv6 APIs are not backwards-compatible. AF_INET is specific to IPv4, and AF_INET6 is specific to IPv6. However, many of the IPv4 API functions and structures were updated to support IPv6, and some new API functions and structures have been introduced that support both protocols in a more agnostic manner.
Related
I have a hardware attached to my RPI board running Linux distro. This hardware & its associated Host stack has created a network interface called wpan0 and assigned some IPV6 addresses to it (I am able to ping the IPV6 address from a remote device in the same network)
Now, I want to enable data communication to this interface to any IPV6 IP assigned to the interface. How do I create and bind a socket to this interface? Also, I want to listen to any ports on this interface. How to achieve this?
How you create a socket depends on the language you use (you didn't specify), but when you want to bind a socket to ANY interface the IPv4 way is to listen to IP 0.0.0.0, the IPv6 equivalent is ::/0, that means all zeros/0 bits CIDR mask.
Redirecting all ports to one is less of a code issue and requires some hands on with IPTables and Prerouting (you can write some code that appends that to your conf file though), here is an example:
https://serverfault.com/questions/616535/iptables-destination-ip-and-port
I tried to convert the destination address to IPv6 format as ::ffff:IPv4. And use a socket of AF_INET6 type. It gives error: Network Unreachable. But using the same technique I am able to communicate from IPV4 to IPV6
Thanks for your help in advance.
IPv4 and IPv6 are separate protocols. They don't talk to each other.
On some operating systems you can use an IPv6 socket and accept incoming IPv4 connections on it. But that is just a software thing to make code development easier for server code. I have never seen that work for client code. You'll have to create the right socket type for that.
Usually you resolve a hostname using DNS, you'll get multiple answers (IPv4 and IPv6), you iterate over them creating the required socket type and try to connect. If it works you use that socket, if not you do the next iteration which creates a new socket etc.
If you code that is sensitive to delays you might want to implement the happy eyeballs algorithm.
On most systems, PF_INET6 sockets are able to communicate with IPv4 addresses by using addresses in the ::FFFF:0:0/96 range. However, this is only done at the level of the sockets library: the actual on-the-wire data are plain IPv4 packets (as though you had used an PF_INET socket), there is no protocol conversion in the network.
The error you receive indicates that you have no IPv4 route to the requested destination. This probably indicates that your host doesn't have an IPv4 default route. There is no solution to that — without IPv4 connectivity, there is nothing you can do to reach an IPv4 address.
I am using setsocketopt function for Ipv4 address and using IP_TOS value for PPROTO_IP option.
what is the equivalent of IP_TOS in IPv6 addressing?
In IPv6 we use PROTO_IPv6, but I could not find any equivalent option like IP_TOS in IPv6 addressing.
I don't know how widely supported it is, but I believe the constant for "setsockopt() traffic class" would be IPV6_TCLASS:
http://www.ietf.org/rfc/rfc3542.txt
See also:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/setsockopt.htm
http://developer.android.com/reference/java/net/SocketOptions.html
As per MSDN Article ID: 248611 ToS is ignored and the GQOS API is limited to IPv4-only. For IPv6 and IPv4 you must use qWAVE QOS which requires Vista or later platforms.
i.e. QoS is completely abstracted away from BSD sockets in Windows land.
Deprecating old QoS APIs
"Back in XP we had disabled the Winsock IP_TOS option. If you used this socket option, the call would succeed but be ignored silently. You could re-enable it through a registry value. In Vista, this registry mechanism has been removed: Winsock IP_TOS option is no longer available."
Does JmDNS 3.4.1 support IPv6? when I register a service with an IPv4 I can see it on other machines, but if I use an interface with an IPv6 address, I don't :(
Also, I get
No support for IPv6 in jSLP yet (see https://bugs.eclipse.org/328074), skipping interface...
does JmDNS use SLP?
In some environments such as Java, it's natural to use TCP/IP sockets to pass messages between processes on the same host using the 'localhost' address (127.0.0.1 in IPv4, or ::1 in IPv6). (Because Java tends not to expose other IPC mechanisms in its API).
Clearly, this has the potential to be a lot slower than IPC via message passing over pipes, or IPC using shared-memory.
On the other hand, if the TCP/IP networking stack realised that both ends of the connection were on the loopback interface, it might be able to do a fair bit of optimisation so that the efficiency might not differ much from using pipes.
But do common operating systems (Windows, Linux) implement such optimisations in their TCP/IP stacks?
Yes. When a packet/data to a Loopback address(127.x.x.x) is received, the IP layer of the TCP/IP uses the Loopback route to route the packet to itself.
Looback Route
Network Destination || Netmask ||
Gateway || Interface || Metric
127.0.0.0 |||||||||||||||||||||| 255.0.0.0 || 127.0.0.1|| 127.0.0.1 || 1
After routing it to itsef, at TCP/UDP layer with the help of protocol control blocks(per connection data structure) the corresponding socket and its owner process will be identified to deliver the packet/data.
Bottom line, All the tasks at Data Link layers and Physical layers(of OSI Model) will be avoided.
Depends upon the OS, and the configuration being used. The answer is yes if you are asking for default behavior.
This is the reason why you are not able to use tools like wireshark to sniff local loopback scenarios.
[Edit from another user]: Actually, this is possible, you have to choose the Loopback interface (Testing with Wireshark 3.4)
Specifically in linux when packets are transmitted on the loopback interface the kernel raises a "software" interrupt for each packet. From that point on the packet reception is identical to the packet reception flow for a physical device. So you are correct in your assumption that communication over the loopback interface would be much slower than alternate IPC mechanisms such as unix sockets.
I guess the kernel code path can be optimized. For e.g., we could call the receive code path directly from the transmit code path of loopback interface.