Date: Wed, 31 Jul 2019 08:07:27 -0400 From: Viktor Dukhovni <ietf-dane@dukhovni.org> To: freebsd-net@freebsd.org Subject: Preferring internal IPv6 source address over gif tunnel IP? Message-ID: <20190731120726.GD24255@straasha.imrryr.org>
next in thread | raw e-mail | index | archive | help
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. -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190731120726.GD24255>