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

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Brian E Carpenter
> Sent: Monday, February 14, 2011 12:29 PM
> To: Dave Thaler
> Cc: 'behave' (behave@ietf.org)
> Subject: Re: [BEHAVE] Call for WG adoption of several documents
> 
> Hi,
> 
> On 2011-02-15 08:14, Dave Thaler wrote:
> > On our charter we have the following milestones for which there is no
> current WG document:
> > Apr 2011
> >
> > Submit to IESG: avoiding NAT64 with dual-stack host for local
> networks (std)
> >
> > Apr 2011
> >
> > Submit to IESG: NAT64 load balancing (std/info)
> >
> >
> > For the first milestone, the chairs believe there are two
> complementary drafts that together may meet the milestone.  These are:
> > draft-korhonen-behave-nat64-learn-analysis-
> 01<http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-
> analysis-01>
> > (-00 was presented last IETF, see minutes at
> http://www.ietf.org/proceedings/79/minutes/behave.txt)
> >
> >
> > http://tools.ietf.org/html/draft-wing-behave-dns64-config-02
> > (this was presented at IETF 77, see minutes at
> http://www.ietf.org/proceedings/77/minutes/behave.txt)
> 
> I don't think either of these drafts is quite there yet. They both
> discuss
> various solutions at some length, but neither of them is clearly
> proposing
> a single solution to the stated problem. draft-wing- does express a
> preference, but we haven't debated that.
>
> Have we even debated whether the solution must work properly with
> untouched RFC3484-conforming hosts? I'd be very hesitant about any
> solution that *requires* host updates.

In my mind, I view draft-wing-behave-dns64-config as solving the
problem when DNS is involved (that is, an application does a DNS 
query), and draft-korhonen-behave-nat64-learn-analysis as solving the
problem when DNS is not involved (that is, an application has an
IPv4 address literal).

draft-wing-behave-dns64-config suggests using an IPv4-mapped
IPv6 address as the first-priority DNS server.  I have not tested
many OSs with that configuration.  But it feels like it could work
pretty well.  The other techniques listed in 
draft-wing-behave-dns64-config are worse ideas, but listed for
completeness.  Those could be easily moved into an Appendix
or dropped from the document entirely.

> Also, I don't think either draft considers the case where a dual stack
> host receives a NAT64-based IPv6 address via an application layer
> referral,
> so that DNS is not part of the picture. Are we trying to solve that
> case too?

draft-korhonen-behave-nat64-learn-analysis tries to solve that case
where an IPv4 address literal is obtained, and an IPv6-only host
wants to use it.  It analyzes a bunch of techniques and at the
end of the last IETF meeting we reached a rough consensus similar
to what Teemu just posted at
http://www.ietf.org/mail-archive/web/behave/current/msg09196.html,
namely that we use a heuristic for our immediate needs (doing a 
DNS query of a special name) and we build a standard for longer 
term (EDNS0).

> I think I'd rather see a new draft that contains only one solution. The
> existing
> drafts could then become informational background documents.
> 
> Don't we *also* need a solution to the main problem considered by
> draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but
> seems important.

Learning the NAT64's prefix is the only way to solve the referral 
problem, where an IPv6-only host gets an IPv4 address literal and
wants to communicate with that host.

-d

> > For the second milestone, there is:
> > http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01
> > (-00 was presented last IETF, see minutes at
> http://www.ietf.org/proceedings/79/minutes/behave.txt)
> 
> If the goal is Informational, this draft is a good one to adopt.
> 
>    Brian
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave