Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-6to4-03.txt

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 18 Oct 1999 11:37:59 -0700 (PDT)

Keith,

Thanks for clearly articulating the problem. Please see my comments
below.

regards,
suresh 

--- Keith Moore <[email-masked]> wrote:
> Suresh,
> 
> the case I'm concerned about is where there is no native v6 path between
> two v6-capable nodes, but there is a pseudo-v6 path through back-to-back
> NAT-PT boxes.  each end node thinks it's talking to a v6 peer.
> each NAT-PT box thinks it's talking to a remote v4 host, but in reality 
> both hosts are v6.  
> 
> e.g.
> 
> Host A ==== NAT-PT X --------- NAT-PT Y ==== Host B
> 
> ==== v6 path
> ---- v4 path
> 
> Host A thinks it has a v6 connection to Host B, but the v6 address
> that A uses to refer to B is not one of B's addresses. Similarly, 
> Host B thinks it has a v6 connection to Host A, but the v6 addresses
> that B uses to refer to A is not one of A's addresses.
> NAT-PT X thinks that Host B is a v4 host.
> NAT-PT Y thinks that Host A is a v4 host.
> 
> the point being, both A and B think they have a *real* v6 connection,
> but the connection doesn't have the characteristics that a v6 
> conneciton ought to have.
> 

Yes, this is a distinct possibility in the case where the only connectivity 
to the external world for a V6 domain is  through NAT-PT device and 
the NAT-PT device does not support some form of V6-over-V4 tunneling
functionality. NAT-PT function by itself merely supports
V6-to-V4 communication only.

However, I do believe, nativev6-to-nativev6 communication can be accomplished
with the above scenario so long as the NAT-PT device also supports some form
of  V6-over-v4 tunneling mechanism. 
 
> here's a worked out example, assuming that A initiates a connection to B:
> 
> 1. A queries B's name in DNS, looking for AAAA or A6 records.
> 
> 2. A's query first gets intercepted by NAT-PT X, which treats this as 
> an attempt to set up an "outgoing" connection per 4.2 of natpt-06. 
> so it forwards the query via IPv4 to the DNS server for B, and waits 
> for the response so it can be modified.

A's Query first gets intercepted by the  DNS server in A's 
domain (say, DNSv6-A), assuming A's domain has a DNS server. DNSv6-A would
subsequently forward the query to an external root name server.

If the external name server is located in the domain of B (say, DNSv6-B), 
it's IP address would be a native V6 address.  If the external name server 
is located in the V4 domain (say, DNSv4), it's IP address would be
PREFIX::<dnsv4>

NAT-PT and the DNS-ALG intercept the outgoing DNS query only so long
it is directed to a PERFIX address (ex: PREFIX::<dnsv4>). Queries 
directed to native v6 addresses (ex: DNSv6-B) will not be intercepted
by the NAT-PT function. The policy on the NAT-PT device may require 
that such packets use some form of tunneling over V4. That is outside 
the scope of NAT-PT document.

If you can make the assumption that (a) V6 name servers across the Internet
are conneted (i.e., know to each other) and (b) the Name server in the 
domain of A (i.e., DNSv6-A) queries native V6 name servers first, followed 
by the V4 name servers (i.e., those name servers with NAT-PT PREFIX), then
the nativev6-to-nativev6 communication can and will take place. Yes, NAT-PT
device would also be required to support some form of V6-over-V4 tunneling.

> (note: it's not clear from 4.2 what NAT-PT X should do to the
> query before forwarding, but presumably it will have to change the 
> query type on outgoing requests to "A"; otherwise it will not get
> useful responses from older DNS servers.  Either that or it will
> have to wait for the initial response to "AAAA" or "A6" queries 
> and if the response contains no information, retransmit the request 
> with query type set to "A"...which adds delay.  I'm assuming
> that the query type gets translated to "A")
>
Your assumption is right. The query type would be changed to A. 
(It is actually detailed in 4.1 - could have been detailed in 4.2 
as well, I guess).

Not modifying the query can cause a variety of other problems in
the scenarios where NAT-PT is supposed to be most useful (i.e.,
legac V4 domains).

> 3. The forwarded request then gets intercepted by NAT-PT Y, which
> treats this as an attempt to set up an "incoming" connection per
> 4.1 of natpt-06.  So it allocates a v4 address and associates it
> with B's v6 address, and returns an answer A=<v4-addr-assigned-to-B> 
> 

What you say is true, if the only external name server configured 
in DNSv6-A is DNSv4.

NAT-PT makes the assumption that name servers in V4 domains will
have authoritative information for V4 nodes only (i.e., A records
only) and does not contain any AAAA records. This is the reason
why DNS-ALG translates AAAA/A6 query types into A query type.

So, even if DNSv4 contains AAAA/A6 record info for B, as the original
query is translated to A type, the reponse cannot come in the form of 
AAAA/A6.

> 4. NAT-PT X gets the response back from NAT-PT Y, and modifies
> it so that the response looks like AAAA=PREFIX-X::<v4-addr-assigned-to-B>
> 
> meanwhile A's address has been translated to <v4-addr-assigned-to-A>  
> between X and Y and to PREFIX-Y:<v4-addr-assigned-to-A> on B's side of Y.
> 
> Am I wrong in assuming that X translates the query type to A in 
> outgoing queries?
> If so, then how does X deal with the case where the remote DNS server
> returns AAAA or A6 records (which are not reachable)?  How does X deal 
> with the case where the remote DNS server returns "no records matching 
> this query" (either because it has only A records, or because it
> does not support AAAA or A6 query types)?
> 

Hope, my earlier comments addressed this. Thanks.

> Keith

regards,
suresh

=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Oct 1999 14:38:34 -0400

> of  V6-over-v4 tunneling mechanism. 

I agree, *provided* we can define a general enough mechanism that allows
arbitrary v6 islands to communicate natively over a v4 network.  (Hence
my suggestions to use DNS and/or BGP for tunnel endpoint advertisements.)

> subsequently forward the query to an external root name server.

(or to some other external name server, presuming that it has cached 
some suffix of B's DNS name)
 
> it's IP address would be a native V6 address.  

there's no reason to make any association between B's DNS domain 
and the network addresses associated with B's portion of the net.
For example, B might reside on a v4/v6 network, even though B is
a v6-only host.  Or B's DNS domain might indeed be sourced from
a v6-only net, but have secondary servers in v4-space.

> If the external name server 

There is no such thing as a v6 name server.  The DNS protocol is the
same regardless of whether it is running over v4 or v6.  A DNS server
on a v4 network can return AAAA or A6 records, and a DNS server on
a v6 network can return A records.  

So no, I don't think such assumptions are reasonable.

There are of course name servers that don't understand AAAA or A6 queries.
For the cases where a v6-only host issues such a query and gets back
"domain is valid but no records match querytype", is it then necessary 
for the NAT-PT box to reissue the query looking for A records?
Or can a v6-only host be expected to do this? 

> (It is actually detailed in 4.1 - could have been detailed in 4.2 

since 4.2 describes outgoing connections, if the query type is to be
changed for outgoing connections, it needs to be described there.
but clearly you do not want to modify the query if there is a
possibility that the remote server will return AAAA or A6 records -
you want to give the host a chance to discover that there is a native
path.  and you cannot rely on the server's IP address (v4 or v6) as a
way to indicate whether this might be the case. 

> the scenarios where NAT-PT is supposed to be most useful (i.e.,

it looks like you have to or first forward the original query ,
and then (if the original query was for AAAA or A6) reissue
the query for A if the original one fails with the right error code.  
either that or issue both queries simultaneously.  (I'm not sure 
which strategy is more attractive.)

> why DNS-ALG translates AAAA/A6 query types into A query type.

As stated above, I don't think this is a reasonable assumption.

Keith