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!
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
