Subject: [v4v6interim] Single namespace

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 13:42:11 -0400

picking up from the discussion in the chat room, and passing along a  
question that jabber wasn't able to deliver in the chat room.

Not sure we're disagreeing on whether there should be a single name  
space. The real question is what you say about a name when you're  
asked to translate it into a name.

Let's imagine that the name oatwillie.example.com has two A records,  
pointing respectively to 1.2.3.4 and 192.168.0.1. The question is not  
whether the name is different in different namespaces; the question is  
whether the translation is different in different domains.

The way we usually implement this kind of thing is to have multiple  
name servers, one of which is accessible from outside and the other is  
accessible from inside. That gives us one name space, but different  
responses to that translation request depending on the source of the  
request. DNS64 does largely the same thing, but commits the gross and  
indecent act of saying out loud that it does so.

The difference in the domains in DNS64 is between an IPv4 (IPv4-only  
or IPv4+IPv6) domain and an IPv6-only domain and referencing a name  
that has an A record but not an AAAA record.

So now I will repeat my question. You said that you didn't care for  
DNS64. I'm asking what, specifically, you would prefer to use.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 13:44:32 -0400

> asked to translate it into a name.

arg: s/into a name/into a record reporting an address/
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Oct 2008 13:57:26 -0400

On Wed, Oct 01, 2008 at 01:42:11PM -0400, Fred Baker wrote:

> The way we usually implement this kind of thing is to have multiple name 
> servers, one of which is accessible from outside and the other is 

I think that in the scenario with one RFC1918 address and one public
address, one of the answers comes with a local context and the other
comes with a global context.  The local context is determinable by the
querying host on the basis of the host's own IP address, because you
know that if you have an RFC1918 address, you're in a local-only
context.  In the case of DNS64, however, the whole point is that the
host doesn't need to know that it's living in a special place.  So
there's nothing about the state of the host that tells you what the
context is.  Instead, you need to know what the state of its relation
to other hosts on the Internet is in order to know what the "right"
context is.  Something about that makes me uneasy, but I can't yet put
my finger on what.

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 14:03:35 -0400

fine. I'll argue that the IPv4 host in my example doesn't know  
anything about public or private addresses; it knows what server it  
has been instructed to use.

In the DNS64/IVI case, it knows little more. It knows that it has no  
IPv4 DNS server and no IPv4 router or address, and that it has all of  
those in IPv6. So it asks for a AAAA record for any name it needs  
translated into an address, and it believes the translation. The  
translation is scoped - the DNS64 server advertises AAAA records  
derived from A records when it has no other AAAA record to present,  
and it does so in the domain in which it resides. But the host knows  
nothing of the scoping.

On Oct 1, 2008, at 1:57 PM, Andrew Sullivan wrote:

>> name

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 14:16:11 -0400

On Oct 1, 2008, at 2:09 PM, [email-masked] wrote:
> that said, DNS64 is asserted to provide a different answer depending  
> on
> where the question originates.  Some folks do this today w/ a bind  
> construct
> called "views".  if  DNS64 "constructs" synthetic addresses on the fly
> (algorithmically generated addressess) as proposed,  is this based  
> on the
> DNS64 application intercepting a DNS reply - (here is the A rr) and  
> fabricating
> a lie (here is the AAAA rr) to pass to the querier? where the AAAA  
> is the address
> of the translation device?

It doesn't intercept anything.

It gets a AAAA request from some host, sends a request for an A record  
(perhaps o itself), gets the A record response, generates a AAAA  
record from it, and sends that as a reply to the original request.

> If this is a plausable explaination, then I would posit that the  
> creation of
> DNS64 is injecting a MITM vector that is unreasonable.

Any form of translation is a MITM vector. If you find translation  
unreasonable, then yes you will find that vector unreasonable. If you  
find translation necessary, I don't think you can avoid the  
possibility that the translator is a MITM vector.

> depending on the deployment model, i think that properly placed DNS  
> caches, running
> dual stack, would work just fine.

several problems there. First, what if a name exists and is  
translatable but doesn't happen to be in the cache at the moment? Do  
you populate the cache? Second, what if the cache is poisoned?

Your complaining about MITM attacks?

> back to the oatwillie.example.com case...
> presume the node has a single NIC  ::   2001:478:6::cafe
> and and IVI box with               ::   2001:478:6::254
> 	                           ::   198.32.6.251
>
> with a dual-stack DNS server       ::   2001:478:6::11
>                                   ::   198.32.6.11
>
> inside the DNS server, I might make the following mapping for  
> oatwillie:
>
> oatwillie	in aaaa 2001:478:6::cafe
> 		in a    198.32.6.251
>
>
> would that work for you?

Maybe. If the server directly knows the translation already, it's  
great. I don't think it is a very general solution, though, as there  
is no way to populate the cache in the first place.

---

From: james woodyatt <[email-masked]>
Date: Wed, 1 Oct 2008 11:34:30 -0700

On Oct 1, 2008, at 10:42, Fred Baker wrote:
> name servers, one of which is accessible from outside and the other  
> is accessible from inside.

The reason I've been having a hard time following this discussion is  
that you're using the word "domain" where I've always seen the word  
"horizon" in order to distinguish the concept from the meaning of the  
word "domain" in Domain Name System.

> That gives us one name space, but different responses to that  
> translation request depending on the source of the request. DNS64  
> does largely the same thing, but commits the gross and indecent act  
> of saying out loud that it does so.

The "gross indecency" here is, apparently, admitting in public that we  
cannot escape the need to amend the DNS standards to recognize, for  
the first time, that we need more than one public horizon, i.e. the  
V4V6COEX public horizon and the IPv6 public horizon.

I do not see how we can escape that problem except by deprecating IPv4- 
only operation.  You want to talk to IPv6 nodes?  Then get yourself an  
IPv6 stack and a default route. Otherwise, have a coke and a smile,  
and shut the frell up.  I'm assuming that rough consensus is still  
leaning away from that, so can we please face up to the reality that  
multiple public DNS horizons are the way out of this?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 15:18:48 -0400

On Oct 1, 2008, at 2:30 PM, [email-masked] wrote:
> 	so the DNS64 app is configured in the endsystems as the
> 	caching nameserver for the domain.  in that case, there is
> 	an operational question or  two.

not sure how that works in a real domain. IVI and NAT64 configure it  
in the common server.

> 	right - but keeping the translation at the network layer instead
> 	of the application layer reduces complexity.

arg.

you're doing DNS name translation at the network layer?

You sound like my marketing people.

> 	translateable is not an artifact of the DNS, thats properly the
> 	perview of a NAT.

and you found this in a document that described a NAT.

I'm lost.

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 15:22:26 -0400

On Oct 1, 2008, at 2:34 PM, james woodyatt wrote:

> "horizon" in order to distinguish the concept from the meaning of  
> the word "domain" in Domain Name System.

The horizon is the edge of the routing domain.

> The "gross indecency" here is, apparently, admitting in public that  
> we cannot escape the need to amend the DNS standards to recognize,  
> for the first time, that we need more than one public horizon, i.e.  
> the V4V6COEX public horizon and the IPv6 public horizon.

perhaps. I find such things a little idiotic. It's one thing to say  
you don't want to do it; there are a lot of things I don't like to do  
and want guidance when I am forced to do them. Pretending it doesn't  
exist and going bats when someone points out the elephant in the room  
isn't very productive.

> I do not see how we can escape that problem except by deprecating  
> IPv4-only operation.

You get my vote. Talk with the network operators. Do you happen to  
know any? :-)
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2008 10:20:24 +1300

