From owner-freebsd-net Sat Jul 20 20:33:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E044D37B400 for ; Sat, 20 Jul 2002 20:33:23 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09B9943E31 for ; Sat, 20 Jul 2002 20:33:23 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g6L3XAwr041931 for ; Sat, 20 Jul 2002 20:33:14 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200207210333.g6L3XAwr041931@gw.catspoiler.org> Date: Sat, 20 Jul 2002 20:33:10 -0700 (PDT) From: Don Lewis Subject: disabling IPv6 *without* recompiling the kernel To: net@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've run into the same problems with Mozilla that many other people have reported. Even though I'm on an IPv4 only network, I'm seeing DNS lookups for AAAA records, many of which are timing out due to problems with the authoritative DNS servers. I'm also seeing long pauses when Mozilla attempts to connect to various web sites which I suspect are caused by Mozilla's attempts to connect to unreachable IPv6 addresses. The only reported solution is to recompile the kernel without the INET6 option, but this seems to be a pretty inconvenient workaround. It doesn't seem reasonable to require the large number of users who are connected to IPv4 only networks to compile custom kernels. This workaround is expecially inconvenient for mobile users who may migrate between network types and for users who might want to test IPv6 on their private networks but only have IPv4 connectivity to the outside world. While the Mozilla port doesn't currently use getipnodebyname(), it uses an equivalent algorithm to decide whether query for IPv4 or IPv6 addresses. Our implementation of getipnodebyname() contains the comment: /* * TODO: * Note that implementation dependent test for address * configuration should be done everytime called * (or apropriate interval), * because addresses will be dynamically assigned or deleted. */ but the test implemented in the code is just seeing whether socket(AF_INET6, SOCK_DGRAM, 0) succeeds. The problem is that this test always succeeds if the kernel is compiled with the INET6 socket even though ipv6_enable is set to "NO" in rc.conf and none of the interfaces have been configured with IPv6 addresses. This test is broken even in the static case. Should it be possible to create AF_INET6 sockets if none of the interfaces have been configured with IPv6 addresses? Is the ability to create AF_INET6 sockets the proper way to determine whether to query for IPv6 DNS records, or should there be some other method of determining this information? By default, all the interfaces get IPv6 addresses assigned even when ipv6_enable is set to "NO". Ethernet interfaces get link local addresses if net.inet6.ip6.auto_linklocal is left at it's default value of "1". Shouldn't this sysctl be set according to the value of ipv6_enable or some other configuration knob? The loopback interface unconditionally gets the IPv6 address assigned by in6_ifattach(). This is different than the IPv4 case, which requires the address to be assigned with ifconfig, and it also has problems if there are multiple loopback interfaces as noted by the XXX comment in the code. Ideally, getipnodebyname() should have some sort of fine grained control to tell it when it should query for and return IPv6 addresses so that the client doesn't waste a lot of time doing useless DNS lookups and attempting to connect to obviously unreachable addresses. In the mean time it would be nice to have an implemenation that wasn't so badly broken for the most common environment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message