Review of 'draft-jiang-v6ops-incremental-cgn-02.txt'

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Below is my review of 'draft-jiang-v6ops-incremental-cgn-02.txt':

Fred
fred.l.templin@boeing.com

---

1) Section 1, second paragraph, the sentence beginning
"They are too complicated..." is meaningless unless it
were to name specific transition mechanisms within specific
deployment scenarios. For example, perceived complications
may only be relevant when necessary network-supporting
infrasturcture is missing. Suggestion is to rewrite the
paragraph as follows:

   "IPv4/IPv6 transition issues therefore become more critical
    and complicated for the soon-coming global IPv6 deployment.
    Host-based transition mechanisms alone may not be able to
    meet the requirements in all cases. Therefore, network
    supporting functions and/or new transition mechanisms
    with simple user-side operation are needed."

2) Section 1, paragraph 4, the final two sentences seem to
imply that DSLite requires the ISP to upgrade its network
to IPv6, but that is incorrect. DSLite can operate as
IPv4-in-IPv6-in-IPv4 encapsulation, such that it can
operate over IPv4-only networks as long as the CPE and
CGN are dual-stacked. These two sentences need to be
corrected to reflect this.

3 Section 2.1, the sentence: "The integration of NAT-PT
is out of scope for this document." should be changed
to: "The integration of such mechanisms is out of scope
for this document."

4) Section 2.2, sentence beginning "Other tunneling
mechanisms..." should read:

  "Other tunneling mechanisms such as 6over4 [RFC2529], the
   Intra-Site Automatic Tunnel Addressing Protocol [RFC5214]
   and Virtual Enterprise Traversal (VET) [VET] are also
   considered."

5) Section 2.6, bring back text removed from the -01 in a
slightly modified form as follows:

  "However, for IPv6 traffic, a user behind the DS HG will
   see normal IPv6 service. It is therefore recommended that
   all IPv6 tunnels support an MTU of at least 1500 bytes,
   to ensure that the mechanism does not cause excessive
   fragmentation of IPv6 traffic nor excessive IPv6 path
   MTU discovery interactions."

6) Section 3, first part of first sentence, change to:
"If the core network transitions to IPv6,".

7) Section 3, paragraph 3 - same comment as 2) above. DSLite
does not require an IPv6-only ISP network, and can run as
IPv4-in-IPv6-in-IPv4 in an IPv4-only ISP network in which the
CPE and CGN are both dual-stacked. The advantages of using
DSLite over v4-v4 NATing are that the CPE can use traffic
engineering and ingress filtering by selecting specific CGNs
through which to direct their traffic. This requires only
that the CPE be able to discover the addresses of CGNs in
the operator network. That process can be coupled with the
ISATAP/VET Potential Router List (PRL) discovery mechanisms,
in which case the CGN would be co-resident with an ISATAP/VET
router that terminates IPv6-in-IPv4 intra-site tunnels.

8) Section 3.1, end of final sentence of first paragraph
says: "so we refer to it non-specifically" but then names
a specific service. To keep the sense of the sentence,
it would have to be changed to: "so we refer to it
non-specifically as "NAT64"." (i.e., and remove the
specific citation). I am open to other suggestions.