Re: [v4v6interim] Single namespace

[james woodyatt <[e-mail]>]

On Oct 2, 2008, at 06:40, Alain Durand wrote:
> On 10/1/08 5:20 PM, "Brian E Carpenter"  
> <[e-mail]> wrote:
>>
>> 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.
>
> 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.

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.


--
james woodyatt <[e-mail]>
member of technical staff, communications engineering

_______________________________________________
v4v6interim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v4v6interim