Just a few days ago I gave a talk at Troopers 18 in Heidelberg, Germany, about the problems of dynamic (non-persistent) IPv6 prefixes, as well as IPv6 VPNs in general. Following are my slides and the video of the talk:
I am lucky to have a full dual-stack ISP connection at home. However, the ISP only offers a dynamic IPv6 prefix with all of its disadvantages (while no single advantage). In this post, I am summarizing the limitations of a dynamic prefix and some of the ideas on how to overcome them. I am always comparing the “IPv6 dynamic prefix” state with the legacy “dynamic IPv4 address” situation. I suppose that some of these problems will hit many small office / home office locations during the next years.
Of course, IPv6 ISP connections with dynamic prefixes should only be purchased at private home sites. It is no problem to have new IPv6 addresses there because all connections are outbound. However, many small remote offices (SOHO) might rely on such cheap ISP connections, too. If they provide some servers in a DMZ or other components such as network cameras, building components with IPv6 connections, etc., they will run into these kind of problems. (The remote office could even tunnel every outbound IPv6 traffic through a VPN to the headquarter. But if it wants to use a local breakout, this won’t be an alternative.)
How to route traffic inside an IPv6 site-to-site VPN tunnel if one side offers only dynamic IPv6 prefixes? With IPv4, the private network segments were statically routed through the tunnel. But with a dynamic prefix, a static route is not possible. That is, a dynamic routing protocol must be used. Here is an example of how I used OSPFv3 for IPv6 between my VPN endpoints.
In detail, I have a home office with a dual stack ISP connection. However, this connection has a dynamic IPv6 prefix: After every reboot or lost connection of the firewall, I get a new IPv6 prefix. This is really bad for building a site-to-site VPN to the headquarter. Since I don’t want to use any kind of NAT/NPTv6 with unique local addresses, I am talking OSPFv3 over the VPN tunnel in order to route the dynamic prefix range (global unicast) via the tunnel.
The Juniper ScreenOS firewall is one of the seldom firewalls that implements DHCPv6 Prefix Delegation (DHCPv6-PD). It therefore fits for testing my dual stack ISP connection from Deutsche Telekom, Germany. (Refer to this post for details about this dual stack procedure.)
It was *really* hard to get the correct configuration in place. I was not able to do this by myself at all. Also Google did not help that much. Finally, I opened a case by Juniper to help me finding the configuration error. After four weeks of the opened case, I was told which command was wrong. Now it’s working. ;) Here we go.
Bis neulich hatte ich einen normalen DSL-Anschluss von 1&1: Per PPPoE eingewählt und eine IPv4-Adresse bekommen – fertig. Das kann neben der FRITZ!Box natürlich auch jeder vernünftige Router oder Firewall.
Jetzt habe ich endlich einen richtigen Dual-Stack (IPv4 und IPv6) Anschluss der Telekom (Glasfaser “MagentaZuhause M” ohne Fernsehen, siehe hier). Juchu! ;) Bevor ich jedoch den mitgelieferten Speedport durch diverse andere Testgeräte ersetze, wollte ich mal vernünftig mitschneiden, welche Protokolle denn bei einem Verbindungsaufbau genau eingesetzt werden. Vor allem die Prefix Delegation über DHCPv6 interessierte mich…
For dynamic IPv4 addresses, dynamic DNS services such as Dyn or No-IP are well-known. If an ISP issues a single dynamic IPv4 address every 24 hours (or the like), the router or any other device registers the IPv4 address for a DNS record. With port-forwardings on the router, several services on different clients can be accessed.
Since there are some ISPs that offer dynamic IPv6 prefixes as well, I have a suggestion on how to optimize the “dynamic DNS” service for several IPv6 addresses and names. The main idea is to update only the IPv6 prefix, while the host IDs are static configured on the DNS server. This limits the DNS updates and expands the usage of DNS names even for devices that have no “DynDNS update client” built-in.
Seit Monaten sieht man auf heise online an der rechten Seite den Link zu einem Artikel namens “IPv6-Präfixe würfeln“. Dabei geht es darum, OpenWRT einen Teil des IPv6-Präfixes innerhalb gewisser Zeitspannen würfeln zu lassen, damit normale IPv6-Clients nicht nur die Interface-ID der Adresse per Privacy Extensions regelmäßig ändern, sondern auch die Subnetz-ID. Da diese Idee aber so gar keinen Vorteil für den Datenschutz mit sich bringt, möchte ich hier mal etwas dazu schreiben.