Re: [BEHAVE] Call for WG adoption of several documents

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Andrew Sullivan
> Sent: Tuesday, February 15, 2011 7:49 AM
> To: behave@ietf.org
> Subject: Re: [BEHAVE] Call for WG adoption of several documents
> 
> On Mon, Feb 14, 2011 at 05:02:18PM -0800, Dan Wing wrote:
> 
> > (notably see slide #6), and I distinctly recall Andrew Sullivan
> pointing
> > out that traffic that it costs the same to traverse a NAT44 or a
> NAT64,
> > which I agree.  The only true savings is if the network doesn't have
> a
> > NAT44, such as depicted on slide 5, or of course if the application
> > simply breaks when traversing a NAT64 (but works when traversing a
> > NAT44).
> >
> > The question is:  for dual-stack hosts, do we want to avoid the
> > NAT64?
> 
> I don't get why these dual-stack hosts are getting the DNS64 as their
> resolver. 

One physical network with two hosts:  an IPv6-only host (which
require a NAT64 to access the IPv4 Internet) and a dual-stack
host.  

The scenario is a network that wants/needs IPv6-only devices
(perhaps for testing, perhaps for real deployment), but -- 
critically -- does not want to disrupt or disturb their
existing dual-stack hosts.

> The only case I've heard so far is something to do with
> some complicated (and frankly, a little artificial) case where one
> group of network interfaces is really dual-stack, and the other group
> is actually NAT64, and you can't tell the difference up in the
> application layer and you pick the wrong one. 

That would be über nasty.  I had not heard that use-case.

> That's not a problem we
> can solve: it's a MIF problem, and just a special case of the general
> problem that if you're in multiple networks and they have different
> networks available, you have a hard problem.

Agreed.

> On top of this (and this is the point Dan remembers), a lot of this
> talk is as though you have a pure, unmolested, IPv6 and IPv4 dual
> stack view, and then the nasty IPv4+NAT64 view.  But that's almost
> never going to be true in the cases we care about: most of the time,
> the IPv4 connectivity is already NAT44, and you need a very compelling
> case for why we need to make this giant NAT64 hairball even fuzzier in
> order to prefer a NAT44 to a NAT64.  The compelling case boils down to
> "protocols with IPv4 literals embedded in them."  I find it very hard
> to believe that we are going to fix that generic problem well enough
> that the better answer won't be "application gateway" every time.  We
> know how to build and ship the latter today.
> 
> I don't think we should be adding elliptics, epicycles, and eccentrics
> to this already complicated NAT cosmology to solve the tiny percentage
> of the cases where this will really matter.

Ok.

> I do think that having a way for applications to learn that they're
> getting synthetic responses from the DNS would be useful, but that's
> because over in DNS land we're already trying to build new PKIs on top
> of DNSSEC (see the DANE WG), and I'd hate for that all to break the
> moment someone is stuck behind a NAT64.

That's a vote for a solution in draft-korhonen-behave-nat64-learn-analysis.

I saw your other note about skin-crawling with a DNS name.  :-)  Will 
follow up on that separately.

-d

> A
> 
> --
> Andrew Sullivan
> ajs@shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave