[Cerowrt-devel] possible ipv6 path mtu issue, address assignment, and dhcpv6 renews

[Dave Taht]

I've had a couple reports of "slowness" on native ipv6, and possibly
there is some sort of path mtu issue being forced, by something.

What I am seeing is ipv4 "bytes on the wire" is 1514, but
native ipv6 "bytes on the wire" is 1494, according to wireshark.

Any attempt to send a "native" 1514 size tcp packet gets an ETOOBIG
icmp response. (In an age of short tcp transactions this is bad)

The topology is host - cero1 - cero2 - internet

There is a he tunnel (mtu 1480) and comcast on the link I'm testing,
and the ETOOBIG is coming from the internal interface of cero2. I will
disable the tunnel there... but arguably, using source specific
routing, it should only be stuff being forwarded through the tunnel
that would give that error... and this happens before it gets to the
tunnel.

The second thing I'm seeing periodically, for no reason I can tell, is that
I'm getting an address on a network that doesn't exist on that host.

d at nuc:~$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr ec:a8:6b:fe:09:a2
          inet addr:172.26.4.20  Bcast:172.26.4.31  Mask:255.255.255.224
          inet6 addr: fe80::eea8:6bff:fefe:9a2/64 Scope:Link
          inet6 addr: 2601:9:6680:4aa::3ce/64 Scope:Global
                             exists
          inet6 addr: 2601:9:6680:56a::3ce/64 Scope:Global
                             doesn't exist

Could be some other device on the link supplying it, but doesn't seem so.
I will keep monitoring radvdump...

The third, is like others here, I'm not seeing dhcpv6 renews work.

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article