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
signature.asc
Description: OpenPGP digital signature
