[BEHAVE] Comments on draft-penno-behave-64-analysis

Dave Thaler <dthaler@microsoft.com> Sun, 07 November 2010 08:45 UTC

From: Dave Thaler <dthaler@microsoft.com>
To: "'behave' (behave@ietf.org)" <behave@ietf.org>, "draft-penno-behave-64-analysis@tools.ietf.org" <draft-penno-behave-64-analysis@tools.ietf.org>
Thread-Topic: Comments on draft-penno-behave-64-analysis
Thread-Index: Act+Ur2LD4pw0u0CRYmezV+vr4ZxPA==
Date: Sun, 07 Nov 2010 09:18:36 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF6534369A13@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [BEHAVE] Comments on draft-penno-behave-64-analysis
Precedence: list

Some comments:

1) I don't believe an analysis document should define new terminology for
    technologies it's analyzing, but should rather use terms consistent with those 
    specifications.   I'm referring to "64 proposal" and "64".

2) Section 1.3 states that only IPv6-initiated communication is supported.
   This is incorrect.  IPv4-initiated communication is supported by either
   stateless translation or statically configured mappings.  These are supported
   in xlate and xlate-stateful, respectively.  The end of section 1.3 says that
   stateless is out of scope, but I would disagree with that scoping.

3) I believe section 2.1 would be better organized by being split into two
    subsections, one for things that are inherent, and one for things that
    are solvable but just aren't currently solved.   In the latter category, I'd
    put at least points 7 (multicast), part of 11 (IPsec), and 12 (addr selection),
    since all of those were proposed as things to solve during the recharter
    discussion.      This would then make the conclusions section (section 3)
    easier to write and understand.

4) Point 12 of 2.1 states that scenarios 1 and 5 assume IPv6-only hosts.
    This is incorrect.   The host could be dual-stack with an IPv6-only application,
    or connected to an IPv6-only network, or whatever else.

5) Under point 11 of 2.1 I would expect to find a discussion of the applicability
    of RFC 3948 in a NAT64 scenario.   For example, does it work as is or is
    there a gap?

6) Re Point 2 of section 2.2: the analysis states that DNS64 does not resolve
    A queries since 64 assumes IPv6-only hosts.  This is incorrect on both counts.
    Also this point should be moved back into 2.1 (or the "not yet solved" portion
    if it's split into two).

7) Regarding section 2.3, I think structurally speaking it would be more clear 
    to fold the first paragraph back into section 1.1, and then add points 1 and
    2 back into section 2.2.

8) Section 2.3 point 1 analysis assumes, without saying so, that there is no NAT44
    LSN on the IPv4 side of the NAT64  (i.e., not NAT644).  Such an assumption 
    may or may not be valid.

9) Section 2.3 point 2 states that NAT64 complies with "most" behave NAT
    recommendations.    Why isn't it "all"?  Which does it not comply with?

10) The table claims to "summarize" the conclusions based on the analysis.
   However, a bunch of cells contain a value that was not discussed anywhere
    in the analysis and hence it does not "summarize".   Furthermore without
    such a discussion many of the cells are also ones with which people may
    disagree.  I would recommend simply removing the table, as I think getting
    consensus on the table would be too difficult/time-consuming and it isn't
    really central to the object of the document.

11) Remove any uncited references (or cite them).  E.g., 
    [I-D.wing-softwire-port-control-protocol].

12) In section 1.1, the title listed for ietf-behave-v6v4-xlate-stateful
      is incorrect (missing "Stateful").

-Dave

[BEHAVE] Comments on draft-penno-behave-64-analys… Dave Thaler