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