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

Keith Moore <moore@cs.utk.edu> Mon, 22 October 2001 21:46 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 RAA00268 for <ngtrans-archive@lists.ietf.org>; Mon, 22 Oct 2001 17:46:33 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25366; Mon, 22 Oct 2001 15:45:19 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24213; Mon, 22 Oct 2001 14:45:22 -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 f9MLioOI008587 for <ngtrans-dist@sunroof.eng.sun.com>; Mon, 22 Oct 2001 14:44:50 -0700 (PDT)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f9MLioiq008586 for ngtrans-dist; Mon, 22 Oct 2001 14:44:50 -0700 (PDT)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f9MLikOI008579 for <ngtrans@sunroof.eng.sun.com>; Mon, 22 Oct 2001 14:44:46 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v2.1p1) with ESMTP id OAA24062 for <ngtrans@sunroof.eng.sun.com>; Mon, 22 Oct 2001 14:44:48 -0700 (PDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26539 for <ngtrans@sunroof.eng.sun.com>; Mon, 22 Oct 2001 14:44:47 -0700 (PDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id f9MLkhP29373; Mon, 22 Oct 2001 17:46:43 -0400 (EDT)
Message-Id: <200110222146.f9MLkhP29373@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: Christian Huitema <huitema@windows.microsoft.com>
cc: Keith Moore <moore@cs.utk.edu>, Randy Bush <randy@psg.com>, ngtrans@sunroof.eng.sun.com
Subject: Re: (ngtrans) Last call on draft-ietf-ngtrans-dns-ops-req-02.txt
In-reply-to: Your message of "Mon, 22 Oct 2001 12:18:22 PDT." <F66A04C29AD9034A8205949AD0C9010401C0E380@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Date: Mon, 22 Oct 2001 17:46:43 -0400
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Keith Moore <moore@cs.utk.edu>

> > but it sounds like you are saying that the v6 client has the burden of
> > providing access to v4-only DNS servers, which doesn't sound right to
> > me.
> 
> Well, the v6 client is the new piece of software that we are now
> fielding; the v4-only DNS server has been running for years and nobody
> wants to change it, so from a practical point of view, yes, I believe
> that the v6 client should go the extra mile.
> 
> What I point out is that the extra-mile may be as simple as getting
> access to the nat-pt service, smtg a v6 client is going to need anyhow
> if it wants to access data on one of those IPv4 servers that is not yet
> upgraded to IPv6.

If I understand what you are saying, I disagree.

It seems to me that if a v6 client wants to access a service that
is on the public v6 internet, it should need only to know the
addresss of DNS roots that support v6, and have the ability to 
send queries to DNS servers that support v6, via the normal means.

If a service wants to make services available to the public v6
internet, it should ensure that the DNS records needed to access 
those services (be they  MX, SRV, AAAA, whatever) can be accessed
using v6 from the public v6 internet, via the normal means.

(This does imply that there must be DNS roots accessible from v6,
and that every parent domain of every DNS record needed to access
a service must also be accessible using the v6 addresses in the 
reference chain.  But it doesn't imply anything about implementation.
Each of those zones could provide v6 access in any way it wished
consistent with the DNS protocol: dual-stack servers, a protocol 
converter, or separate servers for v4 and v6 that produced the 
same results.)

If a client can employ other means to access those services or get 
those DNS records, such as by failing over to IPv4 when a DNS server
cannot be reached using IPv6, or by routing queries through a 
dual-stack DNS proxy, so much the better.  But while it might be
a useful optimization, it shouldn't be required.

And of course NAT-PT must be employed to reach v6 from v4 or vice versa.
But it's completely unreasonable to expect v6 hosts to employ a NAT-PT
in order to access v6 services.

Keith