The fact of life is that we already have an untold number
of DNS namespaces. Offering different views of the
namespace inside and outside corporate networks is standard
practice. Now this offends the computer science view of the
DNS as creating a single, formal, unique namespace but it hasn't
been that way for at least ten years.

Although DNS64 is even more offensive to the computer science
view, I can't see any realistic solution to the v4only/v6 only
interworking problem that doesn't *require* different views
of the namespace on the two sides, created dynamically to
match the translation state.

   Brian
   Dept of Computer Science
   Univ of Auckland

On 2008-10-02 08:22, Fred Baker wrote:
> perhaps. I find such things a little idiotic. It's one thing to say you
> don't want to do it; there are a lot of things I don't like to do and
> want guidance when I am forced to do them. Pretending it doesn't exist
> and going bats when someone points out the elephant in the room isn't
> very productive.
> 
> You get my vote. Talk with the network operators. Do you happen to know
> any? :-)

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Oct 2008 00:52:21 -0400

On Wed, Oct 01, 2008 at 11:34:30AM -0700, james woodyatt wrote:

> cannot escape the need to amend the DNS standards to recognize, for the 
> first time, that we need more than one public horizon, i.e. the V4V6COEX 
> public horizon and the IPv6 public horizon.

While I understand that suggestion, and even have a certain amount of
sympathy with it, I note that there's a practical reason that many
DNS-heads don't like multiple versions of the namespace: they tend to
leak into other contexts.  Since we have experience with this
already, it would be prudent to plan that such leaks will be part of
any future deployment of "split-brain" approaches.

This is bad enough in the context of corporate NATs with RFC 1918
addresses inside, but at least one has a hope of spotting this (by
virtue of the 1918 address itself).  I appreciate what Fred said
earlier, that applications don't always care about the distinction
between 1918 and non-1918 address spaces; but the distinction is an
old one, and applications (or just help desk workers) that need to
deal with these cases can use that distinction to help them.  Since by
definition, in this case, what we're trying to address are
applications that can't learn new things (or they'd use IPv6
natively), I'm pretty worried that we'll create new modes of failure
that will be very hard to troubleshoot, because we'll have inserted a
new device in the network whose whole purpose is to intercept DNS
packets and change them into something else.

To be clear, I'm not saying, "Disaster! Bad! Evil! No! DNS purity!"
I'm just raising a caution that there seems to be a boom on for
split-brain DNS answers, and such answers come not only with DNSSEC
problems, but other issues as well.

A

---

From: Geoff Huston <[email-masked]>
Date: Thu, 2 Oct 2008 16:35:47 +1000

> problems, but other issues as well.

Oh that it were different. Would that we have completed this  
transition while there was plentiful IPv4 addresses left in the pool.  
Would that the dial stack transition were undertaken while we weren't  
being forced to assume unnatural configurations due to IPv4 address  
exhaustion. That way we would not be attempting to shoehorn a size 128  
Internet into a size 32 shoe for the next decade or more.

But we are where we are and now we have to explore notions that  
decouple the previously strict concepts of the equivalence of names  
and addresses. And if an IPv4 only host wants to initiate a  
conversation with an IPv6 only host, then the initial part of the  
conventional rendezvous, the DNS lookup, has to creatively lie in its  
response. Yeah, its crap, and yeah, its going to cause grief. Stuff  
will leak inappropriately and debugging problems will be tougher. And  
the DNS gets broken in strange ways as a consequence.

But we all knew this Andrew, didn't we? So I for one am not sure what  
point you are making here that wasn't part and parcel of any of these  
hybrid translation approaches. Am I missing something here in your  
post that advances something that was not well understood already?

Geoff

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Oct 2008 10:48:30 +0100

On 2 okt 2008, at 5:52, Andrew Sullivan wrote:

> there's a practical reason that many

> virtue of the 1918 address itself).

If we use a well known prefix for the translator then the problem is  
no worse than in the RFC 1918 case.

> I'm pretty worried that we'll create new modes of failure

