[v6ops] <draft-ietf-v6ops-464xlat-optimization-00.txt> - pre-(shepherd-writeup) review

[Jen Linkova <[e-mail]>]

OK, I"ve read the document and before I finish the write up I'd like
to discuss a number of comments I have.
My apologies for not raising them during the WGLC - I was not paying
attention, got busy with work...

0) I might need coffee but I found the Abstract a bit confusing so if
I may suggest some text..

""IP/ICMP Translation Algorithm (SIIT) can be used to provide access
for IPv4-only devices or applications to IPv4-only or dual-stack
destinations over IPv6-only infrastructure. In that case the traffic
flows are translated twice: first from IPv4 to IPv6 (at the ingress
point to then IPv6-only network) and then from IPv6 back to IPv4 at
the egress point.  If the destination is IPv6-enabled that second
translation might not be required. This document describes some
optimization to 464XLAT and MAP-T deployments to avoid translating IP6
flows back to IPv4 if the destination is reachable over IPv6. The
proposed solution would significantly reduce the NAT64 utilisation in
the operator's network"

1) Introduction section
The draft says: "allow IPv4-only devices or applications to connect
with IPv4 services in Internet, by means of a
   stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described
by  [RFC7915]."

Do you think it would help saying  "with IPv4 services in Internet
over IPv6-only infrastructure"?  Otherwise it sounds confusing - why
do we need anything at all to help IPv4-only clients to talk to
IPv6-only services?

2) ""This allows to translate the IPv6-only flow back to IPv4, in
order to forward it to Internet."

I'm not sure we can call a flow 'IPv6-only'. Flows are usually IPv6 or
IPv4...I think the terms 'IPv6-only' and 'IPv4-only flows' are used
extensively in the draft.

3) "In both cases (NAT46 and NAT64), the translation of the packet
   headers is done using the IP/ICMP translation algorithm defined in
   [RFC7915] and algorithmically translating the IPv4 addresses to IPv6
   addresses following [RFC6052]."

IMHO this text would be more readable if we split it in two sentences:
" In both cases (NAT46 and NAT64), the translation of the packet
   headers is done using the IP/ICMP translation algorithm defined in
   [RFC7915] . Translation between IPv4 and IPv6 addresses is done as
per RFC6052]."

4) Section 3 is called "Possible Optimisation". However it comes
before the Section 4 (problem statement) and the text seems to be more
about the problem.
Also, the first 3 paragraphs of Section 4 (until "until "As shown in
the Figure 4" text) seem to repeat Section 3. Shall those two sections
be merged?
Or am I missing anything and they are actually talking about different things?

5) "In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge
of the synthesis of AAAA records from the A records, so they can use
   a NAT64, without the need of doing a double-translation by means of
   the NAT46/CLAT." - who are "they"?  This is the first sentence of
the section so not sure who you are referring to.

6) Fig 1: Shouldn't it be 'Dual-Stack LAN', not 'LAN's Dual-Stack'?

7) ""As it can be observed in the preceding picture, the situation is the
   same, regardless of in case of a wired network with a CE Router or a
   cellular network where a UE is connecting other devices (which may be
   IPv4-only or have IPv4-only apps), by means of a tethering
   functionality."

IMHO it's a bit hard to parse...Maybe smth like:
"Examples of a topology shown on the picture above includes:
- a residential ISP IPv6-only access network with a dual-stack LAN
behind a CPE performing NAT46 (CLAT);
- IPv6-only mobile ISP network when a UE performs CLAT for IPv4-only
applications running on that UE or for traffic originated by other
devices connected to the UE via tethering."

8) Section 5.1. Approach 1: DNS/Routing-based Solution
"5.1. Approach 1: DNS/Routing-based Solution
"Because the WKP is non-routable, this solution will only be possible
   if the CDN/cache is in the same ASN as the provider network, or
   somehow interconnected without routing thru" Internet."

Maybe it's worth explicitly mentioning that this approach would
require that the path to the destination is NOT traversing NAT64
devices. Otherwise the simple configuration of such devices 'translate
everything with the destination address in the WKP' would become much
more complex.

9) Section 5.2.3
""In normal conditions the TTL for both A and AAAA records, of a given
FQDN, should be the same,"

I'm not sure it's the case actually and we can expect that to happen
'normally'. Do you have any references proving that point?

10) Section 5.2.7. Behavior in case of multiple A/AAAA RRs
Sorry but I have difficulties understanding those two sentences. What
'existing procedures'  the resolver must be using?
IMHO this section would be much easier to understand if there is an
example: the given FQDN has 15 A RRs and 5 AAAA RRs. What EAMT entries
would be created?
As most CDNs would have multiple entries, this is a key point of the proposal.

11) Section 5.2.8. Behavior in presence/absence of DNS64
"Furthermore,  because as indicated in Section 5.2.2, the EAMT entry
is not created
   when the service is IPv6-enabled."

Is it correct? The section 5.2.2 seems to be talking about detecting
IPv6 enabled services and using their AAAAs for creating EAMT entries.

12)  (related to 11) The draft seems to assume that the CPE/UA knows
the NAT64 prefix somehow. As it's an operational document I believe it
would be beneficial to provide some guidance on how exactly the device
should discover the prefix. Obviously, the operator could use RFC8781
(PREF64 RA option) or PCE. Or the device and use RFC7050. However if
the device uses RFC7050 then the Section 5.2.8 shall discuss this.

13) IMHO sections 5.2.9.  Behavior when using literal addresses or non
IPv6-compliant APIs and 5.2.12. Behavior in case of Foreign DNS should
be follow each other or  sections 5.2.9. might have a reference to
5.2.12.

14) Section 5.2.11 Behavior in presence of Happy Eyeballs
IMHO, this section should make it explicit and very very clear: as
soon as an EAMT entry is created for an IPv4 address, Happy Eyeballs
fallback to that IPv4 address becomes impossible. In case of
connectivity issues with the IPv6 address used in that EAMT entry, the
client would not be able to reach the destination.
I feel like the draft does not discuss the impact enough.  It's not
about delay, it's about IPv6 becoming the only protocol to reach
IPv6-enabled destinations for both dual-stack and IPv4-only hosts.
Maybe it's a good thing in 2020 ;)

15) Later in that section the draft says:
" So even if Happy Eyeballs is present, the fallback to IPv4-only
typically, will be slower than native IPv6 itself, because
   the added delay in the NAT46+NAT64 translations, when not using this
   optimization."

I think it should be saying "IPv4 would be slower", not "fallback to
IPv4".  So maybe smth like " 'IPv4 is expected to be slower than
native IPv6 due to delays added by NAT46+NAT64. This optimization
reduced that delay by eliminating the need of the second translation
(NAT64)"?

16) The draft does not discuss the troubleshooting implication. For
example if I'm running 'traceroute 8.8.8.8 from my IPv4-only host and
there is an EAMT entry for 8.8.8.8.
IMHO this draft needs to discuss this and potential impact on tech
support procedures.

17) Another thing which seems to be missing is some guidelines on
controlling this feature. I'd suggest adding some text about that.
IMHO, the router vendors SHOULD (I'd vote for MUST even) have that
optimization disabled by default. The routers MUST have a knob to turn
it off if it's enabled.

18) Acknowledgements Section
Pls remove "....and TBD".

-- 
SY, Jen Linkova aka Furry