An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
draft-ietf-v6ops-incremental-cgn-03

[Ballot comment]
This seems like a perfect document for Experimental.  Running an experiment while we work through the
security issues seems like a nice lead-in to an informational or standards track specification.  The current
spec doesn't feel fully baked (esp with respect to security) imho.

[Ballot comment]
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
networks"?


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?

[Ballot discuss]
This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time).

The security considerations include the following two statements:

Further security analysis will be needed to understand double NAT security issues and tunnel security issues.

and

[RFC4891] describes how to protect tunnels using IPSec, but it is not clear whether doing so would be an important requirement.

Taken together I've got to ask why this isn't experimental?

This one is normal discuss:

It's worth noting early that the proposal has not fully addressed the security considerations and that further analysis may show that the proposal might not be worth adopting based on what is found during the study of the security considerations.

[Ballot discuss]
This is a reiteration of Sean Turner's discuss.  I am entering as a discuss (rather than No Objection with
a supporting comment) so I can be involved in any subsequent discussion.

This seems like a perfect document for Experimental.  Running an experiment while we work through the
security issues seems like a nice lead-in to an informational or standards track specification.  The current
spec doesn't feel fully baked (esp with respect to security) imho.

[Ballot comment]
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
networks"?


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?

[Ballot discuss]
I think we need a document like this and it should be in the V6OPS
scope to produce one. In particular, I would like to see a recommendation
and operational considerations to use CGN + tunneled IPv6 service at
an ISP. That seems a very likely configuration in many places.

However, I'm somewhat unhappy with some parts of the document. In
particular:

- it portrays this as a new solution as opposed to recommended
  application of existing components
- it brings in some IMHO unnecessary extensions and references
- its treatment of IPv6-IPv4 translation aspects seems outdated
  (referring to NAT-PT)

My suggestion is to go through the document once more and remove
extra material and take the above focus comments into account, to
see if you can cast the document in slightly different terms.

More detailed comments:

The document says:

  ISPs facing only one pressure out of
  two could adopt either CGN (for shortage of IPv6 addresses) or 6rd
  (to provide IPv6 connectivity services).

I think you mean IPv4 addresses.

The document says:

  In order to
  enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to
  access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement)
  can be integrated with the CGN.

This is wrong. The replacement is already an RFC (or about to become
one), and there is no reason to switch the reference to the right
specification. Pointing to the old specification is harmful.

Sections 2.3 and 2.4 would be better cast as "just use existing
forwarding, NAT, and tunneling technology", than as something where
you describe behaviour. I had to read the text multiple times to
determine what was actually going on, and AFAICT there is no
difference to the application of normal IP forwarding rules and
tunnel termination logic. I think the usual rules are clearer
than what the document describes, e.g.,

  firstly checks whether the packet is a normal IPv4 packet
  or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN
  translates packet source address from a CGN-scope private IPv4
  address into a public IPv4 address, and then send it to IPv4
  Internet. The CGN records the v4-v4 address mapping information for
  inbound packets, just like normal NAT does. For a v6-over-v4 tunnel
  packet, the CGN needs to decapsulate it

seems to be saying that we should particularly check tunnel packets,
but I think the normal way is that the tunnel packet, being addressed
to the CGN device will naturally enter different processing than
packets routed/natted through it.

Section 2.5 should mention MTU effects.

The document says:

  An ISP can provide its IPv6-only customers with a network-layer
  translation service to satisfy this need. Such a service is not fully
  defined at this time, so we refer to it non-specifically as "NAT64".
  Current work in the IETF is focused on one particular proposal
  [I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be
  provided as a common service located at the border between the ISP
  and the IPv4 Internet, beyond the dual stack CGN from the customer's
  viewpoint. It may be integrated into CGN devices too.

This is quite outdated.

The document says:

  [I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance a
  DS-lite solution with an additional feature to ease interconnection
  between IPv4 and IPv6 realms. Home users may encounter the problem of
  reaching legacy IPv4-only public services from IPv6-only clients.
  This problem already exists in early phases, but will become more
  serious over time.

I'm concerned that we are unnecessarily listing all kinds of extensions
that we don't even know are needed and which are definitely not in
the current IETF agenda. Suggest deleting this paragraph. And delete
this as well while you are at it:

  If a different technology than v4-v4 NAT is chosen for IPv4 address
  sharing, for example [I-D.ymbk-aplusp], the present approach could be
  suitably modified, for example replacing the v4-v4 NAT function by
  the A+P gateway function.

The document says:

  For example, the appearance of IPv6 Route Advertisement messages or
  DHCPv6 messages can be used as a signal the availability of DS-Lite
  CGN. 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. The only impact on
  the home user will be to receive a different IPv6 prefix.

I'm not sure I understand what I need to do here as an implementor,
and whether all the necessary pieces in RAs are already defined.

[Ballot comment]
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
networks"?


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?

[Ballot discuss]
The document says:

  ISPs facing only one pressure out of
  two could adopt either CGN (for shortage of IPv6 addresses) or 6rd
  (to provide IPv6 connectivity services).

I think you mean IPv4 addresses.

The document says:

  In order to
  enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to
  access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement)
  can be integrated with the CGN.

This is wrong. The replacement is already an RFC (or about to become
one), and there is no reason to switch the reference to the right
specification. Pointing to the old specification is harmful.

Sections 2.3 and 2.4 would be better cast as "just use existing
forwarding, NAT, and tunneling technology", than as something where
you describe behaviour. I had to read the text multiple times to
determine what was actually going on, and AFAICT there is no
difference to the application of normal IP forwarding rules and
tunnel termination logic. I think the usual rules are clearer
than what the document describes, e.g.,

  firstly checks whether the packet is a normal IPv4 packet
  or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN
  translates packet source address from a CGN-scope private IPv4
  address into a public IPv4 address, and then send it to IPv4
  Internet. The CGN records the v4-v4 address mapping information for
  inbound packets, just like normal NAT does. For a v6-over-v4 tunnel
  packet, the CGN needs to decapsulate it

seems to be saying that we should particularly check tunnel packets,
but I think the normal way is that the tunnel packet, being addressed
to the CGN device will naturally enter different processing than
packets routed/natted through it.

Section 2.5 should mention MTU effects.

The document says:

  An ISP can provide its IPv6-only customers with a network-layer
  translation service to satisfy this need. Such a service is not fully
  defined at this time, so we refer to it non-specifically as "NAT64".
  Current work in the IETF is focused on one particular proposal
  [I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be
  provided as a common service located at the border between the ISP
  and the IPv4 Internet, beyond the dual stack CGN from the customer's
  viewpoint. It may be integrated into CGN devices too.

This is quite outdated.

The document says:

  [I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance a
  DS-lite solution with an additional feature to ease interconnection
  between IPv4 and IPv6 realms. Home users may encounter the problem of
  reaching legacy IPv4-only public services from IPv6-only clients.
  This problem already exists in early phases, but will become more
  serious over time.

I'm concerned that we are unnecessarily listing all kinds of extensions
that we don't even know are needed and which are definitely not in
the current IETF agenda. Suggest deleting this paragraph. And delete
this as well while you are at it:

  If a different technology than v4-v4 NAT is chosen for IPv4 address
  sharing, for example [I-D.ymbk-aplusp], the present approach could be
  suitably modified, for example replacing the v4-v4 NAT function by
  the A+P gateway function.

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.

[Ballot comment]
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
networks"?


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?

[Ballot discuss]
The document says:

  ISPs facing only one pressure out of
  two could adopt either CGN (for shortage of IPv6 addresses) or 6rd
  (to provide IPv6 connectivity services).

I think you mean IPv4 addresses.

The document says:

  In order to
  enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to
  access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement)
  can be integrated with the CGN.

This is wrong. The replacement is already an RFC (or about to become
one), and there is no reason to switch the reference to the right
specification. Pointing to the old specification is harmful.

[Ballot comment]
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
networks"?


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?

[Ballot discuss]
The document says:

  ISPs facing only one pressure out of
  two could adopt either CGN (for shortage of IPv6 addresses) or 6rd
  (to provide IPv6 connectivity services).

I think you mean IPv4 addresses.

[Ballot comment]
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
networks"?


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?

[Ballot comment]
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

[Ballot comment]
Figure 1: Is it supposed to to be "6 to 4" as opposed to "6 o 4" in the tunnel?  Or is the "o" just supposed to be over?

[Ballot discuss]
This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time).

The security considerations include the following two statements:

Further security analysis will be needed to understand double NAT security issues and tunnel security issues.

and

[RFC4891] describes how to protect tunnels using IPSec, but it is not clear whether doing so would be an important requirement.

Taken together I've got ask why this isn't experimental?

This one is normal discuss:

It's worth noting early that the proposal has not fully addressed the security considerations and that further analysis may show that the proposal might not be worth adopting based on what is found during the study of the security considerations.

[Ballot comment]
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.

[Ballot comment]
Please consider the points in the following TSVDIR review:

Hello,

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 tsv-dir@ietf.org if you reply to or forward
this review.


Summary:

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?

Regards,
--
Yoshifumi Nishida
nishida@sfc.wide.ad.jp

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-12-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-incremental-cgn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-incremental-cgn/

Document Shepherd Writeup for draft-ietf-v6ops-incremental-cgn-02

Prepared 10/14/2010

1.a

Joel Jaeggli, v6ops co-chair is the document shepherd for
draft-ietf-v6ops-incremental-cgn-02

1.b

The document has been reviewed by the v6ops working group, has been
socialized in v6ops meetings and was submitted to and passed WGLC on
September 27. The document shepherd believes that the document has
received adequate review to advance.

1.c

The document shepherd has no signficant quibbles with the content, and
the concepts laid out in the document, which has we believe recieved
recived adequate review. Review of transition mechanisms the document
covers occurs as a matter of course in the behave and softwire working
group.

1.d

The document shepherd has no such concerns.

1.e

Working group last call did not generate significant commentary either
for or against. It would be reasonable to conclude that working group
consensus for a document accepted as a working document remains in favor
of the applicability of this document to the problem.

1.f

No appeal is foreseen.

1.g

All Idnits were addressed in draft-02

1.h

Normative and Informative references have been split. no apparent
problems with normative references are envisioned.

1.i

IANA considerations is present. No consideration is required by IANA.

1.j

No sections are written in formal language.

1.k

Technical Summary

Global IPv6 deployment was slower than originally expected. As IPv4
address exhaustion approaches, the IPv4 to IPv6 transition issues
become more critical and less tractable. Host-based transition
mechanisms used in dual stack environments are not able to meet the
transition requirements. Most end users are not sufficiently expert
to configure or maintain host-based transition mechanisms. Carrier-
Grade NAT (CGN) devices with integrated transition mechanisms can
reduce the operational change required during the IPv4 to IPv6
migration or coexistence period.

This document proposes an incremental CGN approach for IPv6
transition. It can provide IPv6 access services for IPv6-enabled
hosts and IPv4 access services for IPv4 hosts while leaving much of a
legacy IPv4 ISP network unchanged. It is suitable for the initial
stage of IPv4 to IPv6 migration. Unlike NAT444 based CGN alone,
Incremental CGN also supports and encourages transition towards dual-
stack or IPv6-only ISP networks. A smooth transition to IPv6
deployment is also described in this document.

An integrated configurable CGN device and an adaptive Home Gateway
(HG) device are introduced. Both HG and CGN are re-usable devices
during different transition periods. It avoids potential multiple
upgrades. It enables IPv6 migration to be incrementally achieved
according to the real user requirements.

Working Group Summary

draft-ietf-v6ops-incremental-cgn-00, was accepted as v6ops WG
document, 2009-11-17. Working Group Last Call completed on v6ops
10/27/10. draft 02 was was released to address grammar issues and
idnits in document shepherd review.

Document Quality

Cross-area review from participants on the internet and transport
areas has been a solicited and provided in the course of document
socialization. Solicitation of directed reviews (particularly from
OPS directorate) should probably be part of the post-last-call
process.