Oct 262012
 
Spend 30 minutes with IPv6 every Friday!

This week we’ve received the very first snow for this season here in the Stockholm area in Sweden. It’s time to go inside and hide until the first flowers show in the spring. During the long cold winter we can work on our networks, improving them and experimenting with new technologies like WebRTC. IPv6 is no longer a new technology, nor is it an addon to TCP/IP – it’s now an integrated part. A friend of mine at a large Internet provider has been able to get this into the corporate portfolio in a way so that all IP-based products now include IPv6 by default. If it’s IP or Internet – then it’s dual stack. So providers are moving, getting ready to deliver IPv6 and many already do. Are you ready? Let’s talk about IPv6 migration for the enterprise network!

Inside out or outside in

To simplify, there are two ways to migrate a company to IPv6. You can start with the outside servers, then move towards the core (I guess it’s the coffee machine) or start deep inside and move out. My personal view is that it is most important to get the Internet-facing services up on IPv6 and build experience. Meanwhile, as you buy new equipment and upgrade software on the internal network, you add IPv6 and let the network grow in an natural way. When you have confidence and all the systems in place, you’re ready to launch.

IETF guidelines for Enterprise IPv6 Migration

We’ve discussed these ideas earlier in the IPv6 Friday blog. The IETF has also spent a lot of time on producing a set of guidelines for the IPv6 migration, for groups ranging from network and application service providers to enterprise-wide networks. The Enterprise guidelines are still being worked on, but a draft in version 2 is published, dated September 15, 2012. The abstract defines the scope of the document:

“Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and potentially an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.”

It’s a rather comprehensive document, only 27 pages long, but contain a lot of valuable information and questions you need to ask in your IPv6 migration planning.

Migrate to the faster Internet – IPv6

The IETF is very clear about one of the reasons to migrate: Need for Speed. As carriers run out of IPv4 addresses, the only option is to provide translated or tunneled IPv4 and native IPv6 connectivity.

“The non-native IPv4 service may be NAT64, NAT444, Dual-stack Lite, or other transition technology, but whether tunneled or translated, the native traffic will be perform better and more reliably than non-native. It is thus in the enterprise’s interests to deploy native IPv6 itself.”

Demystifying some IPv6 security myths

There are still people who claim that IPv6 is more secure than IPv4. The authors are extremely clear on this topic:

“Some people believe that IPv6 is inherently more secure than IPv4 because it is new. Nothing can be more wrong.”

Instead, since it is a new protocol where everyone is building up the global knowledgebase every day, the lack of operational expertise is the biggest threat when deploying IPv6. Everyone needs to take training seriously.

This document is a very important document for everyone. I will leave you reading all the 27 pages in order to learn more and get some new input to your work with IPv6. See you next week!

 

/O

 

 Posted by at 16:08
Oct 202012
 
Spend 30 minutes with IPv6 every Friday!

During the last year, I’ve been spending a large amount of my free time on moving my own servers and services to IPv6. I started with DNS, then the web sites and after that came E-mail. I added IPv6 to my Postfix servers, added new AAAA records in my DNS zone for the  email server that was already used in MX. And then I started looking at the logs. The first few mails over IPv6 where from IETF mailing lists. After that a mail server hosted by Patrik Fältström, TCP/IP and Internet guru. No surprises there. What surprised me was what came next – spam. My graylist software did not support IPv6, but I though I’ll take the risk and assumed that we where ahead of the spammers. Obviously not. Let’s talk IPv6, E-mail and spam!

IPv4 spamlist: Real time Black lists in DNS

In IPV4, almost all mail servers subscribe to a pay-for or free service that lists hosts that are known to be a source of spam in a DNS database. By doing a DNS lookup for every connection on the mail server, we check whether it’s a known spammer or not. Using DNS provides caching, distribution and much more. It’s a system that provides the first level filters for spam. It builds upon a lot of trust in the management of the DNS data. A badly managed blacklist can cause a lot of harm.

When moving to IPv6, the natural thing to do is to ask for the IPv6 versions of the blacklists in DNS. It seems like a very logical thing, moving the system from IPv4 to IPv6 – it’s just a longer address, but still an address. Yes, and No.

With IPv6 spammers, like everyone else, get a vast amount of addresses

When the spammers get IPv6 access, they do no longer get one address or just a few that are easy to block. They get millions. With a tiny bit of intelligence, they’ll find out that they can use one address per mail. If you block one address, they will already be using something completely different. To block that, we need very large DNS zones and very fast systems. Well, why not block subnets then? The risk of blocking something that is not used for spamming will be huge, and may cause more harm than it already does in the IPv4 mail world.

A presentation by an unknown person for IETF 83 discusses the problem in detail. It’s a very good presentation, so take a moment to go through it. An IETF draft document about e-mail migration to IPv6 points out that this is a chicken-and-egg problem. We don’t know anything before we actually deploy IPv6-email servers:

“The lack of a full understanding of all abuse threats SHOULD NOT preclude the adoption of IPv6 for mail. A comprehensive understanding of threats will not be available until implementation.”

The Register published an article in 2011 titled “IPv6 intro creates spam-filtering nightmare” by John Leyden that discussed the problem. Michael Kassner reacts on this article and asks around for more opinions in his article “IPv6 blacklisting: Will it be harder to fight spammers?” where some people recommend blocking whole subnets, others claim that blacklisting in DNS doesn’t work well in IPv4 either and it’s time to move on to new methods. Scott Hogg writes about the problem in NetworkWorld under the title “Should you allow inbound e-mail over IPv6?

In search of other ways to fight spam in IPv6

The realization that we can not fight spam in IPv6 the way we do in IPv4 has lead to two very separate ideas on how to handle it. The first one is obviously to try to solve it by moving to a more trusted system where e-mail servers has to identify themselves. The number of e-mail servers aren’t as big compared with the number of IP addresses. Applying DNSsec-based trust or old-fashioned TLS makes sense. With that we can verify the that an email server for a domain only sends mail it is authorized to send by the DNS zone. Graylisting has helped quite a lot too.

The other groups has come to the conclusion that coming up with a trustworthy solution for e-mail in IPv6 will take quite some time. So their line of thought is to keep e-mail on IPv4. Servers will run dual stack and receive outbound mail from IPv6 clients, but the Internet-wide relay federation will still run on IPv4 where the current DNS-based blacklist system works. This is a short-term solution as it will become expensive for new companies to get access to IPv4 addresses and set up their mail servers. They will run on IPv6 only and complain over your e-mail systems lack of reachability.

Personally, I haven’t formed any opinion on the right way to go. As a technology promotor, I want IPv6 everywhere, now. But I also understand the arguments from larger organizations that it’s not possible to open up the flood gates today. The IPv6 crowd will just have to come up with better solutions and prove them. Considerable amount of effort is put into this, in the IETF and by vendors and Open Source projects. Let’s follow the progress, participate and hope for a solution soon.

/O