From owner-freebsd-net@freebsd.org Wed Jul 31 12:07:08 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25A48BCDC0 for ; Wed, 31 Jul 2019 12:07:08 +0000 (UTC) (envelope-from viktor@dukhovni.org) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45zBxR0rjRz3G53 for ; Wed, 31 Jul 2019 12:07:06 +0000 (UTC) (envelope-from viktor@dukhovni.org) Received: by straasha.imrryr.org (Postfix, from userid 1001) id CBC2647039; Wed, 31 Jul 2019 08:07:05 -0400 (EDT) Date: Wed, 31 Jul 2019 08:07:05 -0400 From: Viktor Dukhovni To: freebsd-net@freebsd.org Subject: Preferring internal IPv6 source address over gif tunnel IP? Message-ID: <20190731120705.GC24255@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.4 (2019-03-13) X-Rspamd-Queue-Id: 45zBxR0rjRz3G53 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of viktor@dukhovni.org designates 100.2.39.101 as permitted sender) smtp.mailfrom=viktor@dukhovni.org X-Spamd-Result: default: False [0.20 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:100.2.39.101]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dukhovni.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.17)[asn: 701(0.88), country: US(-0.05)]; RCVD_IN_DNSWL_MED(-0.20)[101.39.2.100.list.dnswl.org : 127.0.6.2]; MX_GOOD(-0.01)[smtp.dukhovni.org]; NEURAL_HAM_SHORT(-0.45)[-0.454,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:701, ipnet:100.2.0.0/16, country:US]; MIME_TRACE(0.00)[0:+] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 12:07:08 -0000 My FreeBSD machine is also my router, and for lack IPv6 support by Verizon, now uses a "gif" tunnel via Hurricane Electric. HE provides me with two prefixes: 1. Point to point tunnel /128: cloned_interfaces="gif0" create_args_gif0="tunnel " ifconfig_gif0_ipv6="inet6 ::2 ::1 prefixlen 128" ipv6_defaultrouter="::1" 2. A /64 for my network: ipv6_network_interfaces="igb1" ifconfig_igb1_ipv6="inet6 ::1 prefixlen 64" They support DNS reverse resolution delegation for "my-network" (the /64), but not the point-to-point "tunnel-prefix" (the /128). Since a bunch of my traffic is SMTP, I need reverse resolution for outgoing IPv6, which means that I need the outgoing sources address to be ::1, not ::2, even though the routing table lists "gif0" as the interface with the default route. Is it possible to configure my system to use the internal /64 address as the default source address of outgoing IPv6 packets? If it would help, I can assign the "::1" address to the external physical network interface (same one that has the tunnel v4 address) or the loopback interface... RFC3484 section4 hints at such possibilities (https://tools.ietf.org/html/rfc3484#page-9): It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below. Discussion: The Neighbor Discovery Redirect mechanism [14] requires that routers verify that the source address of a packet identifies a neighbor before generating a Redirect, so it is advantageous for hosts to choose source addresses assigned to the outgoing interface. Implementations that wish to support the use of global source addresses assigned to a loopback interface should behave as if the loopback interface originates and forwards the packet. Or could I assign an explicit non-global scope to the tunnel address? Or ... (whatever works). Any help much appreciated. -- Viktor. I used to use 6to4 with stf0, but it seems that 6to4 is deprecated, and the standard anycast address I was using for the gateway seems has recently become unreachable.