> I will definitely may do this, as it it will become a test case for tcpdump. > [just so you realize I'm the tcpdump maintainer :-)]
:O Is blending tcpdump and NAT64 the intended purpose of this experiment? On Wed, Aug 5, 2015 at 12:21 PM, Michael Richardson <[email protected]> wrote: > > Alberto Leiva <[email protected]> wrote: > >> I have a scenario where I'm trying to use Jool along with an > >> IP6-in-IPv4 (ESP/IPsec) tunnel. > > > Ok; as long as the packet is decrypted before reaching Jool I don't > > think there's anything strange about this. > > >> Packet #2 is odd, and something I'm investigating on the tcpdump side > >> of things; it's the the IP6 packet coming out of the tunnel. > > > I'm not very familiarized with the IPSec protocol, but if you dump this > > into a pcap file, maybe I can help with this. > > I will definitely may do this, as it it will become a test case for tcpdump. > [just so you realize I'm the tcpdump maintainer :-)] > > >> I can't see why it would be fragmented, given that it's 64-bytes. > >> Bug? > > > Yes, sort of: It's an atomic fragment > > (https://www.jool.mx/usr-flags-atomic.html). Jool felt the need to > > include a redundant fragment header because of a combination of the DF > > flag and the packet length. It's something RFC 6145 wants but it's > > currently being deprecated. > > > Indeed, Jool 3.3 catched up with this fact and handles atomic fragments > > better (by which I mean, it avoids them). It you upgrade, the redundant > > fragment header should go away. > > Thanks, I haven't gotten to the update process, maybe later this afternoon. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > _______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
