RE: (ngtrans) Last call on draft-ietf-ngtrans-dns-ops-req-02.txt

Christian Huitema <huitema@windows.microsoft.com> Mon, 22 October 2001 14:48 UTC

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19002 for <ngtrans-archive@odin.ietf.org>; Mon, 22 Oct 2001 10:48:19 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14046; Mon, 22 Oct 2001 08:46:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18263; Mon, 22 Oct 2001 07:46:31 -0700 (PDT)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MEkFOI007464 for <ngtrans-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:46:15 -0700 (PDT)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MEkFBB007463 for ngtrans-dist; Mon, 22 Oct 2001 07:46:15 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MEkCOI007456 for <ngtrans@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:46:12 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v2.1p1) with ESMTP id HAA18146 for <ngtrans@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:46:05 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14370 for <ngtrans@sunroof.eng.sun.com>; Mon, 22 Oct 2001 07:46:13 -0700 (PDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Oct 2001 07:46:11 -0700
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Oct 2001 07:46:11 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Oct 2001 07:46:09 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Oct 2001 07:46:09 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Mon, 22 Oct 2001 07:46:04 -0700
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6063.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: (ngtrans) Last call on draft-ietf-ngtrans-dns-ops-req-02.txt
Date: Mon, 22 Oct 2001 07:45:33 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E37D@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: (ngtrans) Last call on draft-ietf-ngtrans-dns-ops-req-02.txt
Thread-Index: AcFaRVJbwUWKSnOmTm2FjdLa2/IBIQAwa/tA
From: Christian Huitema <huitema@windows.microsoft.com>
To: Randy Bush <randy@psg.com>
Cc: ngtrans@sunroof.eng.sun.com
X-OriginalArrivalTime: 22 Oct 2001 14:46:04.0350 (UTC) FILETIME=[467C45E0:01C15B08]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f9MEkCOI007457
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Christian Huitema <huitema@windows.microsoft.com>
Content-Transfer-Encoding: 8bit

> > Again, I'd say "no".  For the next very many years (unless something
> > unexpected happends) we'd be able to manage just fine with
dual-stack.
> 
> mandating a dual-stack on all v6-capable hosts might be an approach.
but
> i suspect it will not be acceptable in some application/vendor
domains.

If an IPv6 only host wants to resolve a name that is served only by IPv4
capable DNS servers, it can send the request through a protocol
translating NAT (NAT-PT), and it will receive the response. There is an
operational issue, the fact that the current NAT-PT specification
mandates an "application layer gateway" treatment of DNS packets,
automatically translating A records into AAAA records; I find that a
poor trade-off between convenience and robustness; we may need to
revisit the issue. Nevertheless, NAT-PT should provide a generic
solution for "v6 hosts discovering v4 hosts."

The opposite problem, v4 only hosts discovering services provided in v6
only domains, is somewhat harder to solve. Indeed, at some point it will
become impossible to solve simply by address translation, since 2^32 <
2^128.

-- Christian Huitema