Subject: [Gen-art] Gen-art LC review of draft-ietf-v6ops-nat64-experience-09

From: Elwyn Davies <[email-masked]>
Date: Tue, 28 Jan 2014 23:25:41 +0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-v6ops-nat64-experience-09.txt
Reviewer: Elwyn Davies
Review Date: 28 January 2014
IETF LC End Date: 28 January 2014
IESG Telechat date: (if known) -

Summary:
Not ready.  This document needs a serious rewrite with the assistance of 
a mother tongue English speaker.  I started doing some of this getting 
as far as s3.1.4, however I came to the conclusion that significant 
parts of the language were sufficiently unclear that I was unable to 
determine the intended meaning.  Accordingly I have abandoned the review 
and will have another go assuming a rewrite is done.  Please consider 
whether the title should be modified as noted below.

Major issues:

Minor issues:
Title:  The title is rather misleading since it the document actually 
documents two suggested ways of deploying NAT64 as well as experience of 
deploying these solutions. Maybe 'NAT64 Deployment Options and Experience'.

s1: A reference to explain what PDP context etc means in an LTE 
environment would be useful.

s3.1.3: It is stated that placing the NAT64 (middlebox) in a centralized 
location would 'reduce the diversity of  log format'.  I guess what is 
possibly being said that is that the network should preferentially use 
just one NAT64 box centrally placed rather than several (smaller) boxes 
at various edge locations.  I think this needs to be explained more 
clearly (assuming I have it right).  OTOH I would rather expect that 
most network owners would go for a single species of NAT64 box so the 
diversity of log formats is really a side issue.

s5.2: The problem here is not specifically geo-location - and since we 
normally don't have any mapping between topology and location this seems 
inappropriate - but doing host identification (which is what RFC 6967 is 
about.  Shouldn't this section just be about host identification?

s8, para 2:
> We configure ULAs as NAT64 prefixes on a NAT64-CGN.
So.. is this a mandatory requirement or just a possibility?

Nits/editorial comments:

s1, para 1: s/Internet/the Internet/

s1, para 2: s/simplify networks provisioning/simplify the provisioning 
of networks/, s/confers some benefits to/confers some benefits on/, 
s/such mobile/such a mobile/, s/if Long Term/if a Long Term/

s3.1.1: s/can be seen with better transparency features/can offer 
improved transparency to <state who or what is offered the improved 
transparency> /

s3.1.1: Expand A+P abbreviation.

s3.3.1: s/IPv4 shortage/IPv4 address shortage/

ss3.1.2, 3.1.3 and 3.1.4: These are very long paragraphs.  It would be 
good to separate the various discussion points into separate paragraphs.

s3.1.2: "..to enable access of IPv4 only applications" Presumably this 
is access to applications running on the IPv4 side from applications on 
the IPV6 side... Suggest
"to allow applications running on the IPv6 network to interact with 
applications that can only use IPv4 communications or IPv6 applications 
that need to communicate using literal IPv4 addresses."

s3.1.2: s/discover NAT64 prefix/discover the NAT64 prefix/

s3.1.2: need a reference for BIND.

s3.1.2: s/...(BIND) software supports the function./The ... (BIND) 
implementation of NAT64 supports this discovery function./

s3.1.2:s/Operators should not/Users should not/ perhaps.

s3.1.2: s/going to IPv4-only service/going to IPv4-only services/

s3.1.2: s/restrains NAT uses/restrains NAT usage/

s3.1.2: s/all traffic flows have to be traversed and translated./all 
traffic flows have to traverse the NAT44 middlebox and be translated there./

s3.1.2: s/may serve a double roles, i.e. a translator and IPv6 
forwarder./may serve a dual role acting as both translator and IPv6 
forwarder./

s3.1.2: s/Therefore, both IPv6 and IPv6

s3.1.2:
OLD:
In some sense, it encourages IPv6 transmission and restrains NAT uses 
compared to NAT44(if used), on which all traffic flows have to be 
traversed and translated. In some cases, NAT64-CGN may serve double 
roles, i.e. a translator and IPv6 forwarder. In mobile networks, NAT64 
is likely deployed as the default gateway serving for all the IPv6 
traffic. The traffic heading to a dual-stack server is only forwarded on 
the NAT64. Therefore, both IPv6 and IPv4 are suggested to be configured 
on the Internet faced interfaces of NAT64. We tested on Top100 websites 
(referring to [Alexa] statistics). 43% of websites are connected and 
forwarded on the NAT64 since those websites have both AAAA and A 
records. With expansion of IPv6 supports, the translation process on 
NAT64 will likely be faded. In addition, it should be noted the 
DNS64-DNSSEC Interaction[RFC6147] may impact the DNS64 process. For 
example, DNS64 will not work with the case, where there is a DNS query 
with the "DNSSEC OK" (DO) bit set and the "Checking Disabled" (CD) bit 
set received.
NEW:
In some sense, it encourages IPv6 transmission and restrains NAT usage 
compared to system using NAT44 (if used), on which all traffic flows 
have to traverse the NAT44 middlebox and be translated in passing. In 
some cases, NAT64-CGN may serve a dual role as both translator and IPv6 
forwarder. In mobile networks, NAT64 is likely deployed as the default 
gateway serving all the IPv6 traffic. The traffic heading to a 
dual-stack server is only forwarded via the NAT64. Therefore, it is 
suggested [or may be RECOMMENDED] that both IPv6 and IPv4 are configured 
on the Internet facing interfaces of NAT64 middleboxes.  We tested the 
configuration of the Top100 websites (as identified in the [Alexa] 
statistics).  43% of websites are [Should this be "would be"] connected 
and forwarded via NAT64 since those websites have both AAAA and A 
records. With the expansion of IPv6 support, the need for the 
translation process on NAT64 middleboxes will likely diminish. In 
addition, it should be noted that the interaction of DNS64 and DNSSEC 
[RFC6147] may impact the DNS64 process. For example, DNS64 will not work 
in the case where a DNS query is received that has the "DNSSEC OK" (DO) 
bit set and the "Checking Disabled" (CD) bit set.

s3.1.3: s/is problematic from multiple-vendor's equipment due to 
inconsistent formats of log records./obtained from equipment supplied by 
multiple vendors may be problematic due to inconsistent log formats./

s3.1.3: This gave me a bit of a laugh...  So having got over my unstable 
user experience (probably due to excessive consumption of beer..)
OLD:
    Since the topology on each
    path is different, it may cause unstable user experiences and some
    degradation of Quality of Experience (QoE) when fallback to the other
    protocol is not powerful enough.
NEW:
    Since the routes taken by the two traffic sets may be different, 
user experiences
    may be inconsistent and there may be some
    degradation of Quality of Experience (QoE) when fallback to the other
    protocol is not sufficiently rapid. [or does this mean that the 
alternative route
    doesn't have enough capacity]

Please clarify.

[I gave up on language corrections at this point as it essentially needs 
a serious rewrite.]

s4.1, last para: Specifying 91.21% of traffic seems inappropriately exact.

s6.1:  It may well be that NAT64-CGN have an FTP ALG .. given the 
general view that FTP shouldn't be used it seems peculiar that this is 
the only default implementation!
Perhaps a comment about this (and maybe even TURNING OFF the FTP ALG) 
seems like an option.