From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 40B3C198005 for ; Mon, 11 Mar 2013 04:38:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 170B0E05ED; Mon, 11 Mar 2013 04:38:07 +0000 (UTC) Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5F8ABE058F for ; Mon, 11 Mar 2013 04:38:05 +0000 (UTC) Received: by mail-ia0-f173.google.com with SMTP id h37so3253353iak.4 for ; Sun, 10 Mar 2013 21:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; bh=Z/GtOl/yYhg3OerA1pw/hevC+Ok7fS49ry0fGIxnY1Q=; b=i0CAZKsLSyhRdJIQGU8Fv37r1TVXwdNcj8uWTJS6cl6tfLBzAU7E3IV1XN6993JfHp T3wHtjbF9wE4vvjaON0BGbPDJPNPD6083G7i2VzYzHNunR25Qv0n2x7BTIx+u58vBXwz yBtx6BUrF6Yod82mIYn9F15CGR22zVarRey4RoBsamHVOiw6PrTGVllcqvCCUaWQ6yZ+ 8R18MgUzdKWvPnsCrL9k+vBkIS1ppKkyC3GSM05Ts7m72rj4XtL2DsCUHhWnI+bb/9Ed G4uZu9NjorkVZOPl/XnrScutkoM1rTaciZjl+s8ORDEJcZ2i8ulFGxMvHX7H/s9zCR8b PCJQ== X-Received: by 10.50.197.170 with SMTP id iv10mr5898904igc.62.1362976684328; Sun, 10 Mar 2013 21:38:04 -0700 (PDT) Received: from ?IPv6:2001:5c0:1400:a::1b9? ([2001:5c0:1400:a::1b9]) by mx.google.com with ESMTPS id gy3sm12096204igc.10.2013.03.10.21.38.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Mar 2013 21:38:03 -0700 (PDT) Message-ID: <513D5FA5.2000506@gmail.com> Date: Mon, 11 Mar 2013 00:37:57 -0400 From: Michael Mol User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130222 Thunderbird/17.0.2 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [Bulk] Re: [gentoo-user] /etc/hosts include file? References: <5139EA4D.1000606@gmail.com> <5139ED7C.3030708@gmail.com> <263693.5416.bm@smtp197.mail.ir2.yahoo.com> <513A423D.3080900@gmail.com> <293639.72773.bm@smtp143.mail.ird.yahoo.com> <20130309001343.GB25016@waltdnes.org> <513A8529.7000708@gmail.com> <20130310014256.GA27509@waltdnes.org> <513C17D2.7080008@gmail.com> <513CF60D.7060708@gmail.com> <20130311040016.GA30399@waltdnes.org> In-Reply-To: <20130311040016.GA30399@waltdnes.org> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2XRDOXLCGQVXWIXJEQVTH" X-Archives-Salt: 21026833-fccd-4cc2-86eb-b378c638d871 X-Archives-Hash: 188e8fa993740bedcdbd777280a3b936 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2XRDOXLCGQVXWIXJEQVTH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/11/2013 12:00 AM, Walter Dnes wrote: > On Sun, Mar 10, 2013 at 05:07:25PM -0400, Michael Mol wrote >=20 >> NAT behind a home router is bad, too. For IPv4, it's only necessary >> because there aren't enough IPv4 addresses to let everyone have a uniq= ue >> one. >=20 > The best real reason for moving to IPV6 is address space (or lack > thereof, in the case of IPV4). The people who are truly interested in > speeding up IPV6 adoption should do their best to shut up the internet > hippies who constantly rant and rave about how "NAT is evil". Don't le= t > the cause get distracted by that unrelated issue. Focus on the core > issue. They're two sides of the same coin. If NAT wasn't such a problem, layering RFC1918 address space would solve most of the address space problems. The address space crunch remains a technical problem largely because NAT can't solve it to completion. NAT forces a distinction between 'client' and 'server', breaking the 'peer' nature of the network. This isn't some hippy egalitarian thing, it means I can't trivially tell my VPS to connect to a backup target on a different network without setting up either a tunnel or a port forward. With IPv6, doing this is so brain-dead easy I never want to be without it again. Once you've experienced IPv6 and appropriate network firewalls, along with the ease of connecting to your own machines from anywhere you want without having to bounce through a third-party management service like Teamviewer, you never want to go back. It's like discovering you've been holding a pencil wrong all your life, or like discovering a better way to tie your shoes; the solution is simple, elegant and surprisingly productive. NAT is like tying your shoes wrong; you don't know how much of a problem it is until you experience life without it. And even once you get people comfortable with deploying IPv6, they still want to hold on to NAT; it's like a stubborn stain on their minds. It's important to explain that NAT isn't a security measure. In order to operate, it requires what amounts to a stateful firewall...but that doesn't mean that a stateful firewall is difficult to obtain without NAT. People have grown so accustomed to the presence of NAT and NAT's inherent implications on inbound traffic that they wind up conflating the two in their minds, making actual understanding of their network's security that much more difficult to comprehend. So, yeah, NAT is evil. Looking for privacy in your addresses? That's what privacy extensions are for, and they're enabled by default on Windows and Ubuntu. (I haven't looked on Gentoo...) The only reasonably valid use case for NAT that I've seen is for dealing with the question of multi-homing an office with two internet connections. The idea is that you don't have to renumber your internal network if you need to switch from your primary connection to your backup connection (and you're being granted different IP ranges based on which connection you're working with...so we're talking small business, not BGP or multilink with the same ISP). In those cases, I advocate application-layer gateways; chances are, if you're investing in multi-homing your office, you probably already want the kind of administrative power (and performance improvements) proxy servers can offer you. The IPv4 address crunch triggered the development of DNAT a couple decades ago, and the silly thing persists in terrible ways when there are simpler ways to handle things. (When I say 'simpler', I mean: Don't break assumptions about basic network behavior such as 'don't mangle my packets' or 'I can open a connection back to him when I have updates he needs') ------enig2XRDOXLCGQVXWIXJEQVTH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRPV+oAAoJED5TcEBdxYwQt0cH/R+q+/tG+9UPzb0R4XQ/giNx 1+v28FVWRsdlH9c+jeQ1zlXoPhvzQ9faM/XLlZbRTUB+s2u+dIvo9irJfQZEJuNK bDPZ+zfrMGu+OjebyD3STtd/sD+tA71k7ogRN/0j1v1FvCyzm3WYLPrz00AWA4zg Om87gE1OyEV0vCyYjERtLZAi6jjyU815pAEsVYuysfoa4sD22sNL70AVWy+IaCoW B2keHRpFmat4+gxZGZYX3sGIKIrRzpoyNk/4ilegxrzXzFC1qeuUbBLbeLW7Ek9o XUbUpHKHwP2FnuFIp1ozRM1zKZdqmaRr0dFF4dMVpD5iS48olb9GDH+rAniSm0k= =Em0Z -----END PGP SIGNATURE----- ------enig2XRDOXLCGQVXWIXJEQVTH--