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@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
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