Nobody wants to put a device in the network that _intercepts_ DNS  
packets.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Oct 2008 08:55:49 -0400

On Oct 2, 2008, at 12:52 AM, Andrew Sullivan wrote:

> leak into other contexts.

no doubt. When we pretend something doesn't exist, it's pretty easy  
for it to get screwed up.

I'll argue that recognizing the issue and designing a solution will  
work better than whistling in the dark.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Oct 2008 09:22:52 -0400

On Thu, Oct 02, 2008 at 04:35:47PM +1000, Geoff Huston wrote:
> But we all knew this Andrew, didn't we? So I for one am not sure what point 
> you are making here that wasn't part and parcel of any of these hybrid 
> translation approaches. Am I missing something here in your post that 
> advances something that was not well understood already?

I don't think I'm advancing something that was not understood, but I
am arguing that it is not plain the benefits are worth the cost.  I am
pretty sure there are going to be DNS protocol enthusiasts who think
it's _not_ worth the cost.  Certainly we're going to have to have a
better argument than "We know we're introducing this breakage, so it's
ok."

I can imagine someone arguing, for instance, that if you're an
IPv4-only operator and you want people on v6 networks to be able to
use your services, put a AAAA record for a v4-compatible (or some new,
improved v4-compatible) address in the DNS.  If the response is, "But
v4-only operators might not do that, and v6 users will suffer," then
we're begging the question, because what we're debating is whether
altering DNS answers for some users is ok given the benefit thereby
achieved.  Such a person might also argue that supporting v4 users'
use of v6-only systems is just not a practical goal given the costs,
and if they want to use those services, that will give them an
excellent incentive to add IPv6 support; so for practical reasons, we
shouldn't try to solve that scenario.

Note that there's an important disanalogy between the current
proposals and the corporate network, split-brain case.  If I run a
split-brain DNS installation, I am taking the risk of leaks &c.  It's
my network, and if I want to do funky things inside it, that's
arguably my privilege.  But unless I'm missing something important,
most of the current proposals will change the DNS answers without the
operator of the source DNS answer needing to know anything about it.
The potential for increases in support costs and surprising results is
real, and that will cause people to object.

A

---

From: "Ed Koehler Jr" <[email-masked]>
Date: Thu, 2 Oct 2008 09:22:37 -0400

If that is the case then it would make sense to get this documented as a
common practice. We have to determine between idealized and realizable. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Fred Baker
Sent: Thursday, October 02, 2008 8:56 AM
To: Andrew Sullivan
Cc: [email-masked]
Subject: Re: [v4v6interim] Single namespace

> leak into other contexts.

no doubt. When we pretend something doesn't exist, it's pretty easy for
it to get screwed up.

I'll argue that recognizing the issue and designing a solution will work
better than whistling in the dark.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Alain Durand <[email-masked]>
Date: Thu, 02 Oct 2008 09:40:14 -0400

> match the translation state.

In the case of v6->v4, there is actually a solution that *does*not*require*
creating different views of the namespace. The v6 host can use its IPv4
stack with Dual-stack lite, and the problem goes away entirely.

  - Alain.

---

From: james woodyatt <[email-masked]>
Date: Thu, 2 Oct 2008 10:07:58 -0700

On Oct 2, 2008, at 06:22, Andrew Sullivan wrote:
>
> Such a person might also argue that supporting v4 users' use of v6- 
> only systems is just not a practical goal given the costs, and if  
> they want to use those services, that will give them an
> excellent incentive to add IPv6 support; so for practical reasons,  
> we shouldn't try to solve that scenario.

The corollary is a better argument: if application service operators  
would like to be reachable and available to IPv4-only clients, and  
making such services IPv6-only is just not a practical goal given the  
costs, then that will give such operators an excellent incentive to  
run a dual-stack site.

---

From: james woodyatt <[email-masked]>
Date: Thu, 2 Oct 2008 12:37:50 -0700

