Subject: Re: [BEHAVE] adoption of learn analysis and DNS-based NAT64 prefix discovery

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 May 2011 13:58:21 -0700

Based on the in-room consensus at IETF80 and one 'yes' on the list, I will
ask the authors to submit the documents as BEHAVE working group items.

-d

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Thursday, May 05, 2011 6:10 PM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked]'; 'behave-
> [email-masked]'
> Subject: adoption of learn analysis and DNS-based NAT64 prefix
> discovery
> 
> At IETF80, we appeared to have reach regarding BEHAVE's milestone "Apr
> 2011 - Submit to IESG: avoiding NAT64 with dual-stack host for local
> networks (std)".  Excerpt from the minutes is below.  Under this
> milestone, it seems valuable to publish two documents:  one which
> analyzes the various approaches, and another that details the specific
> recommended approach.
> 
> To that end, please provide feedback to [email-masked] on adopting the
> following two documents as working group documents:
> 
> 1.  draft-korhonen-behave-nat64-learn-analysis, to be informational
>     http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-
> analysis-02
> 
> 2.  draft-savolainen-heuristic-nat64-discovery, likely to be standards
> track
>     or possibly informational
>     http://tools.ietf.org/html/draft-savolainen-heuristic-nat64-
> discovery-01
> 
> Thanks,
> -d
> 
> -----
> 
> http://www.ietf.org/proceedings/80/minutes/behave.txt
> 
> ...
> Avoiding NAT64 with dual-stack host for local networks (Jouni Korhonen)
>        draft-korhonen-edns0-synthesis-flag
>        draft-savolainen-heuristic-nat64-discovery
>        draft-korhonen-behave-nat64-learn-analysis
>        milestone date: April 2011
> 
> Dan Wing: Should we use DNS well-known-name (hack) or the ENDS0 option
> (more elegant)
> 
> Andrew Sullivan: Are there implementations of NAT64 that don't
> currently implement the ENDS0 option?
> 
> Mark Andrews: BIND does not currently have the ENDS0 option but could
> easily add it
> 
> Andrew Sullivan: Needs to be done quickly
> 
> Matthew Kaufman: What about client resolver APIs that don't support
> getting to the EDNS0 option?
> 
> Stuart Cheshire: What software needs to learn the prefix? Client DNS
> resolver, or other application software?
> 
> Dave Thaler: Other application software.
> 
> Stuart Cheshire: Then the resolver API limitation might be a problem.
> 
> Andrew Sullivan: Standardizing a DNS well-known-name will be an uphill
> struggle
> 
> Andrew Sullivan: We should pick one and do it, not both.
> 
> Dave Thaler: If DNS well-known-name, we need to decide if it's a single
> global well-known-name, or per-operator, or per vendor?
> 
> Matthew Kaufman: This will happen. Better to synthesize locally than to
> store in the DNS far away.
> ...
> 
>