After todays (8+ hours) outage at Fremont, we obviously needed to move , so we migrated to Dallas. Dallas like other sites (except Atlanta) hand out IPv6 , which we want turned off...

Usually we'd ask support to turn off the IPv6 and that would be that..

Maybe it was todays stress or what not, or maybe because I was asking for 10 nodes to be touched... but I get this answer:

Oh well for customer service.

Greetings,

Thank you for taking the time to contact us. We've been disabling IPv6 on your Linodes in the past as a courtesy. However, we must ask that that you disable IPv6 on each Linode by killing off the routes and disabling autoconfiguration and accepting of router advertisements.

To accomplish this you would want to issue these commands:

echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/default/accept_ra
echo 0 > /proc/sys/net/ipv6/conf/all/autoconf
echo 0 > /proc/sys/net/ipv6/conf/default/autoconf

You would then want to add these lines to the end of '/etc/sysctl.conf':

net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0

Finally you'll either want to reboot your Linode, or manually remove IPv6 from your networking:

ip -6 addr del <IPv6_address>/64 dev eth0
ip -6 route flush dev eth0

I hope this helps! If we can be of any further assistance don't hesitate to contact us.

Regards,
Tim

personally, I'd be happier knowing how to disable IPv6 myself so I didnt have to rely on support everytime I needed it doing.

I was not even aware that support would do such tasks. I was under the impression it was fully un-managed, meaning; here is your smoking fast Linux VPS*, have fun.

* If your VPS is in the Freemont DC, it may or may not be available to fully enjoy that fast Linode experience.

What ever. If they went in and touched your VPS to make configuration changes without additional compensation, they went way and above what they advertise for their service. Linode is un-managed. Your are your administrator. I wouldn't dare ask them to make any configuration changes to my servers. If I don't know how, I'll figure it out. They manage the network and the physical host, not your VPS.

It is unmanaged. Which is why they said they've done it as a courtesy in the past, but were unwilling to do it this time; you're asking them to manage your linodes for you, and it's an unmanaged service.

The fact that they still provided detailed instructions on how to do it yourself is nice, because some unmanaged hosts would just refuse to do it and leave you to figure it out for yourself.

I think the OP means turning off IPv6 on the host or router level, for that node. Seems like, at least in Dallas, IPv6 is or will be automatically and unconditionally enabled, so if you want it off, turn it off on your own nodes.

You can do it on the network config level, firewall level, application level... your choice.

It's not just Dallas, nor, for that matter, really Linode specific, compared to any network using IPv6 autoconfiguration.

For the OP, IPv6 autoconfiguration is based on router availability broadcasts, so it's not quite the same as a DHCP process, for example. A central router, or routers, broadcast availability, and then the individual clients hear that and automatically pick addresses. So there's no central knob to block/configure any individual client node, as it's all based around a common broadcast.

So while you may not have realized it, your request to Linode was essentially a request for guest-level changes. That's why many responses here are talking about the un-managed nature of a Linode. I suppose Linode could configure hosts to manually filter IPv6 traffic on behalf of a guest, but as with IPv4 filtering, that's not something the hosts currently get involved with.

At this point (at least at the IPv6 enabled data centers), spinning up a Linode is the same as using pretty much any PC with a current OS on an IPv6 enabled network, where the client is going to see IPv6 availability, and its up to the client configuration how it uses that. In most cases that will mean obtaining an auto-configured address.

As Azathoth noted, this process can be blocked on your Linode at multiple levels, one of which Linode supplied details on (stopping the auto-configuration process). For myself, on nodes I don't want to worry about IPv6 on, I tend to just block it at the firewall level, but that's just personal preference.

-- David

iptablesv4 is a struggle for me - is there a simple ipv6 line that blocks ipv6 at the firewall level.

Hope this is ok to ask here as it is somewhat different from OP.

The approach of the original post would be my first recommendation, from a practical standpoint. However, this will drop all IPv6 traffic as well:

ip6tables -F
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT
ip6tables -P INPUT DROP
ip6tables -P OUTPUT DROP
ip6tables -P FORWARD DROP

Basically, same as you'd do for IPv4, but with "ip6tables" instead of "iptables".

_________________

/* TODO: need to add signature to posts */

For myself, I think just the DROP policy rules are sufficient (and really, the INPUT table is the only critical one). If you're trying to ignore IPv6, it doesn't really matter if loopback works.

Blocking input packets will also block the routing announcements and most likely prevent an autoconfiguration address from being selected (though there may be a race condition at startup depending on when the tables are loaded).

-- David

Thks Hoopy and db31 - I have gone with the OP solution, did a reboot and the server comes back up ok. I still have the public IPv6 in my dashboard but trust it is disconnected.

Don't trust -- check. Run "ip -6 addr" and see if there are any public IPv6 addresses.

_________________
Matt Nordhoff (aka Peng on IRC)

I was thinking about checking a little later, but thanks - this is what I found:

:~$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2600:3c03::f03c:ZZZZ:YYY:XXXX/64 scope global dynamic 
       valid_lft 43122sec preferred_lft 43122sec
    inet6 fe80::f03c:ZZZZ:YYY:XXXX/64 scope link 
       valid_lft forever preferred_lft forever

(X,Y,Z redacted)

So ... I am out of my depth here but it looks like it is still up?

Yes, it does. Did you edit /etc/sysctl.conf? If you just ran the 'echo' or 'ip' commands, they'll be forgotten on reboot and it'll get reenabled.

_________________
Matt Nordhoff (aka Peng on IRC)

It is becoming common to treat IPv4 as a subset of IPv6 within applications. For example, your web server likely binds itself to TCP6 socket [::]:80 instead of to TCP 0.0.0.0:80, which will handle the IPv4-only, dual-stack, and IPv6-only cases with one socket. Likewise, even if you disable external IPv6 connectivity, there could still be IPv6 going across the loopback if two IPv6-aware applications want to talk to each other.

I don't know if this actually happens in practice; logging might be a good idea. I personally err to the side of not breaking localhost, since I've done it before and things get very bizarre. But I also treat IPv4 and IPv6 as equivalent security surfaces, so I haven't tried totally blocking IPv6 yet either.