Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?

Dave Thaler <dthaler@microsoft.com> Fri, 17 June 2011 17:04 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05999E8007; Fri, 17 Jun 2011 10:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.542
X-Spam-Level:
X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9MT-GBihkJX; Fri, 17 Jun 2011 10:04:40 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2E9E8005; Fri, 17 Jun 2011 10:04:40 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 17 Jun 2011 10:04:40 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 17 Jun 2011 10:04:39 -0700
Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Fri, 17 Jun 2011 10:04:39 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: Mark Townsley <mark@townsley.net>, "K.Fleischhauer@telekom.de" <K.Fleischhauer@telekom.de>
Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?
Thread-Index: AQHMLPGivtoY85X6EUKujJJYVGTXOZTBxJ+A
Date: Fri, 17 Jun 2011 17:04:39 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net>
In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.42]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 19 Jun 2011 14:25:46 -0700
Cc: "pppext@ietf.org" <pppext@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 17:04:40 -0000

Mark Townsley wrote:
[...]
> Applications may not be all that forgiving to IPv4 coming and going either, e.g.,
> I have a popular mail client that has recently taken to crashing when I switch
> from wired to wireless and get a different IP address in the process. Some of
> the IM connections I keep up recover quickly to IP changes, others do not. The
> IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP address
> coming and going - it's not always easy, in particular when the link-layer is not
> giving your IP stack any up/down notification, which I believe by definition is
> what your proposal requires from the very start.
[...]

I'll second the above.   This is very problematic for some applications.
(Other solutions like DSTM that have on-demand IP addresses have this same issue.)

So any network that deploys such a solution in anything other than 
a tightly controlled environment where directly connected nodes are restricted
to a specific set of pre-tested applications, will likely result in many support calls.

-Dave