> stack with Dual-stack lite, and the problem goes away entirely.

Except, the v6->v4 case is only half the picture.  The problem is  
entirely in the other half.  It does not go away.  You have simply  
chosen not to see it.

IPv6 hosts running DS-Lite can initiate flows to IPv4 endpoints, but  
they do not have public IPv4 addresses and they can't make their  
services available to IPv4-only hosts without help from the service  
provider.  From the perspective of IPv4-only clients, DS-Lite servers  
are in a walled garden.

Brief digression: if you want to make any kind of services available  
to IPv4-only clients, then you have two basic choices:

   + Make your services available over IPv4 at publicly assigned
     and routed addresses.  Advertise DNS content normally.

   + Make your services available through an IPv4 translator.
     Advertise DNS content with addresses translated into the
     public IPv4 realm.

In the second case, from the perspective of IPv4-only clients, it does  
not matter whether the server is in a private IPv4 realm or in the  
public IPv6 realm.  If you'd like your IPv6 services to be available  
to IPv4-only hosts, you have only two choices: A) run full dual-stack  
servers (not DS-Lite), or B) deploy a translator with a DNS gateway to  
the public IPv4 horizon.

As it happens, here at Apple, we have a service called Back To My Mac™  
(part of our MobileMe™) service that basically does option B) today,  
because our customers often don't full native IPv4 service, i.e. they  
have private networks.  (Interestingly, we avoided the whole IPv4  
address realm conflict problem by tunneling IPv6 over ESP/UDP/IPv4  
through NAT with NAT-PMP and using DNS-SD tricks to manage the  
equivalent problem to what is under discussion here, but that's a side- 
track for now.)

Please take note of the problem if you try to make Back To My Mac™  
work by tunneling inside ESP transport mode IPv6 in addition to ESP  
IPv4/NAT-T.  The additional mode would be a simplification of the  
current mode, actually, because NAT-PMP wouldn't be required (though,  
ALD might be, depending...).  However, it would only be good for IPv6- 
capable clients-- IPv4-only clients would still have no recourse if  
the SP NAT does not help with the IPv4 autotunnel.  You might imagine  
deploying something like IVI or NAT64, so that IPv6 servers register  
their tunnels in the DNS through a DNS64 gateway that knows about the  
NAT64 point where ESP/UDP/IPv4 is translated into ESP/IPv6, but that  
would be not-at-all anything like what you see in the DS-Lite draft.   
It *also* doesn't look like the current NAT6/NAT64/IVI/what-have-you  
proposals because nothing in those drafts talks much about DNS-SD (or  
its moral equivalent).  They seem to just hand-wave over that problem.

Summarizing, these are the sorts of problems that have me convinced  
that trying to make IPv6-only services reachable from IPv4-only  
clients is a losing game in the long run.  We should concentrate our  
coexistence effort on the following problems:

   A) Ensuring that *all* kinds of dual-stack clients see IPv6 servers,

   B) Ensuring that IPv4-only clients see dual-stack servers,

   ...and finally...

   C) Ensuring that dual-stack servers can register equivalently in  
the DNS for
      both IPv4-only clients and dual-stack clients,

   ...while...

   D) Bearing mind that Teredo hosts and nodes in 6to4 sites may be  
dual-stack,
      and they may be either/both clients and/or servers.  (No, I  
don't care
      about ISATAP today.  I'm not going to care until ISATAP  
deployments are
      numerous enough to matter.)

At this point, I view everything else as a dangerous distraction from  
our basic coexistence problem set, and it should be deferred until the  
happy eventuality that they become a more pressing problem than they  
are today.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Oct 2008 13:41:24 +1300

> stack with Dual-stack lite, and the problem goes away entirely.

Agreed. But if you have a true v6-only scenario in the host, that doesn't
work. I agree with those who've said we'd better document this
issue rather than pretending it isn't real.

    Brian