From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 13FBE21F3EA for ; Thu, 29 May 2014 13:54:46 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so22043wib.0 for ; Thu, 29 May 2014 13:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eq/kRbRXA45DqW1hRYvlH9kQzuMQZcRHuKWIQPWw9uc=; b=WSZZ83mFVZkvvyT7K/HTJluJKFXcqjb6qElykC1trylSYv52wWgJQoqDMpE7dabU24 2FN0Va79OOFGjSCfShhbrseGLQCo6zGZMT33g79U7cHZg4Cg6DoWnNZKb5QgDUNuBGDd DyR4fOHDy7GO6wqBo3BQA7dKTcIyqnf95J7iB0mveaaChyc8DaMygOJl6WXIIXboywqm /55NyNQ8iOisoRVz2x+3ytpJ5wYEAYuDm/fgOj7rgtaKs4N8ri0ASnKYjq5u0J2D4tXK 1h7qgfkHrRWxct6E3+bcpJcd1iq4/IS4b/LQ4kysFvwO0yW2+fw+TltwmEsuY8yMRCSs vxXw== MIME-Version: 1.0 X-Received: by 10.180.19.201 with SMTP id h9mr15243335wie.17.1401396884091; Thu, 29 May 2014 13:54:44 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Thu, 29 May 2014 13:54:44 -0700 (PDT) Date: Thu, 29 May 2014 13:54:44 -0700 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] possible ipv6 path mtu issue, address assignment, and dhcpv6 renews X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:54:47 -0000 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. --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article