[apps-discuss] APPSDIR review of draft-ietf-behave-64-analysis-05

S Moonesamy <sm+ietf@elandsys.com> Thu, 16 February 2012 19:48 UTC

Message-Id: <6.2.5.6.2.20120216094738.08f96280@elandnews.com>
Date: Thu, 16 Feb 2012 11:47:30 -0800
To: apps-discuss@ietf.org, draft-ietf-behave-64-analysis.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: behave@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-behave-64-analysis-05
Precedence: list

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-behave-64-analysis-05
Title: Analysis of Stateful 64 Translation
Reviewer: S. Moonesamy
Review Date: February 16, 2012

Summary: This draft is almost ready for publication as an Informational RFC.

This draft evaluates how the new stateful translation mechanisms 
avoid the problems that caused the IETF to deprecate NAT-PT.  It 
discusses about problems identified in RFC 4966.  There is an 
analysis about an application protocol (FTP) in Section 
2.2.  Applications are mention in several places.  I did not find any 
application issues.

Major issues:

None.

Minor issues:

In Section 2.2:

      "Analysis: This is not specific to NAT64 but to all stateful
           NAT flavors.  The presence of single point of failures is
           deployment-specific."

Wouldn't the anchoring of flows create a single point of failure?

      "Actually, this is not a limitation of 64 (or even NAT-PT) but
       a deployment context where shared IPv4 addresses managed by
       the NAT64 are not globally reachable."

What is meant by "shared IPv4 addresses" in this context?

In Section 2.3:

    "Application clients (e.g., VPN clients) are not aware of the
     timer configured in the NAT device.  For unmanaged services, a
     conservative approach would be adopted by applications which
     issue frequent keepalive messages to be sure that an active
     mapping is still be maintained by any involved NAT64 device
     even if the NAT64 complies with TCP/UDP/ICMP BEHAVE WG
     specifications."

I suggest point to the relevant IETF specifications.  For what it's 
worth, this draft becomes an IETF specification instead of a WG 
specification once it is published as a RFC.

   "Address persistence can be therefore easily ensured by the
    NAT64 function (which complies with BEHAVE NAT recommendations
   [RFC4787][RFC5382])."

I recommend against writing a draft from a working group perspective 
unless it is meant for IETF consumption only.

In Section 5:

    "This document does not specify any new protocol or architecture.  It
     only analyzes how BEHAVE WG 64 documents mitigate concerns raised in
     [RFC4966] and which ones are still unaddressed."

 From Section 1.1, I am given to understand that there are references 
to mechanisms defined in the RFCs mentioned in that section.   There 
isn't any mention of BEHAVE WG 64 documents.  I suggest referencing 
the documents.

There is a normative reference to RFC 2766, which is Historic.

Nits:

The Requirements language section is oddly placed.

In Section 2.3:

  "Creation of a DoS (Denial of Service)"

That could be "Creation of a Denial of Service (DoS)".

Some of the informative references are out of date.

Regards,
S. Moonesamy

[apps-discuss] APPSDIR review of draft-ietf-behav… S Moonesamy
Re: [apps-discuss] APPSDIR review of draft-ietf-b… S Moonesamy
Re: [apps-discuss] APPSDIR review of draft-ietf-b… mohamed.boucadair
Re: [apps-discuss] APPSDIR review of draft-ietf-b… mohamed.boucadair