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

[Cameron Byrne <[e-mail]>]

On Feb 14, 2011 5:02 PM, "Dan Wing" <[e-mail]> wrote:
>
> > >>> 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).
> >
> > Fair enough, if there's consensus on that.
>
> There probably isn't.  I expect many people have not read the
> introduction of these two documents...  :-|
>
> Hopefully this thread will initiate some discussion, along the
> lines of "Yes, I have exactly that problem."
>
> We (Cisco) have recently been having a lot more conversations with
> operators that are wondering how to build a network comprised of
> both IPv6-only hosts (which use a NAT64) and dual-stack hosts (which
> might use a NAT44), so that the dual-stack hosts don't put traffic
> on the NAT64.  The working group has discussed this at meetings, but
> I don't recall much in-depth discussion on the mailing list.  My
> slides are at http://www.ietf.org/proceedings/77/slides/behave-12.pdf
> (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?
>

No. The network operator controls the DNS server and will provide dns64 as
needed. That is the simplest answer and therefore likely the best.

If, by design or not, a ds host gets dns64 not much is lost.  In the
networks where dns64 is most relevant nat44 is generally used as well.

Cb

> > > 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.
> >
> > Fair enough too, if there's consensus, but the document would have to
> > read more authoritatively than it does now.
>
> Point taken.  Editing now.
>
> > >> 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,
> >
> > Yes. I'm asking about the opposite case, where IPv6-only host A gets a
> > synthetic IPv6 address and passes it over to dual-stack host B. If we
> > do nothing, B will just use that IPv6 address as-is and the result is
> > either redundant translation, or failure, depending on the details.
> > Maybe there's nothing we can do for that case, in which case we should
> > document it and move on.
>
> If it can, Host A should un-do the synthesis for passing along the
> referral.  I don't know where that should be documented - grobj or
> in a behave spec?
>
> -d
>
> > 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/behave
> > >
> > >
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave