Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

Dave Thaler <dthaler@microsoft.com> Tue, 01 December 2009 19:26 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B093A692B for <behave@core3.amsl.com>; Tue, 1 Dec 2009 11:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.27
X-Spam-Level:
X-Spam-Status: No, score=-10.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 hp1wtY6zQuiO for <behave@core3.amsl.com>; Tue, 1 Dec 2009 11:26:39 -0800 (PST)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B3B843A690A for <behave@ietf.org>; Tue, 1 Dec 2009 11:26:39 -0800 (PST)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Dec 2009 11:26:58 -0800
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 1 Dec 2009 11:26:31 -0800
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 1 Dec 2009 11:26:31 -0800
From: Dave Thaler <dthaler@microsoft.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, "behave@ietf.org" <behave@ietf.org>
Thread-Topic: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
Thread-Index: AQHKcqpG2eUdkzWZQUCTf9KecyFv9ZFRAU4A//+QcDA=
Date: Tue, 01 Dec 2009 19:26:29 +0000
Message-ID: <E4561B14EE2A3E4E9D478EBFB5416E1B29B5A944@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <bcff0fba0911302332ub498269qabbdca8341b018d5@mail.gmail.com> <002f01ca7265$b6ededb0$d40c6f0a@china.huawei.com> <097401ca72aa$0828aa50$c3f0200a@cisco.com> <4B1559E6.4060003@viagenie.ca>
In-Reply-To: <4B1559E6.4060003@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2009 19:26:40 -0000

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Simon Perreault
> Sent: Tuesday, December 01, 2009 10:01 AM
> To: behave@ietf.org
> Subject: Re: [BEHAVE] proprietary implementation v.s
> standardisedprotocols//re: draft-xu-behave-nat-state-sync-00
> 
> Dan Wing wrote, on 2009-12-01 12:16:
> > It's not just the AAAA records getting cached.  It's also the
> > applications that have done their getaddrinfo() and now have the
> > IPv6 address in their internal datastructures.  There is no lifetime
> > for that, and very very few applications pay any attention to the
> > TTL of the AAAA record.  Applications expect the IPv6 address to
> > be fixed and to be valid as long as they need it.
> 
> How hard should NAT64 try to accommodate broken applications?
> 
> These applications would fail in many other cases that don't involve
> NAT64.
> 
> Simon

Yes but it's not the apps that are broken, it's the sockets
API that's broken (getaddrinfo and its predecessor gethostbyname
don't return it).  Applications just call APIs and are agnostic
as to whether the name gets resolved using DNS, hosts file,
mDNS, LLMNR, NetBIOS over TCP, or whatever else.  The only applications
that pay attention to TTL are ones that only support DNS and not
other protocols, and generally either implement DNS themselves 
or call DNS-specific APIs that expose a TTL.

So yes NAT64 should try (to the extent that is practical) 
to accommodate apps that don't pay attention to TTL, since that's
99.99% of all applications.

-Dave