An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
draft-ietf-v6ops-incremental-cgn-03
Yes
(Ron Bonica)
No Objection
(Dan Romascanu)
(Gonzalo Camarillo)
(Lars Eggert)
(Peter Saint-Andre)
(Ralph Droms)
(Russ Housley)
(Sean Turner)
(Tim Polk)
No Record
Note: This ballot was opened for revision 03 and is now closed.
Jari Arkko Former IESG member
(was Discuss)
Yes
Yes
(2010-12-16)
Unknown
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?
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-12-15)
Unknown
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.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2011-03-26)
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(2010-12-16)
Unknown
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
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
David Harrington Former IESG member
No Record
No Record
(2010-12-15)
Unknown
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