(That draft would basically be a BCP, cc'd to v6ops where this belongs) kent@songbird.com wrote:
I think I could have been clearer with my message.[..]Instead, I was presenting what I thought was an interesting example of a subtle problem that can come up in ipv6 deployment.
I think it is a good idea to document common examples of how one could setup a datacenter, or at least a small network. One thing to note is that people should stop thinking in IPv4 terms. Yes, IPv6 is in effect only more bits, but those bits belong to you and you can use them to do all kinds of new interesting setups as you are not limited any more to what you are doing with respect to address usage.
Generally the ideas for a network I follow are: - autoconfig (or if wanted DHCPv6) for hosts (client+server) Turn off RFC3041 on all hosts (it is just annoying IMHO :) - for servers use the autoconfigged address for 'management' purposes - for services, use a /64 per service, or just use one with all services. Call these 'service prefixes'. Thus DNS could be <pfx>::53/64. Then you can use quagga or similar to do OSPF/BGP/whatsuitesyou on the server and announce that it is able to serve DNS, just announce the <pfx>::53/64 (or /128 or whatever) everything in the network can use <pfx>::53 for DNS resolutions. Of course the side-effect is that you can just setup another host and do the same trick, then have some scripting on those hosts to check if the service is actually working and retract announces when needed. Voila a very nice distributed-by-anycast-local-service setup. Repeat this trick for any service you want. Remember, if your service becomes busy, just add another box, or just move it to another etc. Also, if the MAC of the box dies, it is unrelated to the actual service and outages will be kept to a minimum. This of course works for http-proxies/smtp-servers/imap-servers etc. Note that for the service prefix, as it is generally only for serving local clients, one could quite well use a ULA prefix, which will thus will never change even if changing upstreams or disconnecting etc. YMMV on that one though. Note that you just need a route to that ULA prefix and can avoid clients having to have a secondary address in that range. Benefit for ULA prefix is of course that automatically it will be hard for external sites (The Big Bad Internet) to reach these services as they don't easily get a working TCP bidirectional path to it. - Forward/Reverse DNS, I simply register the EUI-64's in DNS, hardcoded. One can of course with DHCPv6/(Secure-)DDNS also do it dynamically if wanted. If you are a Windows-shop Active Directory can also help you out in this area. It depends a bit on what you require, how many hosts you have and also how much control you have over these hosts. - DNS resolving is configured either static (we have the service prefix which will most likely never change anyway if lucky) or you could simply do it using DHCPv4||v6. - Don't forget to properly configure your firewalls ;)Another note for a lot of people who use a VPN when working from home but where the VPN is only IPv4-capable. When you are at home you will have a (public) IPv4 address, an IPv6 address and a VPN-IPv4 address, but no VPN-IPv6 address, thus most likely the Internet-IPv6 address will thus hit the firewall and die off there. Thus if you have firewalled@work, AAAA's in the DNS you won't be able to reach them and hilarity ensues as this will cause lots of connections delays due to most firewalls dropping connections, not rejecting them. Thanks to our marvelous IS team here though I found out that ISATAP is a perfect solution to this problem as it automatically sets up tunnels locally when needed, as the VPN IPv4 is 'local' the tunnel works and you can reach resources which would be firewalled when using the global address. Which reminds me to quickly write&submit another draft I had in my head on that subject.
The mailserver in question uses a default redhat enterprise build (actually centos). ipv6 is either enabled by default, or just has a single check box, with no further information. The fact that ipv6 is enabled so trivially carries the implication that just enabling ipv6 won't actually damageanything.
Unfortunately if people just click they will open a lot of things that are not needed and can cause issues, for them bot more importantly for others. As that means that the box is not properly configured, clearly as the 'admin' didn't care, why would anyone then even care to receive mail/traffic from them?
Now I know different. Just enabling ipv6 on an otherwise correctly configured and functioning ipv4 box *will* cause damage -- it will cause mail that would have been delivered to not be delivered. I could be wrong, butthis strikes me as a trap that lots of people could fall into.
People who make those mistakes are the same people who don't read the manual/readme/mustread etc, unfortunately that also means that they will never ever read a BCP even if someone wrote one up.
As I mentioned, my servers actually do reject mail if they can't find a reverse dns for the senders IP. Some of those servers use ipv6; in light of all this I'm going to have to rethink that decision. For a server, the combination of enabling ipv6 and using this particular anti-spam technique may drastically increase the number of false positives -- especially as ipv6 gets more widely deployed.
As I mentioned, servers/hosts which are not properly set up, are indeed just that, not properly set up, as such they don't even deserve my time.
Note also that if you open this loophole that for spammers it becomes really easy to start spamming you from any host on the planet, and using at least a /48 per IPv4 address and a large chunk of the Teredo /32 to choose their source addresses from. Note also that it is quite difficult to contact those people in general, because that is what they want, not to be contacted.
Thus my summary on this: if they don't care, why should you care? :) Greets, Jeroen
Attachment:
signature.asc
Description: OpenPGP digital signature