Re: [v6ops] network topology hiding
Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Wed, 15 December 2010 21:13 UTC
Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2B228C0DC for <v6ops@core3.amsl.com>; Wed, 15 Dec 2010 13:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 uxBW34jYy16H for <v6ops@core3.amsl.com>; Wed, 15 Dec 2010 13:13:57 -0800 (PST)
Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id 70F6428B23E for <v6ops@ietf.org>; Wed, 15 Dec 2010 13:13:57 -0800 (PST)
Received: from 219-90-153-253.ip.adam.com.au ([219.90.153.253] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1PSyhF-0003OL-Kw; Thu, 16 Dec 2010 07:45:37 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id DBA4A3B31E; Thu, 16 Dec 2010 07:45:36 +1030 (CST)
Date: Thu, 16 Dec 2010 07:45:36 +1030
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: "t.petch" <ietfc@btconnect.com>
Message-ID: <20101216074536.6f10447e@opy.nosense.org>
In-Reply-To: <00ff01cb9c3b$a51c7420$4001a8c0@gateway.2wire.net>
References: <AANLkTik248vSqAb79=oEWmzNwZ4xOP7ZSp01b6A4bXZ4@mail.gmail.com> <00ff01cb9c3b$a51c7420$4001a8c0@gateway.2wire.net>
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] network topology hiding
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Dec 2010 21:13:58 -0000
On Wed, 15 Dec 2010 10:37:04 +0100 "t.petch" <ietfc@btconnect.com> wrote: > ----- Original Message ----- > From: "Toru Kuboshiki" <toru.kuboshiki@wata-lab.meijo-u.ac.jp> > To: <v6ops@ietf.org> > Sent: Wednesday, December 15, 2010 8:46 AM > > > Hello, everybody. > > My name is Toru Kuboshiki, the student of Meijo University in JAPAN. > > This is the first time I post on this mailing list. > > > > I am studying how we can familiarize IPv6. > > I think that one of reasons, why IPv6 does not become popular, is that > > IP addresses in the local network are seen from the outside. In IPv4, > > NAT conceals a whole network and this gives the network manager > > security. > > <more emotion than engineeering> > > Put forward this point of view on some lists, the main IETF one for > example, and, judging by past experience, you will get a firestorm of > protest that NAT adds no security. I think that the truth is closer to > that than you say, that NAT adds a little security, but not much. I have > worked with a number of managers who are convinced that it adds > a lot, and I think that that is a dangerous position to take. > NAT topology hiding is functionally equivalent to camouflage. It provides a minimal defence in depth mechanism, however anything that uses it also a big gun, can run fast, can kick hard, or bite savagely to resort to when the camouflage fails. People who seem to vehemently defend topology hiding seem to be coming from a position that there is no need for any other prevention or response mechanisms, which is quite false. > At the same time, you will see a lot of support for the view that NAT > destroys end-to-end communication, which I personally think untrue > in almost all cases. I don't think you fully understand what "end-to-end" is referring to. The nature of the Internet is supposed to be, and was originally peer-to-peer. A peer-to-peer network architecture means that if a node has an network address, it has an equal ability to directly send or receive packets to any other node that also has an address and is attached to the same network. What the end-nodes, and more specifically, what the applications put in those packets was irrelevant to the newtork. The roles of "client" or "server" are only supposed to be relevant to application architecture and roles. A node attached to a peer-to-peer architecture network should be able to concurrently run client or server components of applications without any network imposed limitations - it was exclusively an end-nodes choice as to what application role it wanted to play, not the network's. Also, because the network doesn't care about what applications it was being used for, the network doesn't need to be upgraded before new applications can be deployed. NAT has broken the peer-to-peer nature of the Internet. The consequences have been that some end-nodes can't directly send traffic to other end-nodes, so they have relay the communications via another intermediary node that is visible to both the end-nodes. This intermediary node then becomes another possible failure point, an possible traffic interception point and a potential performance bottleneck point. Applications that are forced to use an intermediary become less reliable, less naturally secure and less scalable. Yet there is no other choice if the end-nodes cannot directly send packets towards each other. That is the limitation that NAT has imposed on end-nodes. NAT exists because there aren't enough IPv4 addresses to give all end-nodes unique addresses, and therefore not all remote-end nodes that local end-nodes might want to send packets to are uniquely identifiable and therefore reachable. Giving every end-node a network unique Internet address (i.e. an IPv6 one), will give them back their ability to exclusively choose what role they want to play in the application architecture. > The protocols used by the vast mass of Internet > users overcame NAT years ago, and there are just a few protocols, > unknown to almost everybody in the world at large, which have not, > but for most people, that is irrelevant. NAT boxes "overcame" those limitations be incurring the hidden costs of forcing public intermediary servers to exist, and application developers to have develop client-server applications where a peer-to-peer application architecture would have been far more reliable, secure and scalable. The costs of dealing with a network layer problem, namely lack of IPv4 addresses, has been shifted onto the application developers and ultimately the end-users of those applications. People have accepted them because there is no other choice an an IPv4/NAT scenario - but with the deployment of IPv6 without NAT those costs can disappear. So we'll have more reliable, more naturally secure and more scalable applications at less cost. > > So, roll on NAT! we won't need it to in IPv6 as an address proxy, > and it won't add security, but I still expect it to happen. > Returning to the original question, for the comparative advantage of network camouflage, verses the other costs NAT incurs, I'm willing to go without it. Regards, Mark.
- [v6ops] network topology hiding Toru Kuboshiki
- Re: [v6ops] network topology hiding Fred Baker
- Re: [v6ops] network topology hiding t.petch
- Re: [v6ops] network topology hiding Erik Kline
- Re: [v6ops] network topology hiding Carlos Martinez-Cagnazzo
- Re: [v6ops] network topology hiding Arturo Servin
- Re: [v6ops] network topology hiding Ted Lemon
- Re: [v6ops] network topology hiding Roland Bless
- Re: [v6ops] network topology hiding Joel Jaeggli
- Re: [v6ops] network topology hiding james woodyatt
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Sander Steffann
- Re: [v6ops] network topology hiding Mark Smith
- Re: [v6ops] network topology hiding Roland Bless
- Re: [v6ops] network topology hiding Michael Newbery
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Merike Kaeo
- Re: [v6ops] network topology hiding t.petch
- Re: [v6ops] network topology hiding Erik Kline
- Re: [v6ops] network topology hiding Mark Smith
- Re: [v6ops] network topology hiding Toru Kuboshiki
- Re: [v6ops] network topology hiding Mark Smith
- Re: [v6ops] network topology hiding Gunter Van de Velde (gvandeve)
- Re: [v6ops] network topology hiding Erik Kline
- Re: [v6ops] network topology hiding Fred Baker
- Re: [v6ops] network topology hiding Erik Kline
- Re: [v6ops] network topology hiding Joel Jaeggli
- Re: [v6ops] network topology hiding Merike Kaeo
- Re: [v6ops] network topology hiding Brian E Carpenter
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Fred Baker
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Erik Kline
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Gunter Van de Velde (gvandeve)
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Gunter Van de Velde (gvandeve)
- Re: [v6ops] network topology hiding Fernando Gont
- Re: [v6ops] network topology hiding Toru Kuboshiki
- Re: [v6ops] network topology hiding Joel Jaeggli