Draft on how to correctly configure servers and other hosts (IPv4+IPv6)

(That draft would basically be a BCP, cc'd to v6ops where this belongs)

kent(_at_)songbird(_dot_)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(_at_)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

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf