Introduction

I recently had the need and opportunity to setup my Raspberry Pi as a public server running in my home network. During the process, I found a few issues that I wanted to share to save everyones precious time. The first is about the appropriate choice of the address configuration mode for IPv6. The next is about using a subdomain of your website domain (in case you have one) despite being in an environment with ever changin addresses. The last is about a nuisance that comes along with the "lack of" NATing in IPv6 in combination with default home router settings.

IPv6 Specificities

With my home network being a dual stack (IPv4/IPv6) network, I also configured the Pi as an IPv6 server. In doing so, I ran into several problems that were difficult to debug.

First of all, I expected the interface identifier (IID) to remain static. This was not the case in the default Raspbian configuration. A static IID is important to create a permanent clearance for the Pi in my home router's firewall. Most often, SLAAC derives IPv6 addresses or IIDs from the MAC address of the interface. However, there is a variety of modes available to do this. In the default Raspbian configuration, the mode is chosen to be the mode defined in RFC 7217. In short, RFC 7217 produces "stable" interface identifiers "per network", meaning that a new IPv6 prefix, which I get from my provider every now and then, results in a new interface identifier. For a server scenario, this is pretty much useless, as my home routers firewall configuration is based on, you guessed it, the interface identifier. Therefore, if you do not have a stable IPv6 prefix, do not use RFC 7217 addresses for such nodes.

I also learned that most modern Linux distributions use the RFC 7217 address configuration by default. So, please be aware of the consequences.

Using Proper Names

When I configured my server, I wanted it to be available with a nice name, possibly a subdomain of my web site. My hosting provider allows for just this. So, I registered a dynamic domain name for my Pi with a provider offering both IPv4 and IPv6 resolution, say abc.dynxyz.net. Also, I created a subdomain to my domain having a CNAME of this dynamic DNS name. Thus, my subdomain will always be resolved to my Pi at home. This can be verified as shown in the following snippet.

$ dig AAAA sub.b-hagemeier.de
...
;; ANSWER SECTION:
sub.b-hagemeier.de. 49     IN      CNAME   hagemeier.dynv6.net.
hagemeier.dynv6.net.    49      IN      AAAA    2001:4dd7:d9e8:0:...
...

DNS Rebind Problem

The next problem I came across was that my home router defaults to preventing DNS rebind attacks by disallowing IP addresses in the local network in responses from external DNS servers. In the NATed IPv4 world, this does not pose a problem, as the DNS response will point to the router's external IP. In the IPv6 world, however, NATing is unheard of. Therefore, our server's public IP address, which is within our internal network, will be returned by an external DNS server when I request its IP. My home router simply blocks this, such that I can happyly resolve my server's IP anywhere but not at home. In my Fritz!Box I mitigated this by adding my server's domain to the list of exceptions from the DNS rebind protection. Et voilà!

Now, I can access my server from anywhere, be it external or internal networks.

I hope this small compilation of things I came across may be useful for someone.