Hello,
I have been testing IPv6 on my home network and I have decided to let my iMac act as a gateway, as it's the only machine that stays on most of the day. Everything works fine with the he.net tunnel, but a few seconds after I start rtadvd, the default v6 gateway is automatically set to the link-local (fe80::/16) address of the en0 interface, breaking v6 routing for my whole network. Manually deleting such route and readding the correct one (2001::/16) on the tunnel interface gif0 fixes it.
The problem is that I'm ultimately planning on having a shell script do all of this on boot, and having the script wait a given number of seconds before deleting and readding the route doesn't seem very elegant, not to mention that I don't really know how much time passes before the default route is changed.
This is what my gif0 and en0 interfaces look like:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 192.168.0.6 --> 216.66.80.30
inet6 fe80::217:f2ff:fed9:eb5e%gif0 prefixlen 64 scopeid 0x2
inet6 2001:470:1f0b:1393::2 --> 2001:470:1f0a:1393::1 prefixlen 128
This is the default gateway that I manually set (and works):
Internet6:
Destination Gateway Flags Netif Expire
default 2001:470:1f0a:1393::1 UGSc
And this is what it gets reset to (and stops working):
Internet6:
Destination Gateway Flags Netif Expire
default fe80::217:f2ff:fed9:eb5e%en0 UGc
This happens a short while after starting rtadvd, but I can't find anything in the manual pages that refers to the default route. I have used the very same configuration on FreeBSD (by replacing en0 with the correct interface name) and it worked flawlessly, so I'm not sure what the problem is. I suspect that I should add something to rtadvd.conf, because right now I only have a reference to en0 and that may be why the route is redirected there, but I'm not sure how to do that.
Here is my current rtadvd.conf:
en0:\
:addrs#1:addr="2001:470:1f0b:1393::":prefixlen#64:tc=ether:nolladdr:
Any hints will be greatly appreciated.
Thank you :)
i assume that your mac is still listening for ra? you should be able to tell your mac not to listen for RA and thereby keep its static address (and also the default gateway)
Hello,
unfortunately that's not the problem. net.inet6.ip6.accept_rtadv is set to 0, and the only other variable I change is net.inet6.ip6.forwarding (setting it to 1 to act as a gateway for the rest of my local network.)
Interesting; I've never heard of this before. Is your iMac configured to advertise RA?
Yes, and after I manually delete the wrong default gateway and set the new one, it works perfectly over the network. I just have no idea why it gets reset to a link-local address after starting rtadvd, nor why it only happens once.
For reference, here are the kernel values about the ipv6 stack:
octavarium:~ jollino$ sysctl -a | grep inet6 | sort
net.inet6.icmp6.errppslimit: 500
net.inet6.icmp6.nd6_debug: 0
net.inet6.icmp6.nd6_delay: 5
net.inet6.icmp6.nd6_maxnudhint: 0
net.inet6.icmp6.nd6_mmaxtries: 3
net.inet6.icmp6.nd6_prune: 1
net.inet6.icmp6.nd6_umaxtries: 3
net.inet6.icmp6.nd6_useloopback: 1
net.inet6.icmp6.nodeinfo: 3
net.inet6.icmp6.rediraccept: 1
net.inet6.icmp6.redirtimeout: 600
net.inet6.ip6.accept_rtadv: 0
net.inet6.ip6.auto_flowlabel: 1
net.inet6.ip6.auto_linklocal: 1
net.inet6.ip6.dad_count: 1
net.inet6.ip6.defmcasthlim: 1
net.inet6.ip6.forwarding: 1
net.inet6.ip6.fw.debug: 0
net.inet6.ip6.fw.enable: 1
net.inet6.ip6.fw.verbose: 0
net.inet6.ip6.fw.verbose_limit: 0
net.inet6.ip6.gifhlim: 0
net.inet6.ip6.hdrnestlimit: 50
net.inet6.ip6.hlim: 64
net.inet6.ip6.kame_version: 20010528/apple-darwin
net.inet6.ip6.keepfaith: 0
net.inet6.ip6.log_interval: 5
net.inet6.ip6.maxdynroutes: 1024
net.inet6.ip6.maxfragpackets: 1024
net.inet6.ip6.maxfrags: 8192
net.inet6.ip6.maxifdefrouters: 16
net.inet6.ip6.maxifprefixes: 16
net.inet6.ip6.neighborgcthresh: 1024
net.inet6.ip6.redirect: 1
net.inet6.ip6.rr_prune: 5
net.inet6.ip6.rtexpire: 3600
net.inet6.ip6.rtmaxcache: 128
net.inet6.ip6.rtminexpire: 10
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.use_deprecated: 1
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.v6only: 0
net.inet6.ipsec6.ah_net_deflev: 1
net.inet6.ipsec6.ah_trans_deflev: 1
net.inet6.ipsec6.debug: 0
net.inet6.ipsec6.def_policy: 1
net.inet6.ipsec6.ecn: 0
net.inet6.ipsec6.esp_net_deflev: 1
net.inet6.ipsec6.esp_randpad: -1
net.inet6.ipsec6.esp_trans_deflev: 1
I had the exact same problem today, however it seemed to go away once I assigned a proper subnet address manually to my en0 interface, rather than using the default-assigned link-local address. I also didn't bother configuring anything in rtadvd.conf, since with the proper IPv6 address assigned to en0 it's handing out the correct addresses by default.
Could you please list which commands you use? (Feel free to remove the addresses, of course.)
Thank you very much.
While you could fill it in with ifconfig, it's actually easier just to assign the subnet through the System Preferences by setting your IPv6 configuration to manual and entering it there.
In my case, I allocated a /48 to my HE tunnel and used that to setup the tunnel on GIF0, and then picked an address in my assigned /64 to put on my en0 interface.
So basically, an IP address in my routed /48 gets assigned to gif0 using:
ifconfig gif0 inet6 2001:470:b110::bdc:caff/48 alias
...in addition to the usual commands to setup the tunnel.
I then assigned one of the addresses from my routed /64 to en0 via System Preferences -- select en0, choose "Advanced" and select "Configure IPv6: Manually" and enter the following info:
Router: The Server IPv6 address from your tunnel (same as your default route set by the route command when setting up the gif0 interface)
IPv6 Address: Your /64 prefix and a node on your network (ie, 2001:470:1d:403::1)
Prefix Length: 64
Once that's setup, you should be able to just fire up rtadvd by entering "rtadvd en0" without worrying about the rtadvd.conf file, as the daemon will pick up the network configuration from en0 automatically and advertise addresses within that subnet. Other machines on your network should autoconfigure with addresses in the 2001:xxxx:xxxx:xxxx::/64 subnet and pick up the default route via your iMac.
Note that you may also need to set net.inet6.ip6.accept_rtadv to 1 on the remote computers for them to pick up the stateless autoconfiguration from your iMac and obtain addresses on the routed /64 network.
In the end, my ifconfig for gif0 and en0 reads as follows:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 192.168.101.101 --> 216.66.38.58
inet6 2001:470:b110::bdc:caff prefixlen 48
inet6 2001:470:1c:403::2 --> 2001:470:1c:403::1 prefixlen 128
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1280
ether 00:23:df:91:9e:92
inet6 fe80::223:dfff:fe99:9f93%en0 prefixlen 64 scopeid 0x4
inet6 2001:470:1d:403::1 prefixlen 64 autoconf
inet 192.168.101.101 netmask 0xffffff00 broadcast 192.168.101.255
media: autoselect (1000baseT <full-duplex,flow-control>)
status: active
I'd rather stay with ifconfig for "portability" on other machines if needs be, but I can't really make it work. I only have a /64 assigned by HE, and I can't pinpoint where the problem is. Here is what I run, including assigning a /64 node to gif0:
ifconfig gif0 tunnel 192.168.0.6 216.66.80.30
ifconfig gif0 inet6 2001:470:1f0b:1393::1 2001:470:1f0a:1393::1 prefixlen 128
ifconfig gif0 inet6 2001:470:1f0b:1393::aaaa prefixlen 64 alias #what you suggested
ifconfig en0 inet6 2001:470:1f0b:1393::abcd prefixlen 64
route -n add -inet6 default 2001:470:1f0a:1393::1
rtadvd en0
I have cleaned up /etc/rtadvd.conf so everything is commented out. This is what my interfaces look like:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 192.168.0.6 --> 216.66.80.30
inet6 fe80::217:f2ff:fed9:eb5e%gif0 prefixlen 64 scopeid 0x2
inet6 2001:470:1f0b:1393::1 --> 2001:470:1f0a:1393::1 prefixlen 128
inet6 2001:470:1f0b:1393::aaaa prefixlen 64
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:17:f2:d9:eb:5e
inet6 fe80::217:f2ff:fed9:eb5e%en0 prefixlen 64 scopeid 0x4
inet 192.168.0.6 netmask 0xffffff00 broadcast 192.168.0.255
inet6 2001:470:1f0b:1393::abcd prefixlen 64
media: autoselect (100baseTX <full-duplex,flow-control>)
status: active
I noticed that your en0 says autoconfig, while mine doesn't. It can't be because of the configuration in System Preferences, as you set it manually.
What route command do you use? I have a feeling that if told it "route via gif0 rather than en0", rtadvd wouldn't try to replace it. However, I've been unable to make it digest the -interface modifier, no matter which syntax I tried. What I have to do to make it start working is deleting the default route and readding it:
route -n delete -inet6 default
route -n add -inet6 default 2001:470:1f0a:1393::1
and that fixes it on all machines.
I'm sure I'm making very stupid mistake somewhere, but I swear I'm learning in the process. :)
Thank you.
Quote
ifconfig gif0 inet6 2001:470:1f0b:1393::1 2001:470:1f0a:1393::1 prefixlen 128
ifconfig gif0 inet6 2001:470:1f0b:1393::aaaa prefixlen 64 alias #what you suggested
ifconfig en0 inet6 2001:470:1f0b:1393::abcd prefixlen 64
route -n add -inet6 default 2001:470:1f0a:1393::1
I think you have your addresses messed up. Shouldn't this be
ifconfig gif0 create
ifconfig gif0 inet6 2001:470:1f0b:1393::2 2001:470:1f0a:1393::1 prefixlen 128
ifconfig en0 inet6 2001:470:1f0a:1393::abcd prefixlen 64
route -n add -inet6 default 2001:470:1f0b:1393::1
I'm assuming that 2001:470:1f0b:1393::/64 is your tunnel /64 and 2001:470:1f0a:1393::/64 is your routed /64. If I'm wrong, you need to change the commands above.
Only ::1 and ::2 are used out of your tunnel /64; if you need more addresses, you need to go to your routed /64
Okay, I'm getting quite confused (and yes, I feel quite stupid... bear with me, upgrading an OS stack to v6 is easier than upgrading one's brain :D)
According to the tunnel details page, 2001:470:1f0b:1393::/64 is my routed /64 and 2001:470:1f0a:1393::/64 is where the tunnel endpoints are taken from. Specifically, 2001:470:1f0a:1393::1/64 is the server address and 2001:470:1f0a:1393::2/64 is the client address.
First question: why is a whole /64 "wasted" for the two endpoints? And why does the details page use the 2001:470:1f0a:1393::1/64 notation? Shouldn't it be 2001:470:1f0a:1393::1/128 as the tunnel endpoints are effectively one IP each?
So, I suppose that I need to use the tunnel /64 addresses with the gif interface exclusively (on my v6 gateway), and the routed /64 for everything else?
I'm going to make some extra tests, I'll report how it goes.
OK, so the code I wrote should say
ifconfig gif0 create
ifconfig gif0 inet6 2001:470:1f0a:1393::2 2001:470:1f0a:1393::1 prefixlen 128
route -n add -inet6 default 2001:470:1f0a:1393::1
You'd obviously need to add in the line with the IPv4 addresses, eg "ifconfig gif0 tunnel 1.2.3.4 5.6.7.8"
Quote
And why does the details page use the 2001:470:1f0a:1393::1/64 notation? Shouldn't it be 2001:470:1f0a:1393::1/128 as the tunnel endpoints are effectively one IP each?
Because the network actually is a /64 I've seen posts that say you can use the rest of the addresses in that range for your stuff, but you're not able to assign DNS to them, so it's pointless.
Quote
So, I suppose that I need to use the tunnel /64 addresses with the gif interface exclusively (on my v6 gateway), and the routed /64 for everything else?
Exactly. Unless you're going to get a /48, use the routed /64 for everything other than your tunnel addresses
Quote
why is a whole /64 "wasted" for the two endpoints?
"Just because." A /64 is the smallest network that most OS's will accept, so that's what is used.
Thank you for the clarifications.
However, I must be still missing something becuse everything works fine until rtadvd starts. After about 15 seconds, the default gateway goes from 2001:470:1f0a:1393::1 to fe80::217:f2ff:fed9:eb5e%en0 and, of course, everything breaks.
Just to be sure, here is what I do:
ifconfig gif0 tunnel 192.168.0.6 216.66.80.30
ifconfig gif0 inet6 2001:470:1f0a:1393::2 2001:470:1f0a:1393::1 prefixlen 128
ifconfig gif0 inet6 2001:470:1f0b:1393::ffff prefixlen 128 # as per jdh's advice (node from the routed /64, i suppose /128 is fine)
ifconfig en0 inet6 2001:470:1f0b:1393::abcd prefixlen 64 # as per jdh's advice (on en0, the 'prefixlen 64' should help rtadvd 'get' what it can advertise)
route -n add -inet6 default 2001:470:1f0a:1393::1
The very same thing happens whether or not I manually assign the extra addresses to either interface. It all works great until rtadvd's been running for about 15 seconds.
So the tunnel is working...great.
Every gateway I've seen is an fe80 address. Really, that should work fine because the router is always on the same network as the clients (at least, that's how it's supposed to be)
I'm not sure why changing from 2001 to fe80 breaks it. (does this break on the tunnel machine or on other machines on the network?)
Which 2001 address are you using for the gateway?
Well, the tunnel has been working since day one, even with the messed up addresses.
However, I tried using the System Preferences method suggested by jdh and it seems to work... I suppose it has a higher priority than ifconfig when it comes to rtadvd. I just used the two original ifconfig settings for gif0 (tunnel 1.2.3.4 5.6.7.8; inet6 2001::1234 2001:abcd) and rtadvd seems to be going. My iPhone and MacBook Pro also got configured correctly.
As for the gateway, I'm using 2001:470:1f0a:1393::1. The problem with the fe80 address is that rtadvd reset it to the en0 link-local address, not the gif0's. Correct me if I'm wrong, but that would mean that all the ipv6 traffic would be routed to the LAN itself... failing miserably. If it used the gif0's fe80 address it would probably work, but for some reason rtadvd takes the 'en0' parameter to the extreme. Again, for some mysterious reason, giving an address to en0 via System Preferences makes it behave. Why doing so through ifconfig makes it dismiss it is beyond me.
As a side note trivia, all of my traffic from this machine originates from the tunnel IP (2001:470:1f0a:1393::2) rather than the address I manually assigned to the en0 (2001:470:1f0b:1393::1984). Not a big deal, at least that has a reverse DNS entry. :)
Thank you all, for the help and for the explanations!
FWIW. I was doing RA on my tunnel machine for a couple of months (FreeBSD) and everything was working fine. The gateway was set to the fe80 address of em0 on my tunnel server and the tunnel server knew where to send it from there. Maybe it's a bug in OSx?
It may very well be, because I pretty much used the same commands I used on FreeBSD (as they're very similar — the main difference being that it was called rl0 instead of en0), and OS X choked on it.
I actually found someone having the very same problem... in 2007: http://discussions.apple.com/thread.jspa?threadID=1008547&tstart=1996
Let's just say that OS X's implementation of IPv6 is a bit flaky. There's a strange bug that hasn't been addressed yet, that makes the internal resolver prefer IPv4 over IPv6 depending on the order that the responses are received from the DNS.
My plan is to ultimately get a tiny machine like an Asus Eeebox, installing FreeBSD on it, and have it do tunneling and a few other things. v4 routing is handled by my DSL router and is fine like that, but I wouldn't mind a decent and cheap machine to take care of a few things.
(I had originally considered getting an Apple Airport Extreme access point as several machines of mine are 802.11n capable, but it feels a bit like a waste compared to an actual mini-server.)
Actually 10.6.5 has "fixed" that resolver issues -- now OS X always prefers IPv4 over IPv6 when both A and AAAA responses are received, except in edge cases where one of the responses takes an abnormally long time to be returned. There's a difference of opinion on whether the 10.6.5 change is good or bad, as early adopters and those experimenting with IPv6 will see it as a flaw while the bulk of the Internet at large presently sees it as a good thing due to sites becoming unreachable due to botched IPv6 configurations -- the same reason that Google refuses to hand out its AAAA records to DNS servers that haven't specifically been approved for "Google over IPv6" (as HE has).
As to the original question, the autoconf in my ifconfig output was an error as I was actually pasting two pieces together -- I've been using a combination of a tunnelled connection and an automatic 6to4 gateway via my Time Capsule, since I can't configure the HE 6in4 tunnel through that (seems a manual 6in4 configuration doesn't work when using a PPPoE connection ::) ). At any rate, in my case OS X seems to handle rtadvd just fine as long as I'm configuring manually, regardless of whether I script it through ifconfig or use the System Preferences. I think the key is the net.inet6.ip6.accept_rtadv setting, which I leave OFF (0) for the HE tunnel machine, and I've noticed that setting up my IPv6 configuration manually in System Preferences actually toggles that setting off automatically as part of the process. I suspect when rtadvd starts up it may be looping back the link-local assignment to the local RA listener, which causes the default route to get updated inadvertently. Obviously running rtadvd and listening for RA's would be mutually exclusive in most cases. :)
I had thought so too, but I even tried explicitly setting net.inet6.ip6.accept_rtadv to 0 (which yielded "0 -> 0"). Anyway it seems to work now, even though, like your Time Capsule situation, it's a bit of a mystery. :D As I said I hope this is just temporary, I eventually plan on getting a mini-server to handle a few other tasks too.
Are you sure about 10.6.5 preferring A over AAAA?? If I head on to sites like http://testmyipv6.com/, I am greeted by "Excellent! You are using the snappy new IPv6!"
Speaking of which, how would I proceed to have OS X use my en0 address for outgoing connections by default, rather then the gif0? I imagine I'd have to fiddle with the route command...
With regard to 10.6.5, I get my plain-old IPv4 when surfing to testmyipv6.com. There's an article over at ArsTechnica discussing the change (http://arstechnica.com/apple/news/2010/11/apple-fixes-broken-ipv6-by-breaking-it-some-more.ars). I've overridden this in my case by specifying the IPv6 addresses explicitly in my /etc/hosts file for those sites that I want to ensure I'm visiting over IPv6 (ie, ipv6.he.net, mail.google.com, etc).
I haven't bothered tackling the address issue with regard to outgoing connections. My machines that are behind the tunnel gateway on the local LAN all use their respective routed /64 addresses without any issues -- it's only the tunnel machine itself that's defaulting to the gif0 address, since that of course is technically the uplink interface. It's the same concept as in IPv4 routing -- the "public" or "nearest" address is always used, and it's not really anything I've ever bothered to ponder much as it's the normal state of affairs in the IPv4 world. :)
Update: Actually, it seems that when using a manually configured tunnel through he.net (6in4 vs 6to4) it sometimes works. The AAAA/A prioritization bug may still be the issue here - haven't tested it enough to be certain. In looking at the 10.6.5 changes in more detail it seems they only prioritize IPv4 traffic when using a 6to4 (automatic) gateway. Toredo and 6in4 tunnels are still otherwise prioritized, although it seems it's not quite working flawlessly yet, or there are other issues involved...
For some reason, the automatic script stopped working again. I'm about to smash my head against the desk. The default route went back to being the wrong one:
Internet6:
Destination Gateway Flags Netif Expire
default 2001:470:1f0a:1393::1 UGSc en0
Simply running:
route -n delete -inet6 default
route -n add -inet6 default 2001:470:1f0a:1393::1
revers it to:
Internet6:
Destination Gateway Flags Netif Expire
default 2001:470:1f0a:1393::1 UGSc gif0
and all's good and great again.
I'm almost tempted to just go and get a secondhand nettop...
Or to switch to a real OS?
;)
Just Kidding.
Ah, come on. This is the only issue I've had with OS X in nine years. :)
BTW, I have been running into the same issue. I have just been manually resetting the default route, as rtadvd seems to overwrite it. I then let the link-local address be advertised out as I only have a single network at home and that works fine. While I would like to figure this out, it does seem that rtadvd config is a bit of a black art and I have not been able to grok it in my spare time. If I make any progress I will re-post.
I would like to hear if you come up with a solution. It's been extremely frustrating to me, to the point that I ended up reducing my v6 connectivity. If I need v6 on more than one machine, I'll boot up the old freebsd 'sandbox' pc, curse under my breathe, do what I have to do, and shut it down.
Have you tried using radvd? I just noticed it's available through macports, I wonder if it works any better. I'm a bit short on time these days, but if you can't manage to give it a try, I will do it in a week or so.
radvd @1.6 (net)
Variants: universal
Description: The router advertisement daemon (radvd) is run by Linux or
BSD systems acting as IPv6 routers. It sends Router
Advertisement messages, specified by RFC 2461, to a local
Ethernet LAN periodically and when requested by a node
sending a Router Solicitation message. These messages are
required for IPv6 stateless autoconfiguration.
Homepage: http://www.litech.org/radvd/
Platforms: darwin
License: unknown
Maintainers: lars.rasmusson@sics.se