An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
RFC 6264

Note: This ballot was opened for revision 03 and is now closed.

(Jari Arkko) (was Discuss) Yes

Comment (2010-12-16)
No email
send info
The document says nothing of prefix delegation. Maybe it should, or
should at least point out that discussion about prefix delegation
can be found in several of the references.

The document says:

   For dual-stack ISP networks, dual-stack home gateways can
   simply switch off the v6-over-v4 function and forward both IPv6 and
   IPv4 traffic directly while the dual-stack CGN only keeps its v4-v4
   NAT function. This approach is considered an unlikely choice, since
   we expect ISPs to choose the approach described as incremental CGN
   here because they want to avoid or are unable to complete dual-stack
   deployment completely.

This text is somewhat confusing. I *think* you are saying that you can
do all this in dual stack ISP network, but that if you were adopting
this specification to begin with you did not have a dual stack network.
Please clarify/rewrite, and make sure that the document does not seem
to recommend against deploying dual stack ISP networks...

Ari Keränen had these questions:

1. Introduction

    A smooth transition mechanism is also described in this document. It
    introduces an integrated configurable CGN device and an adaptive HG
    device. Both CGN and HG are re-usable devices during different
    transition periods. It avoid potential multiple upgrade.

What does the last sentence mean?

2. An Incremental CGN Approach

    Most consumers remain primarily IPv4.

Should that be, e.g., "Most consumers remain primarily in IPv4-only 

2.4. Behavior of Dual-stack CGN

    When a dual-stack CGN receives a data packet from a dual-stack home
    gateway, it firstly checks whether the packet is a normal IPv4 packet
    or a v6-over-v4 tunnel packet.

How is this check performed? And what if the host (i.e., not the HG) is 
using some v6-over-v4 mechanism; would that cause problems with the check?

(Ron Bonica) Yes

(Stewart Bryant) No Objection

Comment (2010-12-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
ISPs facing only one pressure out of 
   two could adopt either CGN (for shortage of IPv6 addresses) 

Do you mean "shortage of IPv4 addresses"? 


Modified GRE 
   [RFC2784] with additional auto-configuration mechanism is also 
   suitable to support v6-over-v4 tunneling.

Do you mean "modified GRE" in which case how is it modified, or do you mean GRE supplemented by a signalling protocol to set up tunnels?


The security text on tunnel security seems a little light. If the ISP is going to consider the tunnel as own infrastructure and not needing to be policed, the ISP needs to consider policing those tunnel endpoint addresses at the boundary of the network.
When an ISP decides to switch from incremental CGN to DS-Lite 
   CGN, it may be that only a configuration change or a minor software 
   update is needed on the CGNs. The home gateway can then detect this 
   change and switch automatically to DS-Lite mode.  

This seems very speculative

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2010-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
An important document; thank you.

I found a few nits you might want to try to fix along the way.


Section 1

   Based on this fact, the Internet industry appears to 
   have reached consensus that global IPv6 deployment is inevitable and 
   has to be done expediently.

Do you mean "it is expedient" or "it has to be done expeditiously"?               

"CPE" needs to be expanded on first use.


It seems (to me, and from the usage made in the document) capriscious
that 5969 should be a normative reference, but 5569 informational.


Section 2.2

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

The passive voice is to be avoided!                                                  
By whom are these other tunneling mechanisms considered, to what end,
and with what result?


Section 2.4

   When a dual-stack CGN receives a data packet from a dual-stack home 
   gateway, it firstly checks whether the packet is a normal IPv4 packet 
   or a v6-over-v4 tunnel packet.

You need to say how it checks.

(Russ Housley) No Objection

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Sean Turner) (was Discuss) No Objection

(David Harrington) No Record

Comment (2010-12-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Please consider the points in the following TSVDIR review:


I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC if you reply to or forward
this review.


This draft proposes an incremental transition approach for IPv6 deployment
that combines CGN and other existing technologies such as v6-v4 tunneling,
dual stack home gateways.

Transport Issues:

This is an operational proposal to utilize existing proposal or methods
and no new protocols or technologies are proposed in the draft.
Hence, there is basically no transport related issue in the draft itself.

There may be a risk that combining multiple address-translation and tunneling
technologies cause new transport issue.
However, since the technologies used in the draft are deterministically selected
based on the source and destination addresses, I don't see any
conflicting case to
trigger such a risk.

Other minor comments::

1) Do you have any experimental results or feasibility studies for
this proposal?
   If so, please refer the information. It will be useful for readers.

2) What is normal IPv4 packet in section 2.4? I guess it means non-encapsulated
   packet, but using more specific words would be preferable.

3) In section 2.7, there are two "For IPv6 traffic, a user ..." lines.
   This seems to be an editorial mistake.

4) It would be preferable that you can elaborate why the transition from NAT444
   CGN or 6rd to the incremental CGN is easy in Section 3.

5) It is not clear to me when an ISP can decide to switch from incremental CGN.
   Does it require to update all network configurations and equipments
in the ISP?
   Or is it possible to do it gradually?

Yoshifumi Nishida