[v6ops] comments on draft-ietf-v6ops-nat64-experience

[Lee Howard <[e-mail]>]

Please define the acronym NAT64-FE.  "Front End"?  "Functional
Equivalent"?  "Fire Engine"?

Clarify this sentence:  Some failure cases may be occurred once NAT64
serves
   a IPv6 gateway while is configured only with IPv4 on WAN links.
What is an "IPv6 gateway"?  Is that "IPv4 on WAN links" on the gateway, or
on the NAT64 server?
I can't quite picture the topology being described in this example.

I'm not sure you've made this point:
  It's desirable to find the solutions that will
  allow introducing IPv6/IPv4 translation service to IPv6-only hosts
  while keeping dual-stack hosts unaffected and IPv4 service unchanged.
I think what you want to say is that it's preferable to have at least one
address family accessible via native service, when possible.  If you want
to say that IPv4 service should remain unchanged, and that IPv6 hosts
should use NAT64, I would not agree with that.  I don't think that's
consistent with the rest of the draft, either.  Since this section is
about the coexistence of NAT44 and NAT64, and the previous sentence is how
hard it is to troubleshoot, maybe you want to say more about how to find
the solutions that will facilitate the best network.  That might mean
having both, but upgrading hosts aggressively to support IPv6-only, and
making sure native IPv6 was available.

I'm not sure where you want to put it, but another NAT64-FE consideration
is the use of x-forwarded-for header.  A load balancer using an IPv4 VIP
may be used to sending an IPv4 x-forwarded-for.  A front-end server used
to that has no problem, but the server, logs, or log parsing tools (rDNS
looking, whois) may be affected by seeing an IPv6 address when they're
used to seeing IPv4.  This is related, but not the same, as the
geo-location issue.

I don't like the use of IPv6 subdomains beyond the testing phase.  Nobody
will ever see it; you might as well not have a AAAA if you're only going
to public ipv6.example.com. It's fine to recommend it for testing, but
when ready for production, the same name should be available over A and
AAAA, and let the client choose the address family.

Section 4.1 is an excellent discussion of the pros and cons of each mode,
with supporting data.  It would be good to have a sense of the scale of
sync data for hot standby instances.

Section 5.1 needs some paragraph breaks.

Use of XFF header for geo-location would work if the server could parse
the original address out of the XFF header.
"Geo-location based on shared IPv4 address is rather inaccurate in that
case."  Depending on the geographic range of the NAT64.  A NAT64-CGN
covering a university or apartment complex, or even a small one covering a
neighborhood, may provide as much detail as in the old days.

I think the detail in Section 6.1 is pretty light.  I would expect that
the same things documented as problems in rfc7021 are also problematic in
NAT64-CGN.

These sentences:
  Operators may consider to add
  additional site-specific rows to the default table to steer traffic
  flows going through NAT64-CGN.  However, it involves significant
  costs to change terminal's behavior.

I think you mean that operators might consider making changes to host
(client) behavior, but I wasn't clear on the first couple of readings
whether we were talking about host address selection or routing somehow.

Based on the above, I think this document needs another rewrite, but is
good.

Lee