Preferring internal IPv6 source address over gif tunnel IP?

[Viktor Dukhovni]

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.