RE: I-D Action:draft-daley-ipv6-nonat6-00.txt
Greg Daley <hoskuld@hotmail.com> Sun, 12 July 2009 23:01 UTC
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D527D28C0D0 for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 12 Jul 2009 16:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 1Yw3qklPqrpa for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 12 Jul 2009 16:01:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6D8523A6C84 for <v6ops-archive@lists.ietf.org>; Sun, 12 Jul 2009 16:01:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1MQ802-0009W9-J5 for v6ops-data0@psg.com; Sun, 12 Jul 2009 22:58:26 +0000
Received: from bay0-omc1-s21.bay0.hotmail.com ([65.54.246.93]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <hoskuld@hotmail.com>) id 1MQ7zl-0009Uf-5X for v6ops@ops.ietf.org; Sun, 12 Jul 2009 22:58:20 +0000
Received: from BAY114-W31 ([65.54.169.131]) by bay0-omc1-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 15:58:08 -0700
Message-ID: <BAY114-W31D52AE7A1749EF62EFA45AD250@phx.gbl>
X-Originating-IP: [124.168.63.75]
From: Greg Daley <hoskuld@hotmail.com>
To: brian.e.carpenter@gmail.com
CC: v6ops@ops.ietf.org
Subject: RE: I-D Action:draft-daley-ipv6-nonat6-00.txt
Date: Mon, 13 Jul 2009 08:58:08 +1000
Importance: Normal
In-Reply-To: <4A5A0779.7090100@gmail.com>
References: <20090706234501.47BC13A6D43@core3.amsl.com> <4A5A0779.7090100@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Jul 2009 22:58:08.0110 (UTC) FILETIME=[38EB88E0:01CA0344]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
Hi Brian, Thanks for reading what is still a very rough draft. This draft was primarily born out of the discussions at last IETF meeting, where several of the listeners were confused about how new IPv6 NAT tasks were being justified in terms of the services required. There was a lot of discussion about (non-port based) NAT operations. This document seeks to clarify how these functions would actually work, and how alternatives would also work. The role of alternatives here is not to entrench a proliferation of ideas, but to show that the alternatives can be a complete replacement for NAT operations within the network. The relationship with RFC4864 is not delineated clearly, and I will have to work on the references which were poorly constructed. I apologize. I will see how I can identify the relationship, and the goals of this draft early in the Introduction. One of the solutions shown for Network Topology hiding (the Tunneled Services) could be implemented as a Mobile IPv6 service. Personally, I do not think this will be a successful deployment model because of the heavy implementation load (IPSec, dynamic movement/change detection, home movement considerations) which would be required for deploying the endpoint/Mobile Node. It is more likely that a simple IPv6-in-IPv6(or UDP) tunnel, with a gateway discovery advertisement would meet the local network's address binding need, because it would be more universally implemented. As such, I have stuck closer to more theoretic tunnelled approach as described in the 6ai BoF. I would be very happy if everyone just used MIPv6 though. Once again, sorry for rushing this out. There was a set of analysis in the document which I thought made the distinction between NAT's Goals and operations clearer, and I didn't want to let the meeting pass without sending it to the ether. I will try to fix some of the structural and reference issues, and see if there is a solid contribution. Thanks again, Greg Daley ---------------------------------------- > Date: Sun, 12 Jul 2009 16:55:37 +0100 > From: brian.e.carpenter@gmail.com > To: hoskuld@hotmail.com > CC: v6ops@ops.ietf.org > Subject: Re: I-D Action:draft-daley-ipv6-nonat6-00.txt > > Hi Greg, > > I'm not sure I understand your citation of RFC4864 in this draft: > >> Until now, NATs have only existed for IPv4, and for transitioning >> from an IPv6 network to an IPv4 network [RFC2766][RFC4864]. > > The whole point of 4864 was to identify the claimed benefits of NAT > and discuss how IPv6 can provide them without NAT. It's certainly > relevant to your draft, but I think it would be useful to be explicit > about which parts of the gap analysis in 4864 you are addressing, > and about whether 4864 missed part of the gap. It doesn't use the > phrase "address independence" but does cover > Privacy and Topology Hiding, > Independent Control of Addressing in a Private Network > Global Address Pool Conservation > Multihoming and Renumbering with NAT > > Note, I'm not particularly disagreeing with your draft, I just think > it could be better explained how it fits with the RFC4864 gap analysis. > > We also suggested some possible directions for topology hiding > in 4864, including using Mobile IP tunnels on larger sites. > I'm not sure we need any new mechanisms. > > Regards > Brian > _________________________________________________________________ Looking for a place to rent, share or buy this winter? Find your next place with Ninemsn property http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline&_t=774152450&_r=Domain_tagline&_m=EXT
- Re: I-D Action:draft-daley-ipv6-nonat6-00.txt Brian E Carpenter
- RE: I-D Action:draft-daley-ipv6-nonat6-00.txt Greg Daley