Preferring internal IPv6 source address over gif tunnel IP?

Artem Viklenko artem at viklenko.net
Wed Jul 31 12:56:14 UTC 2019


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!


More information about the freebsd-net mailing list