Draft on how to correctly configure servers and other hosts (IPv4+IPv6) (Was: problem dealing w/ ietf.org mail servers)
Jeroen Massar <jeroen@unfix.org> Fri, 04 July 2008 10:35 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE19E3A6B3E; Fri, 4 Jul 2008 03:35:10 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FE13A6B82 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 03:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_56=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV+YCePS8b92 for <ietf@core3.amsl.com>; Fri, 4 Jul 2008 03:35:08 -0700 (PDT)
Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id D99963A6929 for <ietf@ietf.org>; Fri, 4 Jul 2008 03:35:06 -0700 (PDT)
Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 7F91835A525; Fri, 4 Jul 2008 12:35:12 +0200 (CEST)
Message-ID: <486DFCDF.8000702@spaghetti.zurich.ibm.com>
Date: Fri, 04 Jul 2008 12:35:11 +0200
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: IETF <ietf@ietf.org>
Subject: Draft on how to correctly configure servers and other hosts (IPv4+IPv6) (Was: problem dealing w/ ietf.org mail servers)
References: <013301c8dca5$22ca0a80$685e1f80$@us> <20080703054752.GM6185@lark.songbird.com> <20080703134655.GA17472@boreas.isi.edu> <486CDD05.10802@bbiw.net> <20080704062213.GA32192@lark.songbird.com>
In-Reply-To: <20080704062213.GA32192@lark.songbird.com>
X-Enigmail-Version: 0.95.6
OpenPGP: id=333E7C23
X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on abaddon.unfix.org
X-Virus-Status: Clean
Cc: IETF Ops <v6ops@ops.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1699148452=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
(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 damage > anything. 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, but > this 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
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- problem dealing w/ ietf.org mail servers 'kent'
- Re: problem dealing w/ ietf.org mail servers Mark Andrews
- Re: problem dealing w/ ietf.org mail servers Keith Moore
- Re: problem dealing w/ ietf.org mail servers Bill Manning
- Re: problem dealing w/ ietf.org mail servers Jeroen Massar
- Re: problem dealing w/ ietf.org mail servers John Levine
- Re: problem dealing w/ ietf.org mail servers Dave Crocker
- Re: problem dealing w/ ietf.org mail servers Keith Moore
- Re: problem dealing w/ ietf.org mail servers Keith Moore
- Re: problem dealing w/ ietf.org mail servers John Levine
- RE: problem dealing w/ ietf.org mail servers michael.dillon
- Re: problem dealing w/ ietf.org mail servers Keith Moore
- Re: problem dealing w/ ietf.org mail servers Mark Andrews
- Re: problem dealing w/ ietf.org mail servers Bill Manning
- Re: problem dealing w/ ietf.org mail servers TS Glassey
- Re: problem dealing w/ ietf.org mail servers Mark Andrews
- Re: problem dealing w/ ietf.org mail servers kent
- Draft on how to correctly configure servers and o… Jeroen Massar
- Re: problem dealing w/ ietf.org mail servers Kurt Erik Lindqvist
- Re: problem dealing w/ ietf.org mail servers Kurt Erik Lindqvist
- Re: problem dealing w/ ietf.org mail servers John C Klensin
- Re: problem dealing w/ ietf.org mail servers Jeroen Massar
- Re: problem dealing w/ ietf.org mail servers Keith Moore
- Re: problem dealing w/ ietf.org mail servers kent
- Re: problem dealing w/ ietf.org mail servers Ned Freed
- Re: problem dealing w/ ietf.org mail servers Dave Crocker
- Re: problem dealing w/ ietf.org mail servers Iljitsch van Beijnum
- Re: problem dealing w/ ietf.org mail servers Francis Dupont
- Re: problem dealing w/ ietf.org mail servers Keith Moore
- Re: problem dealing w/ ietf.org mail servers SM
- Re: problem dealing w/ ietf.org mail servers Kurt Erik Lindqvist
- Re: problem dealing w/ ietf.org mail servers Keith Moore
- Re: problem dealing w/ ietf.org mail servers Kurt Erik Lindqvist
- Re: problem dealing w/ ietf.org mail servers Jeroen Massar