IPv6 router solicitation, Link-Local gateway, Ubuntu and a bit of WTF…

I have been using RHEL/CentOS lineage Linuces for a good while  now, and I believe the strength and distro mindset is their dedication to package dependencies.  Some packages or software that require bleeding edge or even not so recently updated/released libraries/CPAN perl modules etc don’t behave well or won’t install/compile without breaking those dependencies without installing source packages.  This paradoxally is the weakness of RHEL/CentOS, their dedication to dependencies runaway  They occasionally are a bit behind when it comes to the latest and greatest, and you cat get handcuffed if you want to remain within the confines of the dependancy sandbox.


In any case I wanted to toy with some software that clearly seems written for Ubuntu (first tell-tale sign is that you need to add a bunch of user-contributed repositories so you can install it….)  This software requires IPv6 connectivity so I decided to trash a BIND virtual server I was using and replace it with Ubuntu 14.04 from the .ISO.  I am not totally foreign to Ubuntu as I use Ubuntu desktop on a couple laptops, however in a server environment I have never bothered to consider it out of laziness, mostly.  Here are a few observations, some of which I am still trying to wrap my head around.


BIND startup

My first challenge was getting BIND to start correctly.  I usually use “listen-on-v6” to specify what interfaces I allow BIND to bind to, and was seeing this incredibly annoying message on bootup and BIND was not binding to any IPv6 addresses, defeating the purpose of running BIND on this server in the first place:

yet 2001:db8:9::37/64 is statically configured in my interface config (!!):


apparently, Ubuntu is in such a hurry to boot that it starts daemons before the interface init is even finished (!)  Major-wtf.  So it would seem that it is prudent (and necessary?) to put the IPv6 definition of eth0 inet6 *before* IPv4.  Guess that is good to know doh  Once thats done, BIND starts correctly and we can move on.

IPv6 default gateway gong-show

My next hurdle was not far away.  Even if I manually set the gateway, for some reason Ubuntu seems to feel it necessary to send a router solicitation… My network has regular router advertisements disabled, just because I don’t want SLAAC to work in that particular test environment.  So even if I statically configure Ubuntu with a prefix, mask and gateway, it still seems to feel a need to go exploring for routers and sends out an ICMPv6 router solicitation…so when I check the routing table:

now wait a minute!  My network does not send periodic RAs, I have statically defined my gateway, and Ubuntu overrides whatever I defined with auto-learned crap??  surprised  After 500 seconds, the RS-learned gateways disappear and whatever I defined as default then remains, and sometimes no gateway at all…..

Link-Local Gateway

Remember I mentioned above the bit about putting the IPv6 config before IPv4?  My network uses HSRP as first-hop redundancy, and IOS didn’t allow for global addressing (and some supported IOS trains do not have this feature) until “recently”.  In any case, I want to use a link-local address as a gateway.  For some reason, if the IPv6 interface in Ubuntu is defined *after* the IPv4 address, the LL gateway sometimes is ignored (what?runaway)  So not only do I get possibly bogus gateways via ICMPv6 router solicitation, I might end up with no gateway at all once those RAs lifetime is up.  not good.

The solution is to disable router-advertisement learning in /etc/sysctl.conf by adding the following:

and contrary to RHEL/CentOS (and pretty much any environment where a link-local is used to route something that I have seen), it is not necessary to specify the interface – I suppose Ubuntu is doing some logic there:



So we note the absence of %device.  I would have to test if with multiple NICs this still works.  Hopefully it does pc


Network restart broken


My last adventure was trying to restart networking in some controlled way after making changes.  I believed I had broken my install when I got the following as a result:

After some googling, apparently this is known.   So shucks, another thing that will hopefully get fixed wassat   At the rate Ubuntu seems to update packages, I suppose it might not be a long wait pc




Samsung Galaxy S4 – IPv6 borked….

I have been running around trying to figure out why my Samsung Galaxy S4 (Android 4.3) seems to lose its IPv6 prefix when it has been sleeping for a while. At first I blamed my edge CPE device, as I had rebuilt a OpenWRT recently and switched from WIDE-DHCPv6+RADVD to 6relayd.  And I had never noticed if the previous implementation had this issue or not.

Symptoms:  If I leave the device idle for a certain amount of time (which apparently would be longer than the preferred life of the prefix), when I open the browser I note that v6-sites are not reachable until my router sends an unsolicited RA.   I installed some free apps such as MyIPv6 and Network Info ii and although all seemed normal during phone use, after a certain time the prefixes would be non-functional, and would even not appear in these apps as existing, until the next RA sent by the router and all would resume correctly.

As well, if for whatever reason the prefix received by prefix delegation changes, an idle device (read: screen off….) will only learn of the new prefix once the route sends an RA containing that new prefix.


Out of desperation I started googling and apparently I am not alone:



I especially liked the comment from the Samsung developers:

OK, well I tested this, as did the reporter of this issue.  Simply locking the phone (turning off the screen), with an ICMP ping to the IPv4 and IPv6 addresses respectively.  The IPv6 address of my phone ceases to reply to ICMP echo requests when I turn off the screen (as expected) –  YET IPv4 REQUESTS ARE NOT IGNORED and replies are sent by the GS4!   So what gives, Samsung devops?  This is with or without the power saving features enabled.  I don’t believe this cockamamie notion about  running down batteries – its either laziness, incompetence or an outright dismissal of a bug.

And frankly, I wouldn’t really care if ICMP echo/echo-reply data was discarded, however ND, RA and other critical v6 traffic shouldn’t be.  Or, at the very least, send a solicited RA or reset the IPv6 stack entirely, because when the phone wakes from sleep or is unlocked, the IPv6 stack is broken up until a router sends an RA.  And in my case, 6relayd seems to send one every 7 minutes or so, with a randomized +/- interval of a few seconds.  And some networks I have connected to send RAs every hour, not every few seconds, since IPv6 protocols allow for address assignment to occur without RAs….So it could be a long wait!  And even if a network sends an unsolicited-RA every 30 seconds, that is 30 seconds where your connectivity is v4-only when you benefit from a dual-stacked environment.  Not very modern-ish behaviour by a so-called industry leader!

I hate to admit it, but I tested iPhone4, 4S, 5 and iPad mini as well as Windows XP/7, and they all behave correctly when woken from whatever state they were in post-prefix-expiry.  I will be borrowing some other Android devices as I can get my hands on them to compare results.  But as of now I don’t have a very high regard for Samsung’s IPv6 implementation!


Samsung coders need to get a clue!  “End users can connect to networks continually by IPv4” is not an acceptable answer.  As IPv6 grows in popularity and necessity, that is a pretty bone-headed opinion.  Need I point out that at the time of this writing, that forum post is less than 6 months old!


BIND DNS64 and views

I am starting to experiment with IPv6-only networks and require the use of a DNS64 service to be used in conjunction with NAT64.  Luckily, BIND 9.8.x offers this capability.  However, I don’t want my DNS server to reply with a quad-A record for every query now that I have enabled DNS64, since this DNS server is used by non-v6 clients, as well as dual-stack clients that I do not want to send them searching for 64:ff9b::/96. :S  I therefore added a secondary IPv6 address on the DNS server for my v6-only clients to use specifically for DNS64, and put it in its own view.  In the config below, the BIND DNS64 service will utilize 2001:db8::64 🙂


acl rfc1918 { 10/8; 192.168/16; 172.16/12; };
options {
        listen-on port 53 {
        listen-on-v6 port 53 {
view "external" {
match-destinations { 2001:db8::10; ::1;;; };

}; //end view external
view "dns64" {
    match-destinations { 2001:db8::64; };
    dns64       64:ff9b::/96 {
        clients { any; };
        mapped { !rfc1918; any; };
        exclude { 64:ff9b::/96; ::ffff:0000:0000/96; };
        suffix ::;
}; //end view dns64


the corresponding digs show the difference between

dig @2001:db8::64 +short -t AAAA www.cnn.com
dig @2001:2b8::10 +short -t AAAA www.cnn.com

Looks like I am ready to start working on learning how to use TAYGA