Weird ISR accounting in 10-STABLE

[Ben Morrow]

Quoth Vlad Galu <galu at packetdam.com>:
> On Thu, Jul 10, 2014 at 9:56 PM, Vlad Galu <galu at packetdam.com> wrote:
> >
> > Good catch, why didn't I think of that earlier! I can see a lot of IPv6
> > traffic that I can't really explain. Since I was running pf with synproxy I
> > disabled pf altogether, but that did not improve things. Here is a snapshot
> > (source IP address edited):
> >
> > -- cut here --
> > 22:52:40.195950 IP6 A:B:C:D:E::1000.62571 > ::10.31.31.153.12132: Flags

The second address here is an 'IPv4-compatible IPv6 address', which are
not these days considered to be useful. See RFC 4291 section 2.5.5.1.

I suspect the process which owns A:B:C:D:E::1000.62571 is playing silly
games of some sort; possibly it's making Linux-based assumptions about
the behaviour of dual-stack hosts which don't apply on BSD.

> It was a routing loop! I kept seeing lots of identical SYN packets. I
> somehow ended up with this v6 table entry:
> -- cut here --
> Routing tables
> 
> Internet6:
> 
> Destination                       Gateway                       Flags
> Netif Expire
> 
> ::/96                             ::1                           UGRS
> lo0

This is a correct route, and will not cause a routing loop. It's also
*not* the same as the IPv6 loopback route (as someone else said); that
route looks like

    ::1     link#2      UH      lo0

and should also be present (the link number might be different,
obviously).

The 'R' flag means 'reject': because these addresses are not useful,
there should be a routing table entry to ensure packets addressed to
them get thrown away rather than sent out on the wire. You need to find
out why they are being generated in the first place.

Ben