The change to IPv6 creates new challenges to keep spam out of email. Because of the sheer size of the IPv6 space, it seems more efficient to build a domain-blocking and reputation system rather than an IP-blocking system. But how do we ensure emails over IPv6 have an authenticated domain?

Email authentication in the IPv4 landscape

There is plenty of documentation and recommendations on how to set up email servers for best deliverability, but the industry-accepted standards and best practices are M3AAWG Sender Best Current Practice (BCP) and various Internet Engineering Task Force (IETF) Requests for Comment (RFC) related to Simple Mail Transfer Protocol (SMTP).

It is commonly accepted that /24 IPv4 address spaces (256 hosts) are assigned to organizations, and among these networks, one or several IPs are used to send emails. An IP address can be static, representing always the same source, or dynamic, where a new address is assigned at regular intervals.

It is recommended that a sending IP should have reverse DNS, and all emails should carry some form of domain authentication. However, not all mail providers check for it and/or enforce it. Due to the historical nature of SMTP, mail servers, also known as Message Transfer Agent (MTA), have been made very lenient and gladly accept nearly any kind of malformed emails. To protect users, several techniques have been developed to reduce spam:

• Blocking lists and reputation lists: Single IPv4 addresses and sometimes /24 networks are listed in blocking and whitelists.
• Sender Policy Framework (SPF) and Domain Keys Identified Message (DKIM): These domain authentication technologies have been adopted and deployed by all large senders, but are still far from being used on all domains.

A study by Google shows that less than 9% of legitimate emails are still unauthenticated. However, this represents the long tail of domains used by small to medium organizations. Also, the bulk of anti-SPAM technology is based on message content, rather than identifiers within SMTP, as any identifier in SMTP can easily be forged.

Authentication challenges with IPv6

IPv6 addresses have a bigger numbering space (128 bits) compared to IPv4 (32 bits), and can support 2^128 Internet addresses. Home connections are assigned a /64 minimum (18 billion hosts) per customer, and one server at a hosting provider also generally gets a /64. This is a lot of IPv6 addresses. Organizations that require an IPv6 assignment will usually get a /48 (65,536 networks of /64) or a /56 (256 networks of /64).

Creating blocking lists or reputation lists based on IPv6 addresses can be challenging. If you look at the latest release (June 2013) of the most popular dns blocking server, rbldnsd, you'll see that it lists /64 networks by default, with the capability of adding exceptions. For instance, you can declare that all machines in a /64 network do not send email, except one mail server. Therefore, it seems necessary to move from IP-based reputation to domain-based reputation. Though it is estimated that only 9% of legitimate emails do not have SPF or DKIM as a form of authentication, this represents a sizeable number of small to medium organizations.

Sending mail over IPv6

Mail server security

Because of the number of IP addresses in the IPv6 space, it is important to limit the number of IPs that can be reached. This is accomplished by Access Control Lists (ACLs). An IPv6 address is 128 bits long. It has two parts: a subnet prefix representing the network to which the interface is connected, and a local identifier, sometimes called token. In the simple case of an Ethernet medium, this identifier is usually derived from the EUI-48 Media Access Control (MAC) address using an algorithm described later in this article. The subnet prefix is a fixed 64-bit length for all current definitions. IPv6 allows auto-configuration; interfaces can set their IPs by using the network portion which is broadcast from the router gateway, and the MAC address of the interface. This autoconf needs to be disabled and a static address used. A more restrictive network, for example, a /120, can be created with ACL to allow only 8 bits for the hostname or about 255 hosts. If someone scans the entire IPv6 space, only 256 entries in the IP to MAC resolution table will be created instead of 2^64 entries, as the rest would be blocked by the ACL. Modern IPv6 switches and routers have mechanisms to avoid this type of poisoning, but why take a chance?

To disable IPv6 autoconf in Linux, set IPV6_AUTOCONF to no, and assign a static address:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
USERCTL=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=xxxx
IPV6_DEFAULTGW=xxxx


Another technique, which makes it easier to remember IPs, is to use a /118 so that the last octet in the IPv4 address of the interface can be used in the IPv6 address. Remember that IPv4 is represented in decimal notation, while IPv6 is in hexadecimal. For example:

IPv4=192.168.0.134/24
IPv6=2000:1::134/118


Selecting the right Mail Exchange (MX) record

A Mail Exchange (MX) record specifies how e-mail should be routed and points to the servers that should receive e-mail for the domain. The RFCs are unclear about the strategy for choosing the best host to send an email to a domain when IPv6 is enabled. There are two general rules, which unfortunately, do not necessarily merge well:

1. SMTP RFC5321 indicates that if a domain has several MX records, the machines that these records point to, should be organized by order of priority.
2. IPv6 RFC6724 indicates that if a machine is dual-stacked (where both IPV4 and IPV6 protocols run on the same network infrastructure), a connection to IPv6 should be attempted first.

In the first rule, the application decides the selection, and in the second, the network stack chooses. This creates uncertainty, and MTA software have been implementing different strategies.

SMTP target host selection in Mixed IPv4/IPv6 environments holds that in mixed environments, both A (IPv4) and AAAA (IPv6) records should be queried for each hostname that an MX points to. It also recommends that the sender-SMTP should try to connect to both addresses. Eventually, the sender-SMTP remembers which IP addresses within the same priority level have better response times.

Mandatory domain authentication

For some time now, the email community has been considering mandatory domain authentication in all emails sent over IPv6. Gmail has these rules for sending over IPv6:

Additional guidelines for IPv6

• The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected.
• The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam.

Therefore, for mandatory domain authentication, you will need to set up:

1. Full Circle reverse DNS (FCrDNS): This authenticates the relationship between the domain name owner and the owner of the network that has been given an IP address. On sending IPs, only reverse DNS (rDNS) is required.
2. SPF: This is relatively easy.

   For example, here is the SPF record (as of 2013) for linkedin.com:

   linkedin.com. 86400 IN TXT "v=spf1 ip4:8.18.31.21 ip4:8.18.31.22 ip4:69.28.149.0/24 ip4:199.101.160.0/25 ip4:199.101.162.0/25 ip4:108.174.3.0/24 ip6:2620:109:c006:104::/64 ip4:216.136.162.65 mx mx:docusign.net ~all"

   

   A simple SPF record needs to be set up for each hostname of every mail server to cater for bounces. When the mail from envelope is empty, the ehlo hostname is used to perform the SPF check.

   hostname 86400 IN TXT "v=spf1 a -all"

   

   This is clearly explained in http://trac.tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-10.1.3 which is just a rewording of RFC4408.

3. DKIM should be applied on all emails, including bounces.

With this setup, sending over IPv6 will not create more problems than sending over IPv4.

A big part of anti-spam and anti-virus is based on email content, but the message has to first pass the authentication hurdle and make it to the other email verification layers of the receiver. At this stage, it does not matter much which IP the message comes from.

Receiving over IPv6

Receiving over IPv6 is where the difficulty lies. As it is not easily possible to port any database that relies on the IP address as an identifier, other techniques need to be used – techniques that rely more on a domain name than an IP address.

Connection and rate limits

Servers have to be protected from potential Denial of Service (DoS) attacks. For this, it is common to limit the number of connections an IPv4 server can make to the mail receiver, usually using the /32 and /24 boundaries. In IPv6, the connection and message rate limits should use the /64 and /48 boundary limits, which mimic the network attribution of IPv4 addresses. An end user, such as a home user, usually receives a /32 IPv4 or a /64 IPv6. Using these boundaries in IPv6 will limit the number of entries required to keep track of connections. This also indicates to a sender to be careful about its neighborhood, notably at hosting providers.

Moving from IP to domain name

It is possible to run a DNS blocking list using IPv6. rbldnsd allows such a list, but it cannot be populated with all possibilities. It is best to use a domain-based blocking list, like Spamhaus Domain Block List (DBL) or SURBL. On IPv6, the first step is to require that the sending IPv6 has a PTR (reverse DNS). Ideally the domain returned should have an AAAA record pointing back to the IP (FCrDNS), but this can be difficult. Just having a PTR indicates that the mail administrator had to configure this reverse DNS, and it is less likely that the IP belongs to an end-user machine. If reverse DNS is enforced, then there is less need for an equivalent of the Spamhaus Policy Block List (PBL). The Spamhaus PBL lists IPs that are allocated to end users who are very unlikely to run mail servers.

It is important to configure domain blocking. The domains found in PTR, ehlo, envelope from, from header, reply-to header, sender header, DKIM d=, should be first checked against popular domain blocking lists, and then verified that they are set to receive emails (MX, A, or AAAA record present). These techniques limit common forms of email abuse, and misrepresentation of well-known domain names.

If the message is successfully authenticated by SPF or DKIM, you can then consider the authenticated domain name for further reputation evaluation.

Network

LinkedIn Backbone is a dual-stacked network. Dual stack means that network devices run IPv4 and IPv6 simultaneously. Each device connected to a dual-stacked network is able to reach IPv4 and IPv6 content simultaneously. Native dual stack does not require any tunneling and allows gradual migration of endpoints from IPv4 to IPv6. LinkedIn has dual-stack transit and peer in the backbone. Each data center is allocated two /48 IPv6 address ranges. For smaller POPs, we have allocated one /48. Currently, we have IPv6 up to the frontend, i.e., external load balancers, external firewalls, and mail servers.

Load balancer and mail server security

As explained earlier, we want to avoid filling the neighbor cache (cf http://tools.ietf.org/html/rfc3756#section-4.3.2), so we want to protect the network by restricting the number of IP addresses that can be used in an incoming packet. While the routing may use a /64, an ACL will restrict authorized packets to /118 or /120. This requires dropping autoconf and using static IPv6 addresses.

If there are several mail servers receiving emails, load balancing is often used to simplify the MX record. There are many load balancing techniques but few are suitable for SMTP. Direct Server Return (DSR) load balancing is common with IPv4. DSR allows the load balancer to advertise to the router that it is the receiver of packets to a specific destination IP. When such a packet is received, the DSR forwards the packet to the correct MAC address of one of the machines in the cluster. The machine then sends the response directly back to the source IP. This path is remembered on the load balancer using (source IP, destination IP, source Port) for further packets. This requires that mail servers have the Virtual IP (VIP) on each machine, and that do not answer ARP requests (mapping between IP and MAC) for IPv4, or Neighbor Discovery requests for that VIP for IPv6.

For IPv4 on Linux, you add a virtual loopback for the VIP because an interface can have only one IPv4 address. With IPv6, an interface can have many IPv6 addresses.

For instance, for VIP 108.174.3.215/2620:109:c006:104::215, you can configure loopback as:

DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
ARP=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=2620:109:c006:104::215/128

DEVICE=lo:0
IPADDR=108.174.3.215
NETMASK=255.255.255.255
NETWORK=108.174.3.215
BROADCAST=108.174.3.215
ONBOOT=yes
NAME=loopback
ARP=no


Note the use of /128 for the IPv6 address to avoid Neighbor discovery.

Enforcing domain authentication and setting up MX

We've seen that It is important to have an authenticated domain name over IPv6 when receiving an email. We could adopt the Gmail approach, which is to deliver to the spam folder when there is no authenticated domain name when the email is sent over IPv6. We could also not accept unauthenticated emails over IPv6. Or we could tell the sending mail server to retry the email over IPv4. This latter approach, while stretching what SMTP was designed for, does not require having junk or quarantine management.

Using a technique similar to email greylisting, during the SMTP transaction, once the message has been verified that it is unauthenticated (no SPF pass and no DKIM pass), the receiving server drops the connection just after a 421 error message. This error code is usually interpreted by the sending server that the receiving server has internal server errors and may not be available immediately. This prompts the sending server to retry the message immediately on the next preferred MX. So if you set 2 MX, one on IPv6 and one on IPv4 with the same priority, the IPv6 enabled sending server will try the MX with an IPv6 host first, before trying the MX with an IPv4 host.

Figure 1: SMTP fall back from IPv6 to IPv4

The receiving server successfully gets the sending server to retry over IPv4, as described in http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/.

Blacklists

An IP address is added to a blacklist when the address is verified as a bad site. Blacklisting is often used in IPv4, but with IPv6, the number of addresses to be blacklisted can be staggering. The general recommendation is to not list less than a /64, whereas the sweet point is usually a /56. Usually a /64 is assigned to a home user or a server at a hosting provider, a /56 is assigned to an organization, and a /48 is assigned to an ISP. At this level, IPv6 blocking lists are more manageable. rbldnsd , software commonly used for handling DNS based blacklists, can handle IPv6 lists since June 2013. However, with enforcement of authenticated email over IPv6, it is much easier to apply a domain-based blacklist. All domains in the envelope from HELO/EHLO, From: Sender:, Reply To:, DKIM d=, should be checked against existing blacklists. Additionally, domains in the envelope from From: Sender:, Reply-To:, should be checked for a MX, A, or AAAA record.

Conclusion

Sending mail over IPv6 is not difficult, provided SPF and DKIM are enabled on all emails. Receiving on IPv6 requires changing the email landscape to rely on domain reputation and not IP reputation. The way to change the landscape is to ensure each email sent over IPv6 can be traced back to domains. SPF and DKIM are common protocols to tie an email to a domain. With more and more mail servers doing opportunistic encryption, the domain found in the encryption certificate could also be used for that purpose. This will not stop spammers, but it will make it more difficult for them to use compromised infrastructure. It will tie them to a domain name, which is usually more directly linked to the sender than an IP address.

Check out our presentation at the 2014 IPv6 World Congress.