----- Original Message -----
Sent: Thursday, October 23, 2003 3:31
PM
Subject: Comments
draft-palet-v6ops-proto41-nat-01.txt
Hi Jordi,
my "last minutes" comments on your draft. Hope they are
not "too late" comments.
In general, I
am very positive over the document. The remarks are mainly for extra
clarification!
General comment:
1)
"NAT boxes" is very often used in the draft meaning actually "IPv4-only
NAT node". An IPv6/IPv4 node that is a 6to4 router implements also NAT only
for IPv4 packets. Then, it can be referred to as a NAT boxes as well. However,
no need to implement proto41 on this box (although it can be and you mention
this in the draft but then it's overdone and rather confusing for the router
producer what (6to4 or proto41) and when (IPv4-only or IPv6/IPv4 node) to
implement ). The strong need for support of proto41 is in "IPv4-only NAT
nodes" in order to support IPv6 tunnels. That is why I recommend the use of
"IPv4-only NAT nodes" instead of "NAT boxes". Further see my remark in section
5.
[Jordi] Very good catch.
Addressed.
2) Very often
in the draft "this behavior" is used meaning "forwarding protocol 41" or the
nickname "proto41". Replacing the former with the latter is more tangible and
I recommend it.
[Jordi] Already addressed.
Specific comments:
- Abstract
I
agree with the Rute's comment here
[Jordi] Already addressed.
1. Introduction
1-2 paragraphs: Substitute with a short intro to the scene, e.g.
Nowadays
homogeneous IPv4 private networks are massively deployed. The first migration
step from IPv4 to IPv6 for these networks is adding an IPv6 node (or cluster
of IPv6 nodes). In this case the IPv6 node communicates with IPv6 peers in the
public Internet via IPv6 packets tunneled into IPv4 ones. Most of the existing
solutions suppose that the router of the private network is begin-/end-point
of the tunnels. Typical examples of such routers are 6to4 IPv6/IPv4 routers
that have already been commercially deployed. However, nowadays most of users
have IPv4-only NAT routers in their private networks and they are not willing
immediately to invest in a new router for whatever reasons, mostly
financial.
That is why in
this draft we propose to make use of protocol 41 forwarding in IPv4-only NAT
routers. This mechanism allows IPv6 tunnels and therefore facilitates the
migration path from IPv4 to IPv6.
[Jordi] Already addressed. In my opinion this is
a generic comment for transition (not migration) in general, but we have
already several transition mechanism that don't rely on IPv6 routers, so I
included a "short" version of your text.
4 paragraph: revise, for example
The scenario illustrated above has been tested with several
IPv4-only NAT boxes/routers that have successfully established IPv6 tunnels
between tunnel clients in a private network and tunnel servers in the public
Internet. In the test we have used three well-known Tunnel Broker
implementations (BT, Freenet6 and TILAB) and routers from 6Bone, Consulintel,
Euro6IX and UPM networks.
[Jordi] Already addressed.
5 paragraph: This can --> This scenario can ..
[Jordi] Already addressed.
2. Rationale for this behavior --> Rationale for
using protocol 41 forwarding
[Jordi] Already addressed.
3. Behavior of different NAT types
I do not understand Rute's confusion here
since Basic (or Traditional) NAT, NAPT and Bidirectional (or two-way) NAT is
commonly used terminology.
[Jordi] My understanding is that she is reading
another draft regarding NAT.
5
paragraph in 3.2: This can also be combined with basic NAT. -->This port
forwarding is often combined with basic NAT leading to NAPT.
[Jordi] Already addressed.
2 paragraph in 3.3: Revision required.
What you wanna say is written so compact that it is rather getting
non-understandable.
[Jordi] Already
addressed.
1 paragraph in 3.4: N.B. At the
beginning of this section make clear that "configurable" NAT can be either 3.1
or 3.2 or 3.3. Each of the first three types can act as a fully bidirectional
NAT for 41-packets if it is configurable.
[Jordi] Already addressed.
4. Applicability
1 paragraph:
inside-to-outside sessions outgoing sessions, outside-to-inside sessions incoming sessions
So,
this is consistent with the terminology you use later.
If my first general comment is applied here the Rute's
remark is resolved.
[Jordi] Already
addressed.
6 paragraph: the application of this
procedure --> the
application of 41-packets forwarding
[Jordi] Already addressed.
7 paragraph: move to Introduction and
consider language revision
[Jordi] Already
addressed.
8 paragraph: move to Introduction after
the intro paragraph I suggested.
[Jordi]
Already addressed.
5. NAT design consideration
-->
NAT design consideration and recommendations
I agree with the Rute's first comment here.
[Jordi] Already
addressed.
3 paragraph: confusing the reader and contradicting the
general idea. I would rather say something like
The proto41 and 6to4 are complementary
transition mechanisms that facilitate the migration from IPv4 to IPv6.These
two mechanisms are in general applicable in different migration steps. The
proto41 mechanism is mostly relevant and applicable for IPv4-only NAT routers
whereas 6to4 mechanism is mostly relevant and applicable for IPv6/IPv4
routers. Notice that an IPv6/IPv4 router that is 6to4 enabled and implements
NAT only for IPv4 packets does not need to be proto41 enabled.
[Jordi] Already addressed.
Some extra conclusions that you may add to make this
section complete:
·
The proto41
adds an enhanced feature to the IPv4-only NAT routers, namely enabling them to
forward IPv6 packets encapsulated into IPv4 ones, i.e., allowing for IPv6
tunneling.
·
The proto41
completely preserves the users investments in the existing IPv4 networks. This
is essential for gaining market acceptance.
· The proto41 allows for gradual migration from IPv4 to IPv6
networks making the migration path easy and acceptable for the users.
Greetings,
Mariana
-----------------------------------------------------------------------------------------------------------------
Dr.
Mariana Nikolova
Philips Research Laboratories Eindhoven
(IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The
Netherlands
room: WDC 1.35, phone: +31-40-27-45455
e-mail:
mariana.nikolova@philips.com
-----------------------------------------------------------------------------------------------------------------