Category Archives: IPv6

Update 2015/01/03: You are probably here for one reason: how to use SNMP to switch this router to bridge mode? As this is unsupported by UPC Ireland, let’s hope they don’t spoil the fun for us. (After posting the main body of the post, I actually got a proper DD-WRT friendly router and have started using this.) So here’s what you’re interested in.

Additionally, concerning IPv6, at no later time have I observed receiving an IPv6 globally routable address, so I guess that was a lucky hiccup.

Based on this thread which I ran into here. These are just notes; if you can learn something from them, do so; but please be careful and fully aware that these are not instructions — merely notes for my own personal use in the future. I do not recommend you follow the notes; quite the opposite.

Despite (according to their reps on Twitter) telnet being unsupported by UPC, you can easily telnet 192.168.100.1 and use username: webstar, password: webstar to log into the console. There isn’t much to do there, sadly. Apparently you may be able to use the set command to control SNMP settings.

Some configuration of hidden features can be done via SNMP. I highly advise you not to do that. This is unsupported by UPC, and you might be unable to restore settings to the previous state.

To switch the device into pure modem, non-routing mode, supposedly you use:

This didn’t work for me immediately. It seems to work immediately after reboot. Also worth noting is the snmpwalk command:

snmpwalk -v2c -c public 192.168.0.1 1.3.6.1.4.1.4413.2.2.2.1.7.1.1.0

Note that the value of “1” means “modem mode” (also known as “bridge mode”), while “2” means “ordinary NAT+routing mode”.

Be very careful. Turning on “modem mode” breaks Wi-Fi. You may need to bring up a separate access point for Wi-Fi. You may have trouble restoring the setting. PUBLISHING OF THESE NOTES DOES NOT CONSTITUTE ENDORSEMENT TO ACTUALLY USE THEM.

Also, I was unable to restore the setting to “2” using SNMP. Hard reset by holding the reset button for 30 seconds worked. Unless you use it strictly as a modem, with another device that performs NAT and IPv6 routing, it isn’t worth switching to NAT mode. So please don’t do this unless you’re fully prepared for breakage of service and possibly annoying UPC (since they obviously don’t want people to play with this).

It’s interesting that UPC does assign a public, fully routable IPv6 /64 prefix. Too bad that it’s not exposed to regular users locked behind a NAT who cannot get direct access to the public Internet, and who have been locked out of it by a firmware that is seemingly arbitrarily restricted compared to the one used in Netherlands. UPDATE: Two sources have told me that they did not receive an IPv6 prefix or address. As I am not keeping my device in bridge mode, and I do not advise readers to do so either (unless they have very good reasons), I cannot and won’t verify this. You can opt to leave a comment on your success, but I want to be clear that neither my text, nor any comments below, represent any advice on my part.

It’s also interesting that the setting seems to have survived a factory reset through the web interface. Factory reset through web interface has, however, restored WiFi functionality, and it seems that WiFi and LAN are getting separate IP addresses. Factory reset by holding the reset button for 30 seconds is the actual hard reset and cleans up the setting for “modem mode”.

In the post, I’m also looking into using this under Mac OS X 10.8 Mountain Lion. I fully understand that PPTP is an insecure protocol and have separately also set up OpenVPN. However, I’m looking at this because PPTP is much more ubiquitous than OpenVPN and it’s easier to set up at both server and client side; no playing with certificate authorities, no playing with distributing configuration files to clients, etc. (Yes, I’m highly annoyed at the OpenVPN client for iOS not supporting the static key setup. Yes, I understand static key is less secure. No, I’m not dealing with stuff that require total and complete anonymity or encryption; I just want a VPN to work.)

This post does not deal with routing the segment through OS X once you got it to OS X.

This post only minimally deals with Windows as a client, because it Just Works™, and does not deal with GNU/Linux as a client, because it didn’t “magically” work under Ubuntu when I tried it, and I am not interested enough to figure out why.

Main goal here is documenting what an OS X user who has access to a Debian server with a public IP needs to do in order to get his OS X machine onto public IPv6 Internet without exposing it to public IPv4 Internet.

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.

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 in pptpd-options. Edit /etc/ppp/chap-secrets:

I have not tested using DHCPv6 to distribute the routing information, addresses or DNS information, especially since rtadvshould 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 dentists most of IPv6 experts agree that DHCP is evil).

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy

Support me!

Need a host with root access over SSH where you can deploy a blank machine within 60 seconds? Need a host billed per hour, that costs only $5/month (that's less than a cent per hour)? Try Digital Ocean!