Tuesday, September 26, 2017

Request: Less Dynamic Prefix, Mr./Ms. ISP

by Craig Miller


There are two types of Global Prefixes, one that is provider independent (PI), allowing one to switch ISPs and keep the same prefix, and the other is provider aggregatable (PA), where the upstream provider allocates a prefix from their block.

PIs are great, and one need only go to your local RIR (Regional Internet Registry) to request/pay for a prefix block. But realistically, only larger organizations will go this route. Many smaller organizations and homes will use PA prefixes.

PA made easy

Through the magic of DHCPv6-PD (DHCPv6 with Prefix Delegation), allocating a prefix (either a /64 or less) to a small business or home is easy. Modern routers will make the PD request, and advertise the allocated prefix into the SOHO/home LAN, and IPv6 end to end connectivity is available.

ISPs are used to having their customers have a dynamic DHCPv4 address. But with many ISPs, a router reboot will result in the same IPv4 address, since the router is using the same MAC address to make the request.

With DHCPv6, a DUID (DHCP Unique Identifier) is used rather than a MAC address. But similar to the MAC address in DHCPv4, the DUID does not change between router reboots, and therefore DHCPv6 requests can receive the same external IPv6 address on the router.

PA Prefix disconnect

Alas, this is not the same for PA prefixes. Inside the ISP, there seems to be no connection between DHCPv6 address allocated and PD prefix allocated to the customer. This results in a semi-static outside IPv6 address on the router, and a very dynamic (changing with every connection/reboot) PD prefix in the customer's LAN.

A very dynamic LAN prefix causes some challenges, such as:

  • downstream routers, may not update to the new prefix in a timely manner causing unknown network outages which are mysteriously fixed by rebooting
  • Some DNS sserver configuration requires a Global Address, if the SOHO/home is using its own DNS server, or a DNS service other than the ISPs, this configuration may require updating with each new PD prefix
  • Network servers on the LAN will have changing IPv6 addressesj, making file sharing, and other network services difficult
  • Firewall configuration, allowing external access

Some of these issues can be mitigated by using a ULA (Unique Local Address) prefix on the LAN in addition to the ISPs very dynamic PA GUA prefix. But that requires more IPv6 knowledge than just plug in play.

Please, a less dynamic PA prefix

Dear Mr./Ms. ISP, I would like to have less dynamic PA addresses. As a customer, I would like to have the address prefix (assigned via PD) linked with my DUID and DHCPv6 address records. At the end of the day, we all want IPv6 to be simpler for the customer.


* note, a provider provides a PA address via DHCPv6-PD (Prefix Delegation)


Monday, July 17, 2017

Shooting fish in a barrel

by Craig Miller


I say this often, IPv6 is not like IPv4. There are key differences which one can and should take advantage of.

Like shooting "fish" in a barrel
Address space is one of them. Scanning an IPv4 address range takes very little time. And the return is rich, with the conservation of address space mind-set, the hosts/targets are closely packed in an IPv4 subnet. It is like shooting fish in a barrel.

Malware using the zmap scanner

A recent Linux malware Linux.MulDrop.14 uses the scanner, zmap, to search for other victims on the network. Zmap man page boasts that given a 1 Gbit connection to the internet, it can scan the entire internet in 45 minutes. Of course, it isn't the entire internet, since zmap doesn't support IPv6 (yet). So what it is really saying is that it can scan 2^32 (or 4 billion) addresses in about 45 minutes.

The numbers of high performance scanning in IPv6

So let's work with that number for a minute. Assuming that zmap and other scanners will support IPv6 in the future, how much time will it take to scan a /64 with a high performance scanner like zmap. How many 2^32 chunks are in a /64? Conveniently the answer is 2^32 or 4 billion internets (of addresses) in each /64 subnet.

So given that it takes 45 minutes to scan 4 billion addresses, how long would it take to scan a /64? It should be 4 billion times 45 minutes or 367,719 years. As you can see, what looks to be a high performance IPv4 scanner, is quite impracticable for scanning IPv6 subnets.

But that is based on the assumption that the IID (Interface IDs) are taking the entire /64 range. I have seen many DHCPv6 installations where the IPv6 address range is much smaller, as small as /119 or 512 addresses! Clearly, one does not need a high performance scanner to scan 512 addresses. In fact, tightly restricting the IPv6 address space (via your DHCPv6 pool) in a subnet is asking scanners to target your hosts.

Make it harder for the bad guys, don't confine your hosts to a barrel

Use the advantages of IPv6 when creating your network, including utilization of very large DHCPv6 address pools. After all, you don't want the bad guys finding your hosts,  to be like shooting fish in a barrel.


* graphic from ralphiesportal.me


Sunday, May 28, 2017

IPv6 on the Go

by Craig Miller


IPv6 on the go
Here's another example of IPv6 in the palm of your hand.  This time it is a small battery-powered wireless router, smaller than a deck of playing cards. The router has 4G on the WAN, and Wifi on the LAN side.

Wireless Hotspot


While visiting with my cousin recently, he said he needed help upgrading his wireless router. I am always happy to help when I can. He was having all sorts of trouble getting the windows software to work. Being used to not running windows apps (I mostly run Linux), I looked for the upgrade option on the web interface on the router. There is usually lots of room for improvement in web user interface design for embedded devices, and little router was no exception. It took a bit of perusing the menus to find the upgrade option, but once done, the router was upgraded and it was then that I noticed that the little 4G router not only was doing IPv4 NAT (expected), but was also providing IPv6 on the LAN (Wifi) side.
Note the IPv6 Address at the bottom
Verizon won't sell you a Jetpack router, but they will rent/lease it to you, adding about $10 to your monthly service bill.

Looking under the covers


Digging into the router a bit more, the router has a GUA (Global Unique Address) on the LAN side, which would appear that the router is doing DHCPv6-PD on the WAN (rather than running a proxy service and extending the /64 from the Service Provider RFC 7278).

$ ./v6disc
-- INT:wlan0 prefixs: 2600:1003:b458:e277 
-- Detecting hosts on wlan0 link 
-- Discovered hosts for prefix: 2600:1003:b458:e277 on wlan0 
2600:1003:b458:e277:216:8ff:fe00:3        <--- Jetpack           
2600:1003:b458:e277:f203:8cff:fe3f:f041                       
-- Pau 

Probing the Jetpack a bit more, we see that it is listening on telnet & DNS on IPv6, and the web interface is only available on IPv4
$ nmap -6 -sT 2600:1003:b458:e277:216:8ff:fe00:3
Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-25 17:44 EDT
Nmap scan report for 2600:1003:b458:e277:216:8ff:fe00:3
Host is up (0.021s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
23/tcp open  telnet*
53/tcp open  domain

$ nmap -sT 192.168.1.1
Starting Nmap 6.40 ( http://nmap.org ) at 2017-03-25 17:46 EDT
Nmap scan report for my.jetpack (192.168.1.1)
Host is up (0.012s latency).
Not shown: 997 closed ports
PORT   STATE SERVICE
23/tcp open  telnet
53/tcp open  domain
80/tcp open  http

The Jetpack router is made for Verizon by Franklin Wireless Corporation (based on the MAC address) which has their own product line of mobile hotspots, and runs for hours on the internal battery.

IPv6 Everywhere, even in Hotspots


We have grown used to firing up a hotspot on our phones to give access to laptops, etc when there is no Wifi available. IPv6 is the future internet protocol with less latency (no NAT) and t is great to see that Service Providers like Verizon are also supporting IPv6 connectivity on their portable hotspots.


* Although the telnet port is open, one can not telnet to it, as it immediately disconnects

Monday, May 8, 2017

Windows 10 now runs in SLAAC Networks

by Craig Miller


Microsoft released the Creator Update last month (11 April 2017) with lots of interesting stuff. But the most interesting for IPv6 is support for the RDNSS field in the RA (Router Advertisement). The RDNSS field is the one that carries DNS server information in the RA.

In order to run an IPv6-only SLAAC-based network the host must need 2 things: an address, and the address of a DNS server. Without DNS, IPv4 or IPv6 is pretty useless these days.

Windows 10 and SLAAC Requirements


In order to see the new feature in action, the Windows 10 machine must:
  • Be in a IPv6-only network (no IPv4) 
  • Hear a RA (Router Advertisement) without the M-bit set (or DHCPv6 disabled). 
Of course, it would be good if your router was sending RDNSS in the RA. 

Windows 10 SLAAC-only Details


In this environment, the output of ipconfig is still a little misleading:
C:\Users\Craig>ipconfig /all

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : lan
   Description . . . . . . . . . . . : Realtek PCIe GBE 
   ...
   DHCPv6 IAID . . . . . . . . . . . : 75761763
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-A3-2E-82-80-FA-5B-96-37-56
   DNS Servers . . . . . . . . . . . : fdf7:56a9:b7af:1101::1
   Connection-specific DNS Suffix Search List :
                                       lan

The DNS Server field is now showing my RDNSS address (the ULA address of my router) and DNSSL (DNS Search List)!

Another way to confirm the DNS servers that Windows 10 knows about is with a netsh command:
C:\Users\Craig>netsh int ipv6 show dnsservers

Configuration for interface "Ethernet"
    DNS servers configured through DHCP:  fdf7:56a9:b7af:1101::1
    Register with which suffix:           Primary only

Running a quick check to see if it can actually resolve an address using only RDNSS:
C:\Users\Craig>nslookup www.google.com
Server:  OpenWrt.lan
Address:  fdf7:56a9:b7af:1101::1

Non-authoritative answer:
Name:    www.google.com
Addresses:  2604:470:4001:806::2004
          172.217.29.164


Now it is possible to run simplified (SLAAC) networks


The fact that MS is now supporting SLAAC-only networks is a huge shift from their previous DHCPv6 only stance. Why is this important? Because there are use-cases for SLAAC-only networks, and now not only can you use your Android devices (which don’t do DHCPv6) but also your Windows 10 machines as well.

Windows continues to dominate the PC market with about 85%. Now with Windows 10 Creator Update, there is no excuse to not deploy IPv6 in your network now.



* adapted from my ipv6hawaii.org article
** Win10 details from André Lange, author of ip6neigh

Thursday, May 4, 2017

North American IPv6 Summit

by Craig Miller


The North American IPv6 Summit was held in Sunnyvale last week. It is always a pleasure to be in a large room with people who get it. There is no convincing that we need to give up our comfortable Linus-blanket of IPv4 for something new and different. No, everyone in the room is a convert, and many are outspoken advocates.

The conference was organized by the regional IPv6 Task Forces: California IPv6 Task Force, Rocky Mountain IPv6 Task Force, Texas IPv6 Task Force, and Mexico IPv6 Task Force.

Speakers, shakers and movers

Some of the speakers were:

  • Tony Scott, the former CIO of the Unitied States of America
  • John Curran, the President and CEO of ARIN (American Registry for Internet Numbers)
  • Kevin Jones, Chair for IPv6 transition at NASA
  • John Brzozowski, Chief Architect, IPv6 and Fellow,  at Comcast

Major Points

So if everyone is a convert, there's nothing to talk about, right? Actually there are quite a few things. Some of the key points made at this year's conference were:
  • Dual-stack is only half way. We need to start moving to IPv6-only networks. There were presentations on how Cisco, Microsoft, and Comcast are doing just that.
  • IPv6 impacts on Cloud Computing, and IoT. A case study of BC Hydro operating 2 million smart meters (IoT) all on IPv6.
  • Content is being delivered over IPv6, thanks to CDN (Content Delivery Networks), like Akamai and Cloudfare, fronting IPv4-only legacy sites.
  • Microsoft adds SLAAC capability to Windows 10, Creator Update (11 April 2017). Now it is possible to have Windows and Android on the same SLAAC (Stateless Address Auto Config) IPv6-only network!


Missed it? Here's the presentations

Thanks to all the volunteers of the regional task forces, and Linked-in for hosting the conference. The presentations are posted online, in case you didn't make it down to Sunnyvale last week. Hope to see you there next time.


Friday, April 14, 2017

Using ULAs for VPNs

by Craig Miller


Credit: http://www.thewaroftheworlds.com/archive/games-e.aspx
War of the Worlds
It has taken me some time to warm up to the idea of using ULAs (Unque Local Addresses), as it initially seemed like we were heading down the same private address problems that we have in IPv4. And I can't see ULA and not think of the sound the Martians made in H.G. Well's War of the Worlds.

But I have found a few really good reasons to use ULAs:

  • DNS stability: ISP is constantly changing GUA (Global Unique Address) PA (Provider-aggregatable) prefixes, and you have servers on your network that you would like to use DNS (Domain Name Service) to make life easier
  • Security: You have servers on your network which don't need internet access, but you want to access them via IPv6
  • VPN: Creating a VPN (Virtual Private Network) across several sites, all sharing the same ULA prefix (the 48 bit prefix).

ULAs made easy

It is this last use case, I'd like to discuss a bit more in this blog. According to RFC 4193, one should generate a 40 bit random hex number which is appended to FD, e.g. fd84:ac67:c214::/48. Fortunately, there are convenient tools on the internet to help with this, such as the Unique Local IPv6 Generator. 

However, if one is to create a VPN of several sites, the routing is much easier if a common ULA /48 prefix is used. With some address planning it is quite easy to give each site a /56 or 255 prefixes per site. In the following example, a hub and spoke topology is used, but with a small number of nodes, a mesh topology could be employed.
VPN using fd01:db8:9::/48 ULA prefix
ULAs also effectively eliminate the IPv4 Duplicate address problem. A common problem when using IPv4 is accessing a corporate RFC 1918 network, such as 192.168.0.0/16 from a hotel which is also using the 192.168.0.0 network. Routing is confused, and packets don't make it to the corporate network. Because ULAs have randomized 40 bits of the prefix, as per RFC 4193, the likelihood of duplicate subnets is a extremely low.

Because IPv6 uses multiple addresses, each site will have different GUA prefixes, and in fact, could be different ISPs. The PA (Provider Agregatable) GUA Prefixes can even change without changing the VPN setup. This is equivalent to the old IPv4 split-tunnel, where internet access doesn't have to be back-hauled to a central site, which results in faster internet access.



OpenWrt and IPv6 VPNs

OpenWrt supports OpenVPN, where the VPN links can be setup to use underlying IPv4 or IPv6 for transport. In addition, OpenWrt also supports ip6neigh, a DNS solution for IPv6 on home routers, with each site having a unique user-defined top domain name (typically .lan, but it is configurable).


Don't fear the ULAs

So don't fear the UUULLLAAs, ULAs are good for creating stability in a address-changing IPv6 world.


* Photo Credit: http://www.thewaroftheworlds.com/archive/games-e.aspx

Sunday, March 19, 2017

Breath deeply, a /64 is a good thing

by Craig Miller

Earth's atmosphere is vast
IPv6 is a different networking protocol from IPv4. To illustrate, just look at how a host can get a globally unique IP address (GUA) without requiring any servers, without sending a packet*.  This is made possible by the fact that IPv6 does not have variable subnet-masking. All end user LANs are a /64.

There are some who say that it is a waste of address space to use an entire /64 (4 billion * 4 billion) on a single subnet. I would suggest that those who do are still in a IPv4-frame-of-mind. The IPv6 address space is vast (see Simplifying Subnetting).

Take a breath

Think of it this way, how many breaths have your taken since getting up this morning? I have no idea how many I have taken. But if you are scuba diving, and are breathing off of a tank of compressed air, you pay close attention to how much air you have (usually measured in minutes, but when diving, that can change depending on how deep you are, and what kind of effort you are expending). We don't think about how many breaths we take driving into work, because Earth's atmosphere is vast.

A prefix longer than /64?

There is the additional problem, that if the LAN subnet is defined as something other than /64, many things will break, much more than just SLAAC (Stateless Address Auto Config). The authors of RFC 7421 have exhaustively gone through the RFCs to examine what assumes the end user LAN is a /64.

Some failure modes highlighted by RFC 7241:
  • Routers may drop packets on interfaces /65 to /126 (inclusive)
  • Specific Multicast Addresses will fail (resulting in NDP failures)
  • The Cryptographically Generated Address format [RFC3972] relies on /64
  • Many Transition mechanisms, such as NAT64, XLAT464 
  • Duplicate Address risk, should SLAAC be modified to work with more than /64
  • Link-Local, defines the Interface ID (IID) as 64 bits wide
  • IP Address Management (IPAM) systems assume /64
  • Firewall look up issues (where there are not enough content addressable memory bits to include longer prefixes + L4 port numbers)
Although not specifically a failure mode, a smaller subnet space takes less time for attackers to scan.

Think Different, Think Vast

Think about how many breaths you take in a day, a month, a year. Compared to how much air is in the world, what you breath is insignificant. So take a deep breath, and remember IPv6 address space is vast.


* Duplicate Address Detection (DAD) is performed, but only after a GUA has been selected.
** Photo licences under Creative Commons

Sunday, January 15, 2017

Swiss Cheese, or Is that your Firewall?

by Craig Miller


Yummy yes, but not a good firewall
While debugging connectivity issues a user was having with my v6brouter project, I discovered that I was not the only one to see a brouter as a solution to extending the ISPs IPv6 network (when they don't provide prefix delegation). And the humbling thing is, that IPSOL did it more elegantly than my clunky code.

So if extending an IPv6 prefix can be done so elegantly, why not rewrite my v6brouter to utilize that better idea. And while I was there, I thought I would provide value add of a bridging firewall (see v6Brouter Part 2: v6Bridge Firewall). The first bridging firewall was more of a proof of concept, but not that useful if you are directly connected to the internet, since it only blocked external SSH access.

Creating a static bridging firewall

My first attempt at rewriting the firewall, was to block all external access, and only allow external in-bound SSH connections. This seemed like a better default firewall configuration.

And it worked great! It blocked all all in-bound connections except SSH. It also blocked responses to web requests, and any external response to a host on my LAN. Very secure, but not all that useful.

A more useful, stateful firewall

This led me to think more about how firewalls work, and the delicate balance of security vs convenience. I had created a very secure firewall, but certainly wasn't convenient. Modern firewalls are stateful machines which keep track of outbound requests, and open holes to permit external responses to those requests, thus making the firewall useful to the users inside on the LAN.

Fortunately, OpenWrt is linux-based, and I could utilize ip6tables features to create a stateful bridging firewall. It would block unsolicited external access, while allowing internal LAN hosts to receive external responses to their requests. All of this without altering the packets, just bridging, and extending the IPv6 prefix into user's LAN.

We tend to think of firewalls as a monolithic non-combustible barrier providing protection from the firestorm that is the Internet these days. But even a car firewall has holes: holes for brake lines, accelerator linkages, steering wheel linkage, wiring, coolant pipes (for the heater), etc.

Check for Holes

A network firewall can begin to look like Swiss cheese, after all the special user requested holes, connection-based holes (for external responses), and UPnP (Universal Plug n Play) holes that are requested by software on LAN hosts. If you don't know how many holes are in your firewall, it might be time to take a look. Don't forget to check your IPv6 firewall as well. Swiss cheese is good on a sandwich, but not as a firewall.


* Swiss cheese photo - Creative Commons

Wednesday, December 7, 2016

Excuse me, your MAC is showing

by Craig Miller 


MACs exposed*
Stateless Address AutoConfiguration (SLAAC) is an easy way to get an IPv6 network up and running quickly. But  RFC 4291 states that the  the interface MAC address should be used when generating a Global Unique Address (GUA).

For the most part, this works quite well. Most MAC addresses are unique (although they only need to be unique within the same broadcast domain). But it has problems when it comes to hardware repair. What happens when you need to replace a NIC card, the GUA changes. Not good.

I have argued in the past that this was a small issue, since servers are probably going to have static IPv6 addresses, which get mapped in DNS to names. Therefore changing a NIC card won't change your GUA.

Exposing information

Other's have expressed concerns that using the MAC address in the GUA exposes that information to the outside world. But on the far side of a router, the MAC address is no longer significant, and therefore pretty useless for network attacks.

But sharing the MAC address globally does reveal the hardware vendor of your NIC, since the first 3 bytes of a MAC address is registered to a manufacturer. This may lead some try to infer an installed OS, and limit their attacks based on this assumption. But the privacy extensions (RFC 4941) have all but eliminated this problem, since temporary GUAs are used for outbound connections.

When infinite is only 16 million

But in-bound connections are still received on the SLAAC MAC-based GUAs.  Reading RFC 7707 (Network Reconnaissance in IPv6 Networks) has convinced me that it is time to move beyond the old MAC-based GUA. RFC 7707 discusses how an attacker can limit the number of addresses being probed from the 2^64 address space by selecting a common NIC vendor (such as Apple, 10:9a:dd:xx:yy:zz) thus reducing the address pool to 2^24. Or in more humanly understandable numbers reducing the potential address from 1 in 18,446,744,073,709,551,616 to 1 in 16,777,216 (or 16 million). Suddenly, the seemingly infinite address space of 2^64 is quite manageable to probe.

A Standard to the rescue

Fortunately, there's a new standard to disconnect the MAC address from the GUA. RFC 7217 (Semantically Opaque Address Generation). Rather than use the MAC address, the RFC recommends using a cryptographic method to generate the lower 64 bits of an address. This opens the entire 2^64 address space again for a GUA on a device. Making it very difficult to guess by an attacker.

The latest version of Mac OSX (10.12) and Windows (10) support this method of GUA generation. Unfortunately, Linux a former leader in the realm of IPv6 support, is behind. A feature enhancement (#4625) has been submitted to systemd for RFC 7217 support.

SLAAC, letting you slack off

Where does this leave us? IPv6 is improving, clever people are fixing the problems of the earlier implementations. With RDNSS (see IPv6 RA, RA, RA) and Semantically Opaque addresses, a SLAAC environment can be viable option to run IPv6 networks with the minimum of management hassle**.


* Macadamia Nuts in and out of the shell
** OK, if you have Windows machines on the network, it may not be enough (see Dual Stack, the good, bad, and ugly)



Monday, November 21, 2016

IPv6 & Systemd, another look

by Craig Miller

Lennart Poettering on systemd*

Systemd is coming to a computer near you. All the major linux distributions have adopted it. Systemd is a replacement for init, PID 1, and if the developers had stopped their, there would be no real impact. But the developers have expanded the influence of systemd to include many other aspects of how your linux workstation operates.
  • networkd - Controls the aspects of networking, including DHCPv6 Client, RA processing, SLAAC address assignment, IPv6 route insertion, etc
  • resolved - Acts like DNSMasq (but more limited) in resolving Domain Names. It gets pointed to DNS servers via networkd.
  • Other aspects of the linux host, including logind, hostnamed, locald, timedated, machined, importd to name a few.
The systemd daemons will also process IPv4 information, but that is beyond the scope of this blog.

Another Look at systemd

It has been six months since I took a good look at systemd and IPv6. You may remember that there were some clear issues which may cause one to pause before deploying a systemd host in an IPv6 production network.

A recap of IPv6 issues with systemd

The devs at systemd (and Redhat) have decided to re-implement functionality already in the kernel code. Therefore there are a few things which worked just fine in a non-systemd system, but do not in a modern system. Retesting with systemd version 231, we see there are improvements (below).
Description Issue Status
IPv6 RA flood (THC flood_router6) causes network disconnection even after flood ceases#2977FIXED
Temporary addresses (RFC 4941) are broken from version 224 to 228#2242FIXED
nterface disable/enable IPv4 will reaquire and address, but IPv6 will not (other than link-local), and will remain address-less until restarting networkd#2912Still broken
Fails to send Router Solicitation#2365Still broken
Unable to view DUID (DHCPv6 Identifier) on host#2952Closed but Still broken
Bridged Interfaces get IPv6 SLAAC addresses#2572FIXED
Systemd in a VM failed to start due to RA parsing error#2228FIXED
IPv6 incorrectly not enabled on Virtuozzo containers#2059FIXED
IPv6cceptRouterAdvertisements=yes or unset accepts too many prefixes#2004FIXED
Does not support DHCPV6-PD#1080Still broken
Does not support SLAAC RDNSS#1079FIXED

A few more issues have been added in the past 6 months


DescriptionIssueStatus
networkd does not support DNS List option in RA#4590            Open
Semantically Opaque Interface Identifiers with IPv6 SLAAC RFC 7217#4625Open
networkd: handle MTU field in IPv6 RA#4464Open
RFC 7084 support in networkd (automatic ipv6 prefix delegation)#4073Open

Time will improve systemd

It is unfortunate that the systemd team has decided to re-implement existing functionality (e.g. in the kernel, dnsmasq, odhcpd). But like fine wine, it is improving. Be sure to check the details of the issues which may impact your testing/deployment and save yourself a bunch of time. As always, taking the time to plan your IPv6 deployment will save you time in the end.

*Lennart Poettering T Shirt