[Jool-list] returned IPv6 packets

[Alberto Leiva]

> 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 <mcr at sandelman.ca> wrote:
>
> Alberto Leiva <ydahhrk at gmail.com> 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  [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>