Subject: [BEHAVE] behave-nat64-learn-analysis-00, issue #2

From: Michael Richardson <[email-masked]>
Date: Wed, 25 May 2011 17:02:09 -0400

Thank you for this document!

Change/add text:

   Secondly, finding out how to construct from an IPv4 address an IPv6
   address that will be routable to/by the NAT64.  This is useful when
   IPv4 literals can be found in the payload of some protocol or
   applications do not use DNS to resolve names to addresses but know
   the IPv4 address of the destination by some other means.  We will
   refer this as 'Issue #2' throughout the document.

to:

*  Secondly, finding out how, and if, to construct from an IPv4 address an IPv6
   address that will be routable to/by the NAT64.  This is useful when
   IPv4 literals can be found in the payload of some protocol or
   applications do not use DNS to resolve names to addresses but know
*  the IPv4 address of the destination by some other means.    Any host
*  which is using a local recursive resolver (such as to do provide
*  DNSSEC or due to split-horizon DNS) will want to do it's own DNS64
*  synthesis.  We will refer this as 'Issue #2' throughout the document.

I think that section 3 lists DNSSEC as one of the first items, but until
I got there I couldn't be sure if it was in fact part of issue #2.

Change:

   Issue #4
      The problem of supporting changing NSP.  The NSP learned by the
      host may become stale for multiple reasons.  For example, the host
      might move to a new network that uses different NSP, thus making
      the previously learned NSP stale.  Also, the NSP used in the
      network may be changed due administrative reasons, thus again
      making previously learned NSP stale.

to:

   Issue #4
      The problem of supporting changing NSP.  The NSP learned by the
      host may become stale for multiple reasons.  For example, the host
*     might move to a new network that uses different NSP (or which 
*     provides no NSP), thus making the previously learned NSP stale.
      Also, the NSP used in the network may be changed due
      administrative reasons, thus again making previously learned NSP stale.

====

section 4.1.2:
   - fails if a host is doing .-anchored recursive lookups.
   - mobile and DNSSEC-aware hosts are much more likely to do this.
   - It's not that the host is "Issue #3", it uses DNS, but it doesn't
     use the DNS server that the "ISP" tells them to use.

section 4.2 duplicate of section 4.1?

section 4.5, wing-behave-learn-prefix's U-NAPTR solution seems like a
        very good solution, but requires that the ISP have reverse DNS.
        (mentioned in CONs.  But, I note that if the DNS64 machine is
        actually the one queried and DNSSEC is not validated, then 
        it does not require the reverse zone to actually be properly
        delegated)

section 4.7, RA-Learn-Prefix is, I think, a MUST for the future. 
        It's the architecturally sensible solution.

section 5, I don't understand how a local DNSSEC recursive resolver
        works if Issue #3 is not solved.  Such a host does not, from
        the point of view of the DNS64, "use DNS".