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

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Feb 2014 15:12:03 +0100

Thanks for the review, Elwyn. Joel, Fred, authors, any comments on this?

Jari

On Jan 29, 2014, at 12:25 AM, Elwyn Davies <[email-masked]> wrote:

> 
> 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.
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Feb 2014 09:46:53 -0500

Elwyn:

Nice review.  I'm sure the document will be improved because of your efforts.  I'd like to make two comments.

> 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 p…

In the beginning, yes.  Subsequent procurements cal lead to changing vendor.  Mergers also lead to multiple venders.

> 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…

If a law enforcement agency shows up with a subpoena, they really do want to know what door to knock down.

Thanks for listening,
  Russ

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Feb 2014 17:56:41 +0100

FWIW, I have now done my own review. I think there are language issues, but they do not prevent going forward. Language itself will be fixed by the RFC Editor. I'm more interested in cases where there might be an semantics unclarity issue. 

I think it would be beneficial to go through each of the comments before final approval of the document.

With that in mind, going through some of my own and Elwyn's comments:

>    o  Operators who adopt NAT64-FE may leverage the application layer
>       proxies, e.g. X-Forwarded-For (XFF)
>       [
> I-D.ietf-appsawg-http-forwarded
> ], to convey the IPv6 source
>       address in HTTP headers.  

I'd say … may leverage application layer proxies, and those may use additional attributes such as X-Forwarded-For ...

> Those messages would be passed on to
>       web-servers.  The log parsing tools are required to be able to
>       support IPv6 and may lookup Radius servers for the target
>       subscribers based on IPv6 addresses included in XFF HTTP headers.
>       XFF is the de facto standard which has been integrated in most
>       Load Balancers.  Therefore, it may be superior to use in a NAT-FE
>       environment.  In the downsides, XFF is specific to HTTP.  It
>       restricts the usages so that the solution can't be applied to
>       requests made over HTTPs.  This makes geo-location problematic for
>       HTTPs based services.
> 

Not sure we should call something a de facto standard while pointing to a draft. I'd just say "… has been implemented in many …"

> The experiences of some
>    applications are still align with [
> RFC6586]. 

Not sure what this means.

> |  SIP-VoIP      |Fail, due to the lack of NAT64 traversal            |
> 

Did you mean ALG? Not sure what this would mean otherwise.

>> 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 Op…

I think that is a reasonable suggestion.

>>  doesn't have enough capacity]

Yes, that would be better.

Jari

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 20 Feb 2014 18:54:52 +0000

I appreciate the review. I disagree that it needs a complete rewrite, but I agree that language work would be beneficial. I do believe that the RFC Editor will have an unusual level of changes, due to language issues.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Feb 2014 08:42:49 +1300

On 21/02/2014 05:56, Jari Arkko wrote:
...
> Not sure what this means.

I assume it's a polite way of saying "As expected, a bunch
of applications don't work properly." Actually I don't think
it's a service to the community to say this indirectly -
anybody proposing to put users behind NAT64 needs to be well
informed about the FAILs.

     Brian

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 21 Feb 2014 01:12:25 +0000

On Thu, 2014-02-20 at 09:46 -0500, Russ Housley wrote:
> Elwyn:
> 
> Nice review.  I'm sure the document will be improved because of your
> efforts. 
:-)

 I'd like to make two comments.
> 
> > 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.
> 
> In the beginning, yes.  Subsequent procurements cal lead to changing
> vendor.  Mergers also lead to multiple venders.
For sure! And of course you then have to decide whether to modify the 
merged network to conform to the centralized location story.  A little
clarification is, I believe, needed to cover all the bases.
> 
> > 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?
> 
Maybe I'd prefer my operator not to know which door - with wi-fi
involved there is no guarantee which door the host is behind in any
case.  It's an interesting point that I had not thought about: Does my
ISP in the UK actually get to know whether the phone number I am paying
for service on is at the same address as on the bills?  Since I provide
my own modem and the ISP has, to the best of my knowledge, never been
near either my house or the exchange where my ADSL line terminates it
depends on whether BT checks the linkage and tells the ISP it is right.
It's so long since I signed up I have no idea what would have happened
if the addresses didn't match. Another PRIVACY issue!

/Elwyn

---

From: Jari Arkko <[email-masked]>
Date: Fri, 21 Feb 2014 13:32:40 +0100

Hi,

First: I cleared my discuss, so this document's progress is now up to you guys and Joel. Some further discussion inline:

> 4-02-21 0:56 GMT+08:00, Jari Arkko <[email-masked]>:
>> FWIW, I have now done my own review. I think there are language issues, but
>> they do not prevent going forward. Language itself will be fixed by the RFC
>> Editor. I'm more interested in cases where there might be an semantics
>> unclarity issue.
>> 
>> I'd say ... may leverage application layer proxies, and those may use
>> additional attributes such as X-Forwarded-For ...
> 
>> 
>> Not sure we should call something a de facto standard while pointing to a
>> draft. I'd just say "... has been implemented in many ..."
> 
> thank you for the suggestion. We will make following changes:
> 
> ==NEW
> 
>      proxies. Those may use additional attributes such as X-Forwarded-For (XFF)
>      [I-D.ietf-appsawg-http-forwarded] to convey the IPv6 source
>      address in HTTP headers.  Those messages would be passed on to
>      XFF has been implemented in most Load Balancers.  Therefore,
>      it may be superior to use in a NAT-FE

OK

> Several applications don't work properly as described in the RFC6585.

If you use that text, then it would be fine.

> I mean ICE is recommended to be supported in order to avoid SIP-ALG.
> After the discussion with Dan Wing, resorting to SIP-ALG for
> supporting IPv4-IPv6 inter-working is not preferred.

Ok. Please elaborate, because the text was unclear to the reader.

Also, I think you should go through Elwyn's comments and see if you make improvements.

Jari

---

From: GangChen <[email-masked]>
Date: Fri, 21 Feb 2014 17:14:24 +0800

Hi Elwyn,

Thank you for the comments.
I apologize for the late reply due to some personal reasons.
Please see my reply inline.

2014-01-29 7:25 GMT+08:00, Elwyn Davies <[email-masked]>:
> 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.

I'm an ESL person. I have incorporated editorial suggestions from the
kind working group. We could improve the writing quality with your
comments.

> 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'.

I agree with your comments that the title is more accurate as "NAT64
Deployment Options and Experience".

> environment would be useful.

 As stated in RFC6459,
 "A Packet Data Protocol (PDP) context is the equivalent of a
 virtual connection between the User Equipment (UE) and a PDN using
 a specific gateway."

We could add the reference of RFC6459 when the PDP is first shown in the draft.

> 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.

Your understanding is correct. One single species is desirable.
A centralized NAT64 box is easier for operators to just use a single species.

we will make following changes:

===OLD

   It has been observed that the
   process of correlating log information is problematic from multiple-
   vendor's equipment due to inconsistent formats of log records.
   Placing NAT64 in a centralized location may reduce diversity of log
   format and simplify the network provisioning.

===NEW

   It has been observed that the
   process of correlating log information is problematic from multiple-
   vendor's equipment due to inconsistent formats of log records.
   Placing NAT64 in a centralized location may be beneficial
   to operators to use a single species of NAT64 that reduces diversity of log
   format and simplify the provisioning of networks.

> 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?

There are some use cases to determine user's location depending on
IPv6 address, for example lawful interception and navigation services.
In my experience, the information of network topology and relevant
locations is required to be provided to lawful agency. Map apps can
also get user's location information in order to provide navigation
service. IPv6 is good for such usages, since it has global meaning.

> So.. is this a mandatory requirement or just a possibility?

It's just a possibility. It actually just describes a test which
evaluates the impact of using ULA.

> 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> /
>
> 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/...(BIND) software supports the function./The ... (BIND)
> implementation of NAT64 supports this discovery function./
>
> 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./
>
> 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./

Thank you for the detailed suggestion. I have already updated my local
copy with your suggestion. It will be updated along with new editorial
improvement.

> 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:

It means the alternative route may have less capacity or lower speed.

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

The discussion in the wg encourage us to share the concrete data for
the statement.
The statistic is also verified by several mobile operators.

> 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!

The recommendation of avoidance of FTP-ALG use align with RFC6384.

Best Regards

Gang

---

From: GangChen <[email-masked]>
Date: Fri, 21 Feb 2014 17:27:08 +0800

2014-02-20 22:46 GMT+08:00, Russ Housley <[email-masked]>:
> efforts.  I'd like to make two comments.
>
>> 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.
>

The procurement for more capacity of equipment(e.g. add board card)
still could avoid multi-vendor coordination. The procurement for new
equipment leads multiple vendor. However, it earns the time to improve
implementation.

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Fri, 21 Feb 2014 17:59:15 +0800

Hello Jari,

Thank you for the comments. Please see my reply inline.

==NEW

BRs

Gang

>>> 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
>>> 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.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
>>> 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
>>> 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:
>>> 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
>>> 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
>>> 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.
>>>
>>>
>>> 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!

---

From: joel jaeggli <[email-masked]>
Date: Fri, 21 Feb 2014 07:14:35 -0800

> First: I cleared my discuss, so this document's progress is now up to you guys and Joel. Some further discussion inline:

related to this, I'd like one more pass through the source document
before we send it to the rfc editor. if you can drop me a copy after you
cleared the genart comments but before we post it that would be appreciated.