Re: ifconfig command for IPv6 tunnel
Also, do note that this just means that this particular box has ipv6 connectivity. If you want to have clients at home behind this one, you should get another v6 network to use behind this gateway. And I agree with Adam, you got most of it correct. I would add the route command to hostname.gif0 with the ! before so it is used only when gif0 is taken up. 2014-08-20 6:38 GMT+02:00 Adam Thompson athom...@athompso.net: On 14-08-19 10:40 PM, Charles Musser wrote: I'm experimenting with using IPv6 via a tunnel broker provided by an ISP. The tunnel works, but I want to confirm my understanding of the commands they gave me to set it up. These are the commands: ifconfig gif0 tunnel 50.1.94.112 72.52.104.74 ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen 128 route -n add -inet6 default 2001:470:1f04:204::1 [...] IIRC from my experimentation, you've got it exactly right. Some tunnel brokers give you subnet masks that certain versions of OpenBSD don't like - that turns out to not actually matter, just use whatever ifconfig(8) want. Point in case: HE recommends using /64 for PtP links, but OpenBSD 5.x requires /128. Since HE allocates an entire /64 per tunnel, there is no danger in configuring it more narrowly on the client end. The hostname.if(5) syntax that finally worked for me on 5.4-RELEASE was (slightly anonymized) description HE_TUNNEL_FREMONT tunnel 184.70.48.XXX dest 64.71.128.83 inet6 2001:470::X::2 dest 2001:470::X::1 prefixlen 128 which perhaps adds some clarity, or perhaps confuses, depending on your point of view. I can't remember whether (in the non-BGP case) I added the route command as !route -n add -inet6 default 2001:470:1f04:204::1 to the hostname.gif0 file, or if I added it to /etc/mygate - one or the other should work, anyway. -- -Adam Thompson athom...@athompso.net -- May the most significant bit of your life be positive.
Re: ifconfig command for IPv6 tunnel
On Tue, 19 Aug 2014, Charles Musser wrote: Hi, I'm experimenting with using IPv6 via a tunnel broker provided by an ISP. The tunnel works, but I want to confirm my understanding of the commands they gave me to set it up. These are the commands: ifconfig gif0 tunnel 50.1.94.112 72.52.104.74 ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen 128 route -n add -inet6 default 2001:470:1f04:204::1 The first and third commands make sense to me; they set up an IPv4 tunnel interface and a default route for IPv6. After reading the ifconfig(8) man page) I think I sort of understand what the second one does. Side note: the two IPv6 addresses provided by the tunnel broker are defined, in their terminology, as follows: prefix::1 is the server IPv6 address and prefix::2 is the client IPv6 address. Given that, I think the following is true: - prefix::1 is the local address of the interface on the IPv6 network. No, *::2 is local. - 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. - Because gif0 is a point-to-point interface, prefix::2 (the server IP) is interpreted as the dest_address parameter mentioned in the ifconfig(8) man page. 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. 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. 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. HE likely provided you a /64 prefix for your use, or maybe you have to request it (I have an HE tunnel but don't remember all details; their website is helpful). Those addrs would be in a different /48 than the tunnel addrs. If you're setting up a router your assigned /64 prefix can be assigned to an internal interface with alias like 'inet6 alias /64 net prefix 64'. Then point rtadvd at that interface. -Ed
Re: ifconfig command for IPv6 tunnel
On Aug 19, 2014, at 9:38 PM, Adam Thompson athom...@athompso.net wrote: IIRC from my experimentation, you've got it exactly right. Some tunnel brokers give you subnet masks that certain versions of OpenBSD don't like - that turns out to not actually matter, just use whatever ifconfig(8) want. Point in case: HE recommends using /64 for PtP links, but OpenBSD 5.x requires /128. Since HE allocates an entire /64 per tunnel, there is no danger in configuring it more narrowly on the client end. Thanks for the info. As it happens, I am also using a tunnel provided by HE. The hostname.if(5) syntax that finally worked for me on 5.4-RELEASE was (slightly anonymized) description HE_TUNNEL_FREMONT tunnel 184.70.48.XXX dest 64.71.128.83 inet6 2001:470::X::2 dest 2001:470::X::1 prefixlen 128 which perhaps adds some clarity, or perhaps confuses, depending on your point of view. I can't remember whether (in the non-BGP case) I added the route command as !route -n add -inet6 default 2001:470:1f04:204::1 to the hostname.gif0 file, or if I added it to /etc/mygate - one or the other should work, anyway. I haven't gotten to the point of making this configuration permanent, but the example above makes sense. My initial effort is toward a larger goal of getting a small network of pure IPv6 hosts connected. My current thinking on how to do this is (in admittedly vague and incomplete terms) is: use a machine connected to the tunnel broker as a bridge. Other machines would connect to it and perform address auto configuration, using the prefix of the HE provided network. To accomplish this, the bridge machine would run the daemon that hands out these prefixes, which I think is called rtadvd Comments on this approach (or alternatives) are welcome. Finally, is this the place to discuss these kinds of network setup puzzles? I happen to be using OpenBSD, but this kind of task really is at the intersection of operating system specifics and the more general practice of network design. Chuck
Re: ifconfig command for IPv6 tunnel
On 14-08-20 09:12 AM, Charles Musser wrote: Thanks for the info. As it happens, I am also using a tunnel provided by HE. I know - I could tell by the addresses you provided :-). My current thinking on how to do this is (in admittedly vague and incomplete terms) is: use a machine connected to the tunnel broker as a bridge. Other machines would connect to it and perform address auto configuration, using the prefix of the HE provided network. To accomplish this, the bridge machine would run the daemon that hands out these prefixes, which I think is called rtadvd Comments on this approach (or alternatives) are welcome. Basically, yes. Although you have a router (does things with IP packets), not a bridge (does things with Ethernet frames) - that's a huge difference. I don't think I've ever relied on address autoconfig - it looks very nice in theory but has some limitations in practice. I would test everything using static IPs and static routes first, and then move on to rtadvd. HE assigns two blocks of addresses with every tunnel - the point-to-point tunnel addresses and the Routed IPv6 Prefixes. You want to use the IPv6 Tunnel Endpoints on the gif0 tunnel, which is presumably built on top of $external_if , and you want to use the Routed IPv6 Prefixes on $internal_if. Note that is perfectly valid to have public IPv6 addresses running on the same subnet as private (RFC1918) IPv4 addresses - IPv4 traffic gets NAT'd, IPv6 traffic merely gets routed. Do beware that your pf ruleset must pass IPv6 traffic without NAT'ing it... I think this is the default now, not sure. If you're like 99% of the IPv6-using population today, your router will probably become 2001:470::::1/64 (on $internal_if), and clients on the internal network will then become 2001:470::::2/64 to 2001:470::::254/64. There may well be better ways, but that naive approach will work. Oh, you'll have to enable net.inet6.ip6.forwarding on the router, I think it's off by default. Finally, is this the place to discuss these kinds of network setup puzzles? I happen to be using OpenBSD, but this kind of task really is at the intersection of operating system specifics and the more general practice of network design. Someone will tell you to go away, don't worry... The fact that you understand this makes answering you a lot more pleasant than the usual run-of-the-mill I deal with (elsewhere) where impossibly-bad network design somehow translates into the firewall must be broken when things don't work. I suggest you try google - the second hit for openbsd ipv6, at least for me, is a SANS Institute guide to setting up an IPv6 firewall using OpenBSD v3.0(!) which appears to mostly still be applicable. The docs for SixS aren't bad as long as you ignore the bits about their ~proprietary client software. Beware following guides that are too old - I see some old material referencing transition mechanisms (like FAITH - did anyone ever actually use that?), which probably aren't what you want to be looking at now. -- -Adam Thompson athom...@athompso.net
Re: ifconfig command for IPv6 tunnel
On Aug 20, 2014, at 7:43 AM, Adam Thompson athom...@athompso.net wrote: I know - I could tell by the addresses you provided :-). So much for *my* anonymity... ;-) Basically, yes. Although you have a router (does things with IP packets), not a bridge (does things with Ethernet frames) - that's a huge difference. I don't think I've ever relied on address autoconfig - it looks very nice in theory but has some limitations in practice. I would test everything using static IPs and static routes first, and then move on to rtadvd. HE assigns two blocks of addresses with every tunnel - the point-to-point tunnel addresses and the Routed IPv6 Prefixes. You want to use the IPv6 Tunnel Endpoints on the gif0 tunnel, which is presumably built on top of $external_if , and you want to use the Routed IPv6 Prefixes on $internal_if. Note that is perfectly valid to have public IPv6 addresses running on the same subnet as private (RFC1918) IPv4 addresses - IPv4 traffic gets NAT'd, IPv6 traffic merely gets routed. rtadvd: Yes, one thing at a time. Static IPs first. router vs. bridge: good point. Because I those routed IPv6 Prefixes are available, there are two networks in play, so it's routing and not bridging. I was initially operating under the assumption that there was one network for both the tunnel endpoint and the other hosts, so I thought bridge!. But that isn't the case. Do beware that your pf ruleset must pass IPv6 traffic without NAT'ing it... I think this is the default now, not sure. This, I will have to dig into. I wasn't aware that PF was enabled. But I suspect you can't get very far in these setups without it. Another responder provided some PF rules to try, so I can study those.
Re: ifconfig command for IPv6 tunnel
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. 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. 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: default2001:470:1f04:204::1 UGS6 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 UHL0 0 - 4 lo0 This is different than what you describe, but it makes sense. I think. 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.7 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.
Re: ifconfig command for IPv6 tunnel
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:
default2001:470:1f04:204::1 UGS6
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 UHL0
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.7
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
Re: ifconfig command for IPv6 tunnel
Forgot to reply-all yesterday (only sent to Charles) to keep the
thread in-sync with the rest of the conversation (don't nuke me for
stating the obvious + added the rtadvd/route6d)
On 20 August 2014 13:40, Charles Musser cmus...@sonic.net wrote:
ifconfig gif0 tunnel 50.1.94.112 72.52.104.74
ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen
128
route -n add -inet6 default 2001:470:1f04:204::1
Spot on there Chuck. That is how I have mine set up.
Don't forget to change in your /etc/sysctl.conf file:
net.inet6.icmp6.rediraccept=1 # 1=Accept IPv6 ICMP redirects (for hosts)
net.inet6.ip6.forwarding=1 # 1=Permit forwarding (routing) of IPv6 packets
(note the removal of the comment #)
You will also need to tweek your /etc/pf.conf rule set. Here is a
rough guide, mileage may vary:
icmp6_types={ unreach, timex, paramprob, echoreq, routeradv,
routersol, neighbradv, neighbrsol } # Only want these ICMP6 types
block return# default that probably exists in your environment -
nothing to come in unless explicitly defined below (IPv4 and IPv6)
pass out on gif0 inet6# Allow for all ICMP6 traffic
out - you may not want to do this but whatever works for you
pass inet6 proto icmp6 icmp6-type $icmp6_types # Allow
ICMP6 of types defined above to move in and out freely
pass on vmx0 inet6# Allowing traffic in and out of internal network.
Then you'll need to setup the rtadvd daemon to hand out your /64 to
your internal clients (/etc/rtadvd.conf):
default:\
:rdnss=ipv6 of your internal DNS server or server
that you use:\
:dnssl=search domain:
vmx0:\ # This is my internal interface, yours may be different
:addr=your /64 subnet prefix:::prefixlen#64:tc=default:
Now enable all that to serve your internal clients (/etc/rc.conf.local):
rtadvd_flags=vmx0
route6d_flags=
That should be about it.
--
Roads? Where we're going, we don't need roads - Emmett Doc Brown
Re: ifconfig command for IPv6 tunnel
On Aug 20, 2014, at 2:25 PM, Ed Hynan eh_l...@optonline.net wrote:
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.
OK, got it. I am at peace.
Output of that is:
default2001:470:1f04:204::1 UGS
6 146 - 8 gif0
2001:470:1f04:204::1 2001:470:1f04:204::2 UH
10 - 4 gif0
2001:470:1f04:204::2 link#6 UHL
00 - 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).
Upon reflection, it does match what you said. My coffee consumption, or
lack thereof, influenced my comprehension here.
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.
I don't now, but that's the goal. At this point, I need to forage for some
hardware to try building a router. I had a perfectly good beige box with
numerous interfaces that I threw out recently. Party foul. Once I get
that, then I probably will have PF-specific questions.
ifconfig command for IPv6 tunnel
Hi, I'm experimenting with using IPv6 via a tunnel broker provided by an ISP. The tunnel works, but I want to confirm my understanding of the commands they gave me to set it up. These are the commands: ifconfig gif0 tunnel 50.1.94.112 72.52.104.74 ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen 128 route -n add -inet6 default 2001:470:1f04:204::1 The first and third commands make sense to me; they set up an IPv4 tunnel interface and a default route for IPv6. After reading the ifconfig(8) man page) I think I sort of understand what the second one does. Side note: the two IPv6 addresses provided by the tunnel broker are defined, in their terminology, as follows: prefix::1 is the server IPv6 address and prefix::2 is the client IPv6 address. Given that, I think the following is true: - prefix::1 is the local address of the interface on the IPv6 network. - The alias parameter is superfluous in this case. I tried it without that and got the same result: an operating tunnel. - Because gif0 is a point-to-point interface, prefix::2 (the server IP) is interpreted as the dest_address parameter mentioned in the ifconfig(8) man page. - dest_address is the far end of the tunnel and, for point-to-point links, serves as the gateway. In this case, it leads to the broader IPv6 universe. Any confirmation, clarification or correction is much appreciated. Chuck
Re: ifconfig command for IPv6 tunnel
On 14-08-19 10:40 PM, Charles Musser wrote: I'm experimenting with using IPv6 via a tunnel broker provided by an ISP. The tunnel works, but I want to confirm my understanding of the commands they gave me to set it up. These are the commands: ifconfig gif0 tunnel 50.1.94.112 72.52.104.74 ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen 128 route -n add -inet6 default 2001:470:1f04:204::1 [...] IIRC from my experimentation, you've got it exactly right. Some tunnel brokers give you subnet masks that certain versions of OpenBSD don't like - that turns out to not actually matter, just use whatever ifconfig(8) want. Point in case: HE recommends using /64 for PtP links, but OpenBSD 5.x requires /128. Since HE allocates an entire /64 per tunnel, there is no danger in configuring it more narrowly on the client end. The hostname.if(5) syntax that finally worked for me on 5.4-RELEASE was (slightly anonymized) description HE_TUNNEL_FREMONT tunnel 184.70.48.XXX dest 64.71.128.83 inet6 2001:470::X::2 dest 2001:470::X::1 prefixlen 128 which perhaps adds some clarity, or perhaps confuses, depending on your point of view. I can't remember whether (in the non-BGP case) I added the route command as !route -n add -inet6 default 2001:470:1f04:204::1 to the hostname.gif0 file, or if I added it to /etc/mygate - one or the other should work, anyway. -- -Adam Thompson athom...@athompso.net
