Preferring internal IPv6 source address over gif tunnel IP?

[Marek Zarychta]

W dniu 31.07.2019 o 14:07, Viktor Dukhovni pisze:
> 
> 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.
> 
Setting source address for MTA will be sufficient in this case. For
example Sendmail requires ClientPortOptions to be set in .mc config file:

CLIENT_OPTIONS(`Family=inet6, Addr=<my-network>::1')

-- 
Marek Zarychta

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20190731/c3719911/attachment.sig>