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

["Dan Wing" <[e-mail]>]

> >>> 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?

> > 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