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

[Brian E Carpenter <[e-mail]>]

On 2011-02-15 12:58, Dan Wing wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Brian E Carpenter
>> Sent: Monday, February 14, 2011 12:29 PM
>> To: Dave Thaler
>> Cc: 'behave' ([e-mail])
>> 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).

Fair enough, if there's consensus on that.
> 
> 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.

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

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