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

[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@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

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

[Dave Taht]

On Thu, May 29, 2014 at 1:54 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 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.

I disabled the tunnel and now 1514 byte ipv6 packets do get through.
It's rather unclear why the lower tunnel mtu was causing problems
though...

>
> 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...

It looks like dhclient6 on the host gets wedged somehow and this
isn't a cerowrt problem.

I filed a bug on it here.

http://www.bufferbloat.net/issues/443

If your underlying ipv6 address changes and you get stuck with
an old one, or an old one keeps coming back, well...

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

by this, I meant, not seeing them in the web interface.

Another problem is I'm not getting a default route from ras for some reason.
Sigh.



> --
> Dave Täht
>
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article



-- 
Dave Täht

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