Re: [BEHAVE] Fwd: I-D Action:draft-korhonen-behave-nat64-learn-analysis-01.txt

[Cameron Byrne <[e-mail]>]

"Firstly, finding out whether a particular address is synthetic and
   therefore learning the presence of a NAT64.  For example, a Dual-
   Stack (DS) host with IPv4 connectivity could use this information to
   bypass NAT64 and use native IPv4 transport for destinations that are
   reachable through IPv4.  We will refer this as 'Issue #1' throughout
   the document."

Do we believe this will be a common case, where there is a dual-stack
network with DNS64 in it?  It is not covered in
draft-ietf-behave-v6v4-framework or
draft-arkko-ipv6-transition-guidelines.  Not to say it won't happen,
but is this design that is likely to happen and needs consideration
here?

Section 3 references SDP and SIP using IP literals, they may also use
FQDNs, so they may not be the best example.  In this sense, they are
just like HTTP or FTP, which may use literals and FQDNs.

I am not sure what issue #5 is.  Can you provide more clarification?
I plan on having many NSPs in my network, but i plan on users only
have a view of one.  AFAIK, NSP = PREF64, and there is a tight
coupling of PREF64 and NAT64 system. So, there  is a tight coupling
between NSP and a NAT64 system.  The load balancing i prefer is based
on the DNS64 having access to multiple NAT64 systems for load
balancing traffic to them via control of the NSP/PREF64 that a client
has access to.  But, there is a requirement that the client alway have
the same NSP/PREF64 so that the users has a "sticky" public IP that
represents the IPv6 client via the NAT64 to the IPv4 internet.  Things
break when the user is represented by multiple public IPv4 address
across TCP sessions (VPNs ....)

I prefer "4.3.  DNS Query for a Well-Known Name" since it can be
deployed today.  A lot of the appeal about DNS64 and NAT64 is that end
systems don't have impacts and the solution can be gracefully put in
place without much fiddling or new standards work.  I believe the
EDNS0 solutions require modifying the end systems and thus spoils some
of the benefits of the NAT64 based solutions.

Another option not captured is the manual PREF64 configuration.  The
NAT46 implementation here uses that today

http://code.google.com/p/n900ipv6/wiki/Nat64D

Generally for this solution of dealing with literals, it is perhaps
beneficial to state some guidance that the application can just
attempt to use the WKP if nothing else works.  I think it is also
reasonable to have guidance that /96 NSP prefixes will be easier to
derive with the heuristic method and therefor network operators should
generally use them as opposed to the other size prefixes.

Cameron