From owner-freebsd-net@freebsd.org Wed Jul 31 12:56:14 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 CB3DCBDE15 for ; Wed, 31 Jul 2019 12:56:14 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from alf.viklenko.net (alf.viklenko.net [IPv6:2001:470:71:d72::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.viklenko.net", Issuer "Art&Co. CA Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 45zD254TdWz3JYn for ; Wed, 31 Jul 2019 12:56:13 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from [10.0.31.12] (ua1.etadirect.net [91.198.140.16] (may be forged)) (authenticated bits=0) by alf.viklenko.net (8.15.2/8.15.2) with ESMTPSA id x6VCttTO081417 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2019 15:55:59 +0300 (EEST) (envelope-from artem@viklenko.net) Subject: Re: Preferring internal IPv6 source address over gif tunnel IP? To: Viktor Dukhovni , freebsd-net@freebsd.org References: <20190731120726.GD24255@straasha.imrryr.org> From: Artem Viklenko Organization: Art&Co. Message-ID: Date: Wed, 31 Jul 2019 15:55:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190731120726.GD24255@straasha.imrryr.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (alf.viklenko.net [192.168.32.61]); Wed, 31 Jul 2019 15:55:59 +0300 (EEST) 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:56:14 -0000 Hi! You can set option "deprecated" at your gif0 interface. gif0: flags=8051 metric 0 mtu 1480 inet6 YYYY:YYY:YYY:YYY::2 --> YYYY:YYY:YYY::1 prefixlen 128 deprecated Works for me. On 31.07.19 15:07, Viktor Dukhovni wrote: > > 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. > -- Regards!