On Wed, 20 Aug 2014, Charles Musser wrote:


On Aug 20, 2014, at 4:15 AM, Ed Hynan <eh_l...@optonline.net> wrote:

On Tue, 19 Aug 2014, Charles Musser wrote:


- <prefix>::1 is the local address of the interface on the IPv6
network.

No, *::2 is local.
Ah, yes. Despite my best efforts at copyediting, I had the meanings of  *::1 and
*::2 reversed.


- The "alias" parameter is superfluous in this case. I tried it without
that and got the same result: an operating tunnel.

If it works, ifconfig is being smart, but why not make your intent
explicit? The tunnel is across the ip4 addresses; this command adds
aliases, or close enough.
Stated another way: the alias keyword doesn't do any harm here, but
using it makes things harder to understand because this isn't actually an
alias; it's a local address and a remote address and this pair comprises
the endpoints of a point-to-point link.

Although this is a little more complex on gif than e.g. an ethernet interface,
alias is at least similar. On a more straightforward type interface, alias
is used adding additional addresses (BTW, not OpenBSD specific, the alias
keyword is similar for {Net,Free}BSD; and, apparently dissimilar on Linux).
Think of the IPv6 addrs as 'additional' after IPv4 tunnel addrs for
conceptual satisfaction.


It's ambiguous when you write "the server IP" because the remote end
of the tunnel is a server, and if you're configuring a router rather
than a host then that's a server too. Addr *:2 is local in that it's
an address of your gif(4) interface.  The ifconfig(8) synopsis is
simpler than gif configuration, but yes *::2 is like "dest_address".
Just to clarify, this setup is currently a host, not a router. Given all that,
::2 is the local address and ::1 is remote. Doesn't that make ::1 the
"dest_address"?

Note: possible beating of dead horse here. Feel free to say: "stop
obsessing over the syntax of this command, dummy."

<grin> Yes, *::1 is like dest_address; I miswrote and should have said
*::2 is like "address" in the synopsis (had just woke up).  IAC *::2
is local, software on the machine may have that as source address,
not *::1.


Addr *::1 is remote. Try 'netstat -nvrf inet6 | grep 2001:' and find
that *::1 has the G (gateway) flag, and host *::2 has a route to *::1.
Output of that is:

default                            2001:470:1f04:204::1           UGS        6  
    146     -     8 gif0
2001:470:1f04:204::1               2001:470:1f04:204::2           UH         1  
      0     -     4 gif0
2001:470:1f04:204::2               link#6                         UHL        0  
      0     -     4 lo0

This is different than what you describe, but it makes sense. I think.

Is it different?  Your output shows what I intended to describe.
Line 1 with G flag shows that 'gateway' addr *::1 is default route
and line 2 with H flag shows 'host' addr *::2 has/is a route to *::1
(didn't I suggest that clearly on my 1st coffee? I think I did).


Also look at something using the interface, maybe ntpd. Look at the
address with 'netstat -nvf inet6 | grep 123' (no -r there), and
see that *::2 is local.
Output is:

Active Internet connections
Proto   Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6         0      0  2001:470:1f04:204::2.32069 
2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED
tcp6         0      0  2001:470:1f04:204::2.44447 
2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED
tcp6         0      0  2001:470:1f04:204::2.30221 
2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED
tcp6         0      0  2001:470:1f04:204::2.3173 
2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED
tcp6         0      0  2001:470:1f04:204::2.27980 
2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED
tcp6         0      0  2001:470:1f04:204::2.48945 
2001:200:dff:fff1:216:3eff:feb1:44d7.80 ESTABLISHED

This seems to confirm what you said. The local endpoint is indeed *::2.

Looks good.  Since this is a host never mind rtadvd (I had mentioned
that).  You'll want to handle IPv6 in pf generally.  Since you
didn't mention it I suppose you're not strictly firewalling; you
would have mentioned allowing proto 41 for the ip4 remote endpoint
or maybe you've got that all set.

-Ed

--
Today's weirdness is tomorrow's reason why.
-- Hunter S. Thompson

Reply via email to