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

From: Lee Howard <[email-masked]>
Date: Fri, 01 Nov 2013 14:41:15 +0200

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

---

From: GangChen <[email-masked]>
Date: Mon, 4 Nov 2013 08:41:39 +0800

Hi Lee,

> Equivalent"?  "Fire Engine"?

FE stands for "Front End". It has been defined in the abstract
session. I will add the definition
in the main body.

> I can't quite picture the topology being described in this example.

IPv6 gateway is the next hop for ::/0
When NAT64 is configured as the IPv6 gateway(that is the case in a
mobile network),
all the traffic heading to a dual-stack server will be transmitted
only on IPv6 path and forwarded on NAT64.
The topology looks like:

+----+           +------+         +-----------------+
|IPv6|-----------|NAT64 |-+-------|dual-stack Server|
+----+           +------+ |       +-----------------+
                          |       +-----------------+
                          +-------|IPv4 Server      |
                                  +-----------------+

If the interface on the left side of NAT64 only configured with IPv4,
the traffic going to the dual-stack server is likely failed.

> making sure native IPv6 was available.

The NAT64 is only for the case where there is an IPv6-only host
intending to connect with an IPv4-only server.
If the destination is IPv6-only server or dual-stack server, the
native IPv6 is always preferred.
In order to make this point, I will make following changes:

==OLD===

   It's also difficult for
   operators to debug the issue and make optimal resource usages on both
   NAT44 and NAT64.  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.

==NEW===

  It's also difficult for operators to find a solution to make a stable
  network with optimal resource utilization. In general, it's desirable
  to figure out the solution that will introduce IPv6/IPv4
  translation service to IPv6-only hosts connecting to IPv4 servers while
  making sure dual-stack hosts to have at least one address family accessible
  via native service if it's possible. With the end-to-end native IPv6
environment
  is available, hosts should be upgraded aggressively to migrate to IPv6-only.

> used to seeing IPv4.  This is related, but not the same, as the

(*)If an operator intend to use x-forwarded-for header for accurate
the geo-location,
I guess it's required that parsing tools should support/recognize ipv6 because
it depends on the parsing results. If the consumption is not able to achieve,
we may have to pick a solution from rfc6967.

> AAAA, and let the client choose the address family.

We will clarify that the subdomain recommendation is only for the
experimental phase.

> sync data for hot standby instances.

I will add concrete data for the sense of the scale of sync data.

> Section 5.1 needs some paragraph breaks.

this will done in the next update.

> the original address out of the XFF header.

Correct. that is the consumption, please also refer to (*) .

> the same things documented as problems in rfc7021 are also problematic in

good suggestion. We could add more testing data into this section.

> whether we were talking about host address selection or routing somehow.

we are indicating the additional row in the default policy table for
host address selection. For example, configure a high Precedence value
for a ULA prefix compared to ::ffff:0:0/96

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

Thank you for the detailed review. We will make another update
according to above comments.

BRs

Gang