Date: Wed, 31 Jul 2019 15:55:55 +0300 From: Artem Viklenko <artem@viklenko.net> To: Viktor Dukhovni <ietf-dane@dukhovni.org>, freebsd-net@freebsd.org Subject: Re: Preferring internal IPv6 source address over gif tunnel IP? Message-ID: <b70edcb4-763f-3035-8c82-09b128451701@viklenko.net> In-Reply-To: <20190731120726.GD24255@straasha.imrryr.org> References: <20190731120726.GD24255@straasha.imrryr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! You can set option "deprecated" at your gif0 interface. gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> 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 <my-public-ipv4> <their-tunnel-ipv4>" > ifconfig_gif0_ipv6="inet6 <tunnel-prefix>::2 <tunnel-prefix>::1 prefixlen 128" > ipv6_defaultrouter="<tunnel-prefix>::1" > > 2. A /64 for my network: > > ipv6_network_interfaces="igb1" > ifconfig_igb1_ipv6="inet6 <my-network>::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 <my-network>::1, not <tunnel-prefix>::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 "<my-network>::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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b70edcb4-763f-3035-8c82-09b128451701>