JDK-7169676 : setTrafficClass() doesn't work on packets sent from IPv6 Socket connected to a v4 mapped v6 address
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: generic
  • Submitted: 2012-05-17
  • Updated: 2024-05-27
  • Resolved: 2024-05-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Duplicate :  
Description
SYNOPSIS
--------
Socket.setTrafficClass() does not work for packets sent from an IPv6 Socket connected to a IPv4 mapped IPv6 address

OPERATING SYSTEM
----------------
Linux

FULL JDK VERSIONS
-----------------
All

PROBLEM DESCRIPTION
-------------------
The current implementation of Socket.setTrafficClass() does the following on an IPv6 enabled Linux system:
 
1. Call NET_SetSockOpt with IP_TOS.
2. If the system is IPv6 enabled, enable IPV6_FLOWINFO_SEND on the
   socket.
3. Set sin6_flowinfo field of the connecting IPv6 address at the time of
   connection with the trafficClass already set by the user.

However, this flow does not set the TOS value of packets sent from an IPv6 Socket connected to a IPv4 mapped IPv6 addresses.

According to the team in our Linux Technology Centre, a socket created with AF_INET6 family and bound to a IPv4 mapped IPv6 address continues to send IPv4 packets only. So, setsockopt() needs to be used to enable TOS on the packets dispatched even if the socket is a IPv6 socket.

TESTCASE
--------
import java.net.*;
import java.util.*;

public class tosTest {
    public static void main(String[] args) throws Exception {

        if (args.length != 2) {  // Test for correct # of args
            args = new String[]{"localhost","6000"};
        }

        InetAddress destAddr = InetAddress.getByName(args[0]);  // Destination address
        int destPort = Integer.parseInt(args[1]);               //Destination port
        System.out.println("Client try to connect to : " + destAddr + "@" + destPort);
        Socket sock = new Socket();
        sock.setTrafficClass(28);
        sock.connect(new InetSocketAddress(destAddr, destPort));
        System.out.println("after set and connect getTrafficClass: " + sock.getTrafficClass());
        byte[] array = new byte[]{1,2,3,4,5,6,7,8,9};

        while (true) {
            System.out.println("in write loop getTrafficClass: " + sock.getTrafficClass());
            sock.getOutputStream().write(array);
            System.out.println("client write : " + Arrays.toString(array));
            Thread.sleep(5000);
        }
    }
}

Output from tcpdump tool:

06:33:58.278111 IP (tos 0x0, ttl  64, id 5977, offset 0, flags [DF], proto: TCP (6), length: 61) linos.in.ibm.com.52754 > ibm-ai71o7pp6o5.in.ibm.com.6000: P, cksum 0xd27e (incorrect (-> 0x9b39), 18:27(9) ack 13 win 46 <nop,nop,timestamp 2680373519 7545518>
06:34:03.282344 IP (tos 0x0, ttl  64, id 5978, offset 0, flags [DF], proto: TCP (6), length: 61) linos.in.ibm.com.52754 > ibm-ai71o7pp6o5.in.ibm.com.6000: P, cksum 0xd27e (incorrect (-> 0x9461), 27:36(9) ack 13 win 46 <nop,nop,timestamp 2680374770 7546010>

WORKAROUND
----------
Enable IPv4 Stack.

Comments
Fixed by JDK-8072384
21-05-2024

More information on the ToS can be found here: http://download.java.net/jdk8/docs/api/java/net/StandardSocketOptions.html#IP_TOS
11-09-2013

The traces in the evaluation appear to be IPv6 traffic whereas the bug report is when an IPv6 socket is connected to an IPv4-mapped IPv6 address -- ie: IPv4 traffic.
17-04-2013

I built a TCP server and the example program and traced the packet flow with tcpdump. The TOS parameters looked correct. I didn't see any checksum errors either.
17-04-2013

I can't reproduce this. Perhaps I'm overlooking something? I built a TCP server and the Test Case program. (I ran both the client and the server on the same host.) I captured the traffic with tcpdump. This is what I see: 17:52:26.813240 IP6 fe80::20c:29ff:fe13:3505.36214 > fe80::20c:29ff:fe13:3505.6000: Flags [S], seq 2590703704, win 32752, options [mss 16376,sackOK,TS val 29109457 ecr 0,nop,wscale 4], length 0 17:52:26.813271 IP6 fe80::20c:29ff:fe13:3505.6000 > fe80::20c:29ff:fe13:3505.36214: Flags [S.], seq 1885922358, ack 2590703705, win 32728, options [mss 16376,sackOK,TS val 29109457 ecr 29109457,nop,wscale 4], length 0 17:52:26.813285 IP6 fe80::20c:29ff:fe13:3505.36214 > fe80::20c:29ff:fe13:3505.6000: Flags [.], ack 1, win 2047, options [nop,nop,TS val 29109457 ecr 29109457], length 0 17:52:26.816405 IP6 fe80::20c:29ff:fe13:3505.36214 > fe80::20c:29ff:fe13:3505.6000: Flags [P.], seq 1:10, ack 1, win 2047, options [nop,nop,TS val 29109457 ecr 29109457], length 9 17:52:26.816548 IP6 fe80::20c:29ff:fe13:3505.6000 > fe80::20c:29ff:fe13:3505.36214: Flags [.], ack 10, win 2046, options [nop,nop,TS val 29109457 ecr 29109457], length 0 17:52:31.817753 IP6 fe80::20c:29ff:fe13:3505.36214 > fe80::20c:29ff:fe13:3505.6000: Flags [P.], seq 10:19, ack 1, win 2047, options [nop,nop,TS val 29110708 ecr 29109457], length 9 17:52:31.818183 IP6 fe80::20c:29ff:fe13:3505.6000 > fe80::20c:29ff:fe13:3505.36214: Flags [.], ack 19, win 2046, options [nop,nop,TS val 29110708 ecr 29110708], length 0 17:52:36.818717 IP6 fe80::20c:29ff:fe13:3505.36214 > fe80::20c:29ff:fe13:3505.6000: Flags [P.], seq 19:28, ack 1, win 2047, options [nop,nop,TS val 29111958 ecr 29110708], length 9 17:52:36.819886 IP6 fe80::20c:29ff:fe13:3505.6000 > fe80::20c:29ff:fe13:3505.36214: Flags [.], ack 28, win 2046, options [nop,nop,TS val 29111958 ecr 29111958], length 0 17:52:41.820006 IP6 fe80::20c:29ff:fe13:3505.36214 > fe80::20c:29ff:fe13:3505.6000: Flags [P.], seq 28:37, ack 1, win 2047, options [nop,nop,TS val 29113208 ecr 29111958], length 9 17:52:41.820234 IP6 fe80::20c:29ff:fe13:3505.6000 > fe80::20c:29ff:fe13:3505.36214: Flags [.], ack 37, win 2046, options [nop,nop,TS val 29113208 ecr 29113208], length 0
16-04-2013

WORK AROUND Set the following system property, '-Djava.net.preferIPv4Stack=true'
21-06-2012

EVALUATION Seems like a reasonable request. We just need to implement the suggestion and validate the results. Also, determine the behavior on Solaris.
21-06-2012