0x0000: 4500 0063 0000 4000 4029 f09e 465b 910a E..c..@.@)..F[.. 0x0010: d133 a13a 6000 0000 0027 113f 2001 0470 .3.:`....'.?...p 0x0020: d846 0000 0000 0000 0000 0002 2001 06b0 .F.............. 0x0030: 0007 0000 0000 0000 0000 0002 b4f7 0035 ...............5 0x0040: 0027 b05d e36c 0010 0001 0000 0000 0001 .'.].l.......... 0x0050: 0262 6700 0030 0001 0000 2910 0000 0080 .bg..0....)..... 0x0060: 0000 00 ... describe this packet as complete as possible, but fit the result in to a twitter message. --- solution: Here is the "solution". First the quick summary: The packet is an IPv6 over IPv4 packet. The payload is a UDP DNS query for the .bg (Bulgaria) DNS Key record. It uses EDNS0 advertising a possible UDP return length of 4096 bytes. Here the details: 0x0000: 4500 0063 0000 4000 4029 f09e 465b 910a E..c..@.@)..F[.. 0x0010: d133 a13a IP Version 4 IP Header Length 20 Bytes (5 * 4) TOS Byte: 0 Datagram Length: 0x63 ( 99 Bytes) IP ID: 0 (normal if DF flag is set) Flags: DF flag set Fragmentation Offset: 0 TTL: 0x40 (decimal 64. Likely captured at the source... as far as the IPv4 header is concerned, the source is the firewall / tunnel endpoint. Protocol: 0x29 ( decimal 41, or IPv6 over IPv4 ) Checksum: f09e.. should be correct. I didn't check it ;-) Source IP: 465b910a - 70.91.145.10 (my external IP address) Destination IP: d133a13a - 209.51.161.58 . Resolves to tserv12.mia1.ipv6.he.net . he.net (Hurricane Electric, aka tunnelbroker.net is a free tunneling service I use. Highly recommended) Next we got the embedded IPv6 packet to analyze 6000 0000 0027 113f 2 Version: 6 Traffic Class: 0 Flow Label: 0 Payload Length: 0x27 (39 Bytes) Next Header: 0x11 (Decimal 17, UDP) Hop Limit: 0x3f ... decimal 64 not 64 ;-)... the packet went one hop to read the tunnel. Next the IPv6 addresses 2001 0470 0x0020: d846 0000 0000 0000 0000 0002 2001 06b0 .F.............. 0x0030: 0007 0000 0000 0000 0000 0002 2001:0470:d846::2 - my DNS server I should setup a reverse DNS entry for it. But dig will tell you it is mine: dig -x 2001:0470:d846::2 ; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 2001:0470:d846::2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25376 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.4.8.d.0.7.4.0.1.0.0.2.ip6.arpa. IN PTR ;; AUTHORITY SECTION: 0.0.0.0.6.4.8.d.0.7.4.0.1.0.0.2.ip6.arpa. 3600 IN SOA ns1.dshield.org. info.dshield.org. 2009010501 7000 3600 604800 86400 Note that the answer is NXDOMAIN, but the authority section for 2001:0470:d846/48 is ns1.dsheld.org ... resolve ns1.dshield.org ;-) dig +short AAAA ns1.dshield.org 2001:470:d846::2 and you got the IP address The target IP address: 2001:6b0:7::2 dig +short -x 2001:6b0:7::2 sunic.sunet.se. Swedish / Sunet... big well known network. Note that the source address is a regularly assigned IPv6 address, not an auto configured 6to4 address (would start with 2001:). One response suggested ISATAP. ISATAP is intranetwork only and would use fe80/12 addresses. Teredo as another tunneling mechanism would include an IPv4 UDP header and a 2001:0:/32 address But now the "meat", the UDP header and DNS payload: b4f7 0035 ...............5 0x0040: 0027 b05d source port: 0xb4f7 - some high port. dest. port: 0x35 ( 53 decimal ) UDP Length: 0x27 (39... note this sis the same as the length in the IPv6 header. The IPv6 header only shows the payload length not including the header) UDP Checksum: b05d ... again, lets believe it is right. Finally the DNS payload: e36c 0010 0001 0000 0000 0001 .'.].l.......... Query ID: 0xe36c flags: 0010 Query / Response flag: 0 - its a query Opcode: 0 - standard query (4 bits) Authoritative answer: no... its a query Truncation flag: no... its a query Recursion Desired: yes! Zero: 3 bits.. always zery Response Code: 0 ... no error Question Count: 0001 - one question Answer Count: 0 NS Count: 0 Additional Record Count: 1 - this is a bit odd about a query. but more later. 0x0050: 0262 6700 0030 0001 0000 2910 0000 0080 .bg..0....)..... 0x0060: 0000 00 our query: 02 62 67 00... 'bg' (Bulgaria) question type: 0x30 ( decimal 48. this is a DNSKEY query, asking for the DNSSEC Key for the .bg zone) Class: 0x0001 (IN... "Internet" ) Next we got the "Additional Record": 00 00 - empty name type: 29 (Decimal 41)- This is an "Option". So it is not an actual resource record, but we use it to communicate additional options 41 is used in particular for a "EDNS-0". The next two bytes will tell us how much data our host is willing to accept via UDP: 0x1000 : 4096 Bytes instead of the normal 512. This is typical for DNS servers supporting DNSSEC or IPv6 to allow for the larger answers common with IPv6 and DNSSEC rcodes and flags: 00 - nothing set 0x8000: The 'DO' bit is set... our server accepts DNSSEC 0x00: Length: 0. BTW: you will be able to find the packet and the solution here to share... http://sǝuuɐɥoɾ.com/packet1.txt The new packet (once I picked it) will be here: http://sǝuuɐɥoɾ.com/packet.txt