I have set up a tunnel using Hurricane Electric's services on a Debian machine. It seems to work alright; I can ping6 ipv6.google.com
and open it in links
.
I've also set up a PPTP daemon on the machine. (Yes, I've read that PPTP is insecure; this is primarily for experimental purposes.) When I connect to this PPTP daemon using Mac OS X, IPv4 works fine.
I seem to be unable to get routing of IPv6 traffic to work, however. OS X doesn't pick up an IPv6 address over PPTP, and it ignores announcements using radvd
, which seems to be a daemon for announcing IPv6 router's existence. To clarify: I see the router announcements sent by radvd
appear in Wireshark on the OS X machine's ppp0 interface.
Overall, this is not a production nor a long-term setup, just something I'd like to get to work (otherwise I might be posting on ServerFault). So I don't care about the fact that if the machine reboots, half of the setup goes down with it until manually reset. In fact, that's a plus for me, in this case.
/etc/network/interfaces (snippet)
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
address 2001:dead:beef:f00d::2
netmask 64
endpoint 216.66.86.114
ttl 255
gateway 2001:dead:beef:f00d::1
/etc/pptpd.conf
option /etc/ppp/pptpd-options
localip 10.0.101.1
remoteip 10.0.101.2-200
/etc/ppp/pptpd-options
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
proxyarp
nodefaultroute
lock
nobsdcomp
ipv6 ,
/etc/ppp/chap-secrets
ivucica pptpd THEPASSWORDHERE 10.0.101.2 10.0.101.3 10.0.101.4 10.0.101.5
/etc/radvd.conf
interface ppp0
{
AdvSendAdvert on;
prefix 2001:dead:beef:f00d::/64
{
};
};
I turned on ipv6 forwarding:
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
And yes, I did restart radvd
whenever I reconnected/recreated-the-ppp0-device. 🙂
What am I missing?
Best Answer
So it turns out there were several issues with my setup. Let's document everything!
Client OS
Mac OS X does not particularly like IPv6 over PPP. Use the following after the connection has been set up:
The prior seems to make OS X adhere to router advertisements; the latter adds a default route for IPv6. (Now, if only the certain-fruity-mobile-operating-system version of
route
provided-inet6
, I'd be a happy wooden boy.)Also take note that OS X will ignore whatever address was supposed to be negotiated over IPv6 and set up only a local address. This may interfere with routing towards OS X.
On the other hand, Windows 8 (of all systems!) has happily picked up the address sent over PPP, took note of the router advertisement, and overall configured itself flawlessly. PPTP really works nice in Windows.
Server
First thing I missed was that Hurricane Electric's tunnel broker actually assigns TWO /64 prefixes; one is supposed to be solely for client use, while the other is intended for routing additional clients (such as the PPTP client). And if you need more addresses (or prefixes!), you can even get a /48 prefix. (With IPv6, this means there's more bits for 'your' use; HE's prefix takes 'only' 48 bits. So that provides you a few more bits to control before the auto-generated suffix, created from a MAC address or even created randomly, kicks in and takes over last 64 bits. You could theoretically wiggle and subnet even with only 64-bits to spare, but I've seen strange behavior on either Windows 8 or OS X, so I wouldn't rely too much on that.)
Instead of configuring
radvd
directly and running it as a server -- simply don't configure it globally. That is, don't run it as a service on Debian.Instead, let's follow Konrad Rosenbaum's example, at Silmor.de, and have
radvd
configured afterpppd
creates the PPP interface.Set up your IPv6 connectivity. I use Hurricane Electric; I've configured it as follows:
Install pptpd. (Of course, take note of PPTP's insecurity as a protocol, and consider using OpenVPN or some other alternative.)
Edit
/etc/ppp/pptpd-options
Note the last line is different from the text in my question. You're assigning some static addresses which may be respected by your client OS or not. (OS X seems to ignore them, but Windows uses them.)
Create users for PPTP. Second column filters based on
name
argument inpptpd-options
. Edit/etc/ppp/chap-secrets
:You're supposed to be able to replace the addresses with
*
instead of listing them manually. I did not try that out.Assign your PPTP users some IPv6 prefixes. NOTE: this is solely used by the script I'll list below, which is derived from Konrad's script.
Edit
/etc/ppp/ipv6-addr
:Add new file
/etc/ppp/ipv6-up.d/setupradvd
:Don't forget to chmod the script to make it executable by
pppd
:The script spews
radvd
configuration into/etc/ppp/ipv6-radvd/
… ensure that the folder exists!Also add
/etc/ppp/ipv6-down.d/setupradvd
(and make it executable!) -- taken verbatim from Konrad:And
I have not tested using DHCPv6 to distribute the routing information, addresses or DNS information, especially since
rtadv
should be fulfilling these roles. It also would not help me, because as of Mountain Lion, OS X still does not ship with a DHCPv6 client (perhaps intentionally;nine out of ten dentistsmost of IPv6 experts agree that DHCP is evil).Once again, please note Michael's comments on PPTP security; consider using OpenVPN in production.
Yes, Konrad Rosenbaum also has a nice tutorial on IPv6 over OpenVPN. :-)