addresses and routes configured via rtsol
I set up a small network in which an OpenBSD machine serves as a router for a collection of IPv6-only clients. Many thanks to previous responders to my questions on tunneling with gif(4). This rudimentary setup is working well: a client machine acquires an address via SLAAC and can access the IPv6 Internet. I am curious, however, about the addresses and routes that get installed on the client machine. The setup straightforward. The router is connected to an IPv6 tunnel on the Internet-facing side (using a gif(4) interface), it has IPv6 forwarding enabled, and is running rtadvd on the inward-facing interface. Note that rtadvd is using its internal defaults; I didn't create a configuration file for it because the man page The interface info and routing table is at the end of this mail and I've annotated lines of interest with numbers in brackets so that referencing these entries in questions would be clearer. The questions are: 1.) In addition to the self-assigned link-local address, the client's interface has two other addresses, both having the network prefix supplied by the router (annotation [1]). One has the same suffix as that of the link-local address. The other, marked "autoconfprivacy", is different and changes periodically (certainly on every reboot). I assume this address is formed with the rules defined in RFC 4941. As I interpret it, the RFC suggests a scheme that employs different addresses for server-oriented tasks and client-oriented tasks. The idea is that a predicable address is suitable for the former, while a randomized one is for the latter. Is that what's happening here? According to netstat(1), this seems to be the case. While surfing the web, the local address always seems to be the one with the autoconfprivacy attribute. Is rtsol(8) in charge of implementing this policy? 2.) A corollary to the above question is how the "privacy" address gets used for outbound connections. My assumption of how interfaces with multiple addresses behave is this: the interface will accept connections for any address it has been assigned, but will use the "canonical" one for connections that are initiated through that interface. Is this correct? Does IPv6 have the notion of "aliases" at all? If it does, how do you know which one is the "canonical" address. If not, how do outbound connection end up with the "correct", i.e. private, local address? 3.) The default route (annotation [2]) mystified me at first, before I realized that the gateway address was the link-local address of the router. I was aware of link-local addresses in IPv6, but I was unsure of their application and didn't expect them to come into play here. I expected the gateway to be the IPv6 address I assigned to the router's inward facing interface. It seems logical that the router's link-local address works, but why was it chosen? 4.) The /64 network route for my network has the gateway specified as "link#1" (annotation [3]). What are the "link" family of interfaces? These must be different than routes that specify one of the link-layer addresses, but how? Thanks, Chuck Output of ifconfig em0 and netstat -nrf inet6, with [annotations]: em0: flags=8843 mtu 1500 lladdr f0:de:f1:78:d5:4c priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) status: active inet6 fe80::f2de:f1ff:fe78:d54c%em0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f05:204:f2de:f1ff:fe78:d54c prefixlen 64 autoconf pltime 604280 vltime 2591480 [1] inet6 2001:470:1f05:204:1039:d2fd:9b56:709 prefixlen 64 autoconf autoconfprivacy pltime 77124 vltime 595610 [1] Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface ::/104 ::1UGRS 0 0 - 8 lo0 ::/96 ::1UGRS 0 0 - 8 lo0 defaultfe80::92e2:baff:fe2b:b008%em0 UG 0 156 -56 em0 [2] ::1::1UH14 0 33144 4 lo0 ::127.0.0.0/104::1UGRS 0 0 - 8 lo0 ::224.0.0.0/100::1UGRS 0 0 - 8 lo0 ::255.0.0.0/104::1UGRS 0 0 - 8 lo0 :::0.0.0.0/96 ::1UGRS 0 0 - 8 lo0 2001:470:1f05:204::/64 link#1 UC 1 0 - 4 em0 [3] 2001:470:1f05:204::1 90:e2:ba:2b:b0:08 UHLc 0 30 - 4 em0 2001:470:1f05:204:24c5:ec52:ca52:a9e7 f0:de:f1:78:d5:4c UHL 00 - 4 lo0 2001:470
Re: ifconfig command for IPv6 tunnel
On Aug 20, 2014, at 2:25 PM, Ed Hynan 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.
Re: ifconfig command for IPv6 tunnel
On Aug 20, 2014, at 4:15 AM, Ed Hynan wrote: > On Tue, 19 Aug 2014, Charles Musser wrote: > >> >> - ::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 Aug 20, 2014, at 7:43 AM, Adam Thompson 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 19, 2014, at 9:38 PM, Adam Thompson 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
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: ::1 is the "server IPv6 address" and ::2 is the "client IPv6 address". Given that, I think the following is true: - ::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, ::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: Package installation
The need for multiple versions of an application on one machine doesn't manifest that often. Asking the system to tie itself into knots for this purpose is likely to result in bloat, convolution and less reliability. Some contexts support and indeed encourage the notion of many versions. For instance, the Ruby Version Manager (RVM) allows different versions of the Ruby interpreter and its attendant libraries to be in use at a given time. It seems to work perfectly well, but one has to wonder if this is really a good thing. Do you really want the mental overload that results from having to deal with multiple versions of a language, library, API, user tool, or whatever? The original poster might want to consider whether this kind of thing is necessary or desirable. It sounds symptomatic of half-baked ideas about what needs to be accomplished and how to accomplish it. Also worth considering is OpenBSD's stance on how to maintain a system. You are encouraged to refresh the system at six month intervals and, in so doing, become familiar with the nature of the software you're running. Chances are, the version they've packaged works well enough, probably better than older incarnations. Incidentally, you can learn what files comprise a package with: pkg_info -L You can learn about the package related commands by typing: apropos pkg_ And then reading the listed manpages. As always with OpenBSD, these documents are of high quality. Chuck On Aug 2, 2014, at 4:17 AM, Gustav Fransson Nyvell wrote: > On 08/02/14 13:13, Gustav Fransson Nyvell wrote: >> On 08/02/14 12:54, Marc Espie wrote: >>> On Sat, Aug 02, 2014 at 12:26:06PM +0200, Gustav Fransson Nyvell wrote: Hi, there, I wanted to run something by you, mkay. About package management. I wonder if this has been shouted at already. I remember from SunOS that packages are installed in a different manner than let's say Red Hat and of course OpenBSD. They install it in the form /pkgs/PROGRAM/VERSION, example /pkgs/gimp/1.0. GoboLinux does this. I think this has some advantages over installing /usr/local/bin/gimp1.1 and /usr/local/bin/gimp2.0. What do you think? What have you said? Ready to be shouted at; >>> This puts more strain on the file system actually, which is probably >>> the main reason we don't do it. Also, there is generally a lot of churning >>> to do to make the package self-contained. >>> >>> As far as policy goes, having stuff set up like that looks more flexible, >>> but >>> it is a fallacy. Instead of having the distribution solve issues concerning >>> incompatible versions and updates, the toll falls instead on the individual >>> sysadmin, to make sure things they have work together. It can lead to >>> security nightmares, because it's "so simple" to have the newer version >>> alongside the old version that sticky points of updating take much longer >>> to resolve. >>> >>> It's a bit like having mitigation measures that you can turn on and off... >>> if it's possible to turn these off, there's not enough incentive to actually >>> fix issues. >>> >>> Likewise for packages. By making it somewhat LESS convenient to install >>> several versions of the same piece of software, we make it more important >>> to do timely updates. >>> >>> Also, we don't have the manpower to properly manage lots of distinct >>> versions >>> of the same software. So this kind of setup would be detrimental to >>> actually testing stuff. >> I guess there could be both. But I think that if there's a security issue >> with one version of a software then there quite possibly are multiple ways >> of limiting the impact of that issue. Disallowing multiple versions to force >> people to upgrade is not really a good reason, from how I see it. Old >> software will always have more holes, because they're older and more well >> observed, but they have qualities, too, like speed. GIMP-1.0 is amazing on >> Lenovo X41 from 2005, but probably has bugs. Of course none of these systems >> will stop someone who wants to run version x of a software. Maybe something >> entirely different is needed? Okay, maybe I should complain about the status >> quo... thing is when packages install in /var, /usr, /etc and /opt they're >> so spread out it's hard to know what is what. This might be because I'm new >> but/and scripts can find orphan files in this structures, but you need the >> scripts for that. Having everything in /pkgs/PKG/VER would not cause this >> splatter. P! rograms without dependees (i.e. non-libs, non-utilprograms) could fit in this structure without any extra filesystem magic. Well, the grass is always greener. >> > BTW, you create multiple versions by your mere existence. There are lots of > old versions laying around, but they can't be installed together right now. > > -- > This e-mail is confidential and may not be shared with anyone other than > recipient(s) without written permission fr
Re: network roaming convenience
On Jul 22, 2014, at 12:59 AM, Stuart Henderson wrote: >> >> Out of curiosity, what happens? > > It prints the status, > > iwn0: flags=8847 mtu 1500 > lladdr 8c:70:5a:62:b7:f8 > priority: 4 > groups: wlan egress > media: IEEE802.11 autoselect (DS1 mode 11g) > status: active > ieee80211: nwid TP-LINK_8F014A chan 6 bssid f8:1a:67:8f:01:4a 189dB > > then there's a 30 second pause during which the led flashes, then ifconfig exits > without further output. Then I have to ifconfig iwn0 down, ifconfig iwn0 up, > and start dhclient again which has exited due to the interface state change Yeah, that is interesting. I didnt really notice it before, but scan doesnt return anything if Im connected to my network, but the act of doing it changes the status from active to no network. Then it returns a list if invoked again. I thought I might run scan periodically to check connectivity, but the act of doing so seems to knock me off the air. A related wrinkle is that the status never changes to no network if the AP is powered off. So you cant check actively (with scan anyway) and you cant be informed passively if youve moved out of range. Darn. About the only thing I noticed was that the mode listed in the media line changes. Not sure thats actually indicative of anything > > While I don't dispute that this behaviour is a bug, it doesn't seem > right for the script to be doing this, surely if you know the password > you should also know if wep is needed? It would seem safer generally > to only use the expected protocol. True. wiconfigs author is open to changing how this works. Apparently, in an upcoming OBSD release, ifconfig will display the security offered by the AP. > > Do you need a full reboot at this point, or does restarting the interface > (ifconfig down+up) work? Do you get anything interesting (look in > /var/log/messages) if "ifconfig iwn0 debug" is set? Turns out, no. What I needed to do was clear the WEP key (by using the -nwkey" parameter) and then the interface was usable. A subsequent ifconfig with wpakey specified got me connected.
Re: network roaming convenience
On Jul 18, 2014, at 3:09 PM, Stuart Henderson wrote: > On 2014-07-17, Daniel Melameth wrote: >> It should have tried WEP first and, if that failed, WPA. ifconfig in >> -current can now discern WEP or WPA so this can readily be improved. > > ...as long as you have a wifi nic where "ifconfig scan" works, for example > not "Intel Centrino Advanced-N 6205 rev 0x34"... > Out of curiosity, what happens? Does this mean you’re flying blind when you parachute in somewhere and want to know what wi-fi networks are around? On my machine, which uses iwn, “ifconfig scan” does work, but there is an odd behavior that wiconfig happens to trigger, at least in my environment. Configuring the interface for WPA manually (or via hostname.if) works fine, but I had trouble with wiconfig until I increased its connect timeout value. This was due to an odd set of circumstances. wiconfig attempts to configure the interface with WPA, waits for a bit and, if the connection isn’t successful, tries again with WEP. My machine doesn'tt connect within the wiconfig's 3 second timeout interval, and then things get weird. After the second connection attempt (with WEP, using the “nwkey” param), the connect fails again (my AP only does WPA). After this, the interface cannot connect successfully with WPA until after a reboot. I first noticed this behavior with wiconfig and determined what it was doing specifically with help from wiconfig’s author. To confirm what was going on, I issued the same sequence of “ifconfig” invocations manually. Sure enough, an ifconfig with the nwkey parameter was a buzzkill: it prevented connection with a subsequent “ifconfig” invocation: one that certainly works if it is the first ifconfig that happens. This is certainly a corner case, but it did trip me up.
network roaming convenience
Hi, I'm looking to create or cobble together functionality that automates network connections as a user roams around with a laptop. The idea is to respond to changing network availability: wifi network is known, so connect, or cable was plugged in, or connect for the first time and remember, etc). On Linux, this is provided by program called NetworkManager. I'm pretty sure it's are Linux-specific and, anyway, it depends on DBus (a separate messaging system). I was hoping to create something a little more self contained. I did explore a couple of avenues. One was the "wiconfig" script mentioned on Undeadly a while back. This didn't connect, seemingly because it tried to use WEP, not WPA. I didn't want to debug a shell script to find out why. Another possibility is using ifstated. However it looks like WiFi interfaces are always "up", even in the "no network" state, so it's unclear whether the required state transitions would actually happen But I haven't verified that, so I can't dismiss this as a solution. An argument could be made that this is of marginal utilty. How hard is it to use ifconfig, anyway? But I figured it might be an interesting exercise and may be a nice convenience. Any advice, or discussion would be appreciated. Chuck
