Re: [Softwires] Softwires configuration via DHCP

"David W. Hankins" <David_Hankins@isc.org> Wed, 18 February 2009 22:27 UTC

Return-Path: <David_Hankins@isc.org>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB743A67F0 for <softwires@core3.amsl.com>; Wed, 18 Feb 2009 14:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 6gsCnYifIxMS for <softwires@core3.amsl.com>; Wed, 18 Feb 2009 14:27:48 -0800 (PST)
Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 024F43A676A for <softwires@ietf.org>; Wed, 18 Feb 2009 14:27:47 -0800 (PST)
Received: from david.isc.org (c-67-161-51-194.hsd1.ca.comcast.net [67.161.51.194]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id n1IMRxGQ016771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <softwires@ietf.org>; Wed, 18 Feb 2009 14:27:59 -0800
Received: by david.isc.org (Postfix, from userid 10200) id CF68316E1B3; Wed, 18 Feb 2009 14:27:58 -0800 (PST)
Date: Wed, 18 Feb 2009 14:27:58 -0800
From: "David W. Hankins" <David_Hankins@isc.org>
To: softwires@ietf.org
Message-ID: <20090218222757.GE4262@isc.org>
References: <20090217230232.GF16400@isc.org> <499B7659.7080604@gmail.com> <20090218042016.GA5061@isc.org> <499C85EC.7080809@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="7CZp05NP8/gJM8Cl"
Content-Disposition: inline
In-Reply-To: <499C85EC.7080809@gmail.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
Subject: Re: [Softwires] Softwires configuration via DHCP
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 22:27:48 -0000

First, thank you Brian for responding and thinking about this, I do
appreciate it.  My writing style is sometimes dry.

On Thu, Feb 19, 2009 at 11:04:28AM +1300, Brian E Carpenter wrote:
> Actually, wouldn't it allow a clever NAT to update session state
> automatically?

If you were to have two nodes sharing NAT mapping state, why would you
prefer to wait for DHCP renewal timers rather than to have the
surviving CGN simply take over routing for its peer's /128?  This is
the area of solutions I mean when I say I would expect 'tunnels' to
be handled by routing equipment, and solved with classic routing
solutions.

Surely by the time you are coordinating such NAT tables, the idea of
coordinating the use of /128s (fallbacks, anycasts) is trivial, and
preferrable to placing complications on the softwire-client end?

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins