SixXS::Sunset 2017-06-06

Tunnel + DSCP
[de] Shadow Hawkins on Sunday, 24 February 2013 12:31:23
When I send IPv6-Packets with DSCP-Bits through the SiXXS IPv6-in-IPv4 static Tunnel, they appears with cleared DSCP-Bits at the other side. Is this behavior intentionally?
Tunnel + DSCP
[ch] Jeroen Massar SixXS Staff on Sunday, 24 February 2013 15:03:42
Can you provide a lot more details? How do these packets look like, which path are packets taking,
Tunnel + DSCP
[de] Shadow Hawkins on Sunday, 24 February 2013 16:33:11
This packet goes into the Tunnel: 17:28:26.944442 IP6 (class 0x4a, hlim 62, next-header TCP (6) payload length: 80) 2001:6f8:12ec:11:224:7eff:fe12:2b45.48829 > 2a01:238:42c8:7b00::21:1.22: tcp 48 And receives the destination: 17:28:26.967257 IP6 (class 0x02, hlim 55, next-header TCP (6) payload length: 80) 2001:6f8:12ec:11:224:7eff:fe12:2b45.48829 > 2a01:238:42c8:7b00::21:1.22: tcp 48 As you can see the class is changing from 0x4a to 0x02 due to clearing the DSCP Bits.
Tunnel + DSCP
[ch] Jeroen Massar SixXS Staff on Sunday, 24 February 2013 17:30:55
Any hop along the path could have changed that. sixxsd does not touch it. I have not heard of any networks that would be rewriting them yet either though. You might want to try with a tracepath while setting the DSCP for those and then tcpdumping the packets, looking inside the ICMP replies to see if the result was modified or not, that should allow you to see where the packet might get modified.
Tunnel + DSCP
[de] Shadow Hawkins on Monday, 25 February 2013 05:42:31
Good hint. It seems that the Hostingprovider clears the DSCP-Bits. I'll ask him.

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker