[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
palet-v6ops-proto41-nat-03 comments
Hi,
I wrote up my comments on palet-v6ops-proto41-nat-03 on the plane. HTH.
substantial
-----------
1) too proactive, e.g. the last 3 paragraphs of the abstract etc. -- if the
goal is to document the mechanism, this needs rewording.
2) there is no clear description whether bidirectional NATs also work in
traditional/outbound NAT way unless explicitly configured? This would be a
huge benefit, as outbound NATs don't need to be configured to be used.
3) 6to4 interoperability requires more discussion. One should spell out
that the NAT box would have to act as a 6to4 router; or were you suggesting
that the NAT box would somehow blindly look at inside the packet and look at
the destination address part?
FWIW, why would the two methods need to co-exist? The NAT box could support
both, but have only one mechanism enabled at a time? This way the vendor
doesn't have to take a stance which method to choose for
implementing/enabling -- it could do both 6to4 and proto-41 forwarding..
4) you seem to be recommending implementing bidirectional NAT and the manual
configs at the end of section 5. I don't think this is useful advice. It's
better that the NAT boxes are stupid devices, and don't have to bastardize
the users w/ DNS-ALG as well:
In addition, considering that the code changes needed to support a
full bidirectional NAT will be minimum, this option should also be
considered, at least as a configurable option, in an easy way by the
user (very simple http interface).
==> (also note:) s/minimum/minimal/, s/in an easy way by/as an easy way to/
?
According to that the tunnel broker must properly create the script
or configuration file that will setup the client tunnel endpoint. In
that case they should have requested the public addresses (can be
automatically detected) and the local interface ID or name of the
tunnel client.
==> tunnel brokers are not required to have "scripts", reword this section
to be a bit more generic?
5) note that when a user is behind a NAT today, I don't think IPv6 should be
enabled:
1) automatically without user intervention (and resulting warnings), or
2) a default firewall configuration which gives NAT-like ("everything
out/nothing in") properties
.. this would mitigate the risks of unknowingly punching through NATs..
I don't think the security threat in the third paragraph of the security
considerations is a relevant or real one -- similar is already possible.
That could be removed..
6) I don't think the document describes that this method won't work if a
second node behind the NAT starts using proto-41 forwarding correct?
semi-substantial
-----------------
Abstract
==> the abstract must not have references, and it should be shorter; single
paragraph of some 5-15 (or thereabouts) lines.
1. Introduction
Most of the existing solutions for the transition to IPv6 rely in
tunnels assuming that the client end-point is an IPv6 capable router.
However, nowadays the installed base of IPv4-only NAT boxes/routers
is still quite big, while most of the client operating systems
already support IPv6.
Some IPv4-only NAT boxes/routers allow the establishment of IPv6
tunnels from systems in the private LAN (using private IPv4
addresses) to routers or tunnel servers in the public Internet.
==> one should beef up this "mini-problem statement" a bit; note that
proto-41 is not a prerequisite for tunneling, one could use e.g. UDP. This
document kind of makes that assumption.
==> the end-point must not be a router, but it must be v6 capable node, yes.
==> s/rely in/rely on/
This fact should be taken into consideration by tunnel broker
implementations in future versions, in order to properly create the
script in case the client is located in a private network.
==> which fact? describe in detail or refer to section 6? Note that e.g.
running "scripts" is a tunnel broker implementation detail..
The document does not discuss how the local private network is
organized, for example, in case the Tunnel Client is an IPv6 router
providing IPv6 connectivity to other systems. The behavior in this
case should be the same as any other IPv6 native network (that is
using stateless or stateful autoconfiguration, or any other typical
functionalities like Home Agent, etc).
==> this section seems to need rewording; the first part especially, and the
last part starting from "This behaviour" or at least from "(that is" should
be removed completely.
RFC 2663 [5] distinguishes several types of NAT routers. This
document focuses on how proto 41 forwarding works over the two most
common types: Traditional NAT and NAPT.
==> what about the other types? Even if out-of-scope for this spec, some
clearer statement is needed.
different transport ports for each one. Entries in NAT table have the
form [source IP address, source TCP/UDP port, target IP address,
target TCP/UDP port]. Both types can be combined in the same NAT
router.
==> and what about the others, like ICMP?
To facilitate that, a default configuration could be defined. For
example, in the case of simple NAT routers used in most SOHO
accesses, the default configuration could include a pre-defined
private network address for the LAN interface and a pre-defined
private address for the host where all the proto-41 traffic is
forwarded.
==> this kind of special config would seem like a bad idea. Some use
net-10, some others, etc. There is no way such config could be useful..
6to4 and Proto-41 forwarding can coexist in the same NAT box. In that
case, an IPv6 over IPv4 packet received, will be forwarded to the
private LAN only if the IPv6 destination does not belong to the local
6to4 /48 prefix. Otherwise it will be decapsulated in the NAT box,
following 6to4 procedures. This fact avoids the problems created by
mobile users when they visit a network that uses 6to4, in the case
they have some automatic proto-41 setup.
==> do you mean that the NAT box is a 6to4 router (if so, say it!), or that
the box somehow intercepts and decapsulates the packet (state more
explicitly how to decapsulate and which 6to4 procedures)?
==> I'd also reword the last sentence.
8. References
==> split to Informative and Normative references.
editorial
---------
Internet Draft Jordi Palet
Document: draft-palet-v6ops-proto41-nat-03.txt Cesar Olvera
Consulintel
Category: David Fernandez
==> s/Jordi/J./, s/Cesar/C./, etc.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
==> no numbered references in the status of this memo are allowed
the usual way is to finish the tunnel directly in a device with an
IPv4 public address.
==> s/finish/terminate/ (similar elsewhere in the document, also "ending"
has been used sometimes...)
==> s/an IPv4 public/a public IPv4/
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [4].
==> these are not being used (and shouldn't be anyway), so you can remove
this section
| |
Public IPv4 | |
+-----+ |
==> the diagram has been muched up in two places, the '|''s are off-base..
Although this mechanism is not usable on all existing IPv4-only NAT
boxes/routers, the large number of them that already support it gives
an opportunity to rapidly deploy a huge number of IPv6 nodes and
networks (in case the node behind the NAT is an IPv6 router) without
the need of using or designing new transition mechanisms.
==> s/all/all the/
==> I'd reword this as well, at least the start of the paragraph, after
"boxes/routers"..
3.1 3.1 Traditional (or) Outbound NAT
==> remove extra "3.1"
As stated in [5], ?with a Bidirectional NAT, sessions can be
==> there are a few special weird chars like before "with" in the doc, also
later in the document. Check these out. Btw, I'd recommend trying to
remove the explicit DOS-style line breaks as well.
What it is needed in our case is just the basic mechanism included in
bi-directional NAT to statically associate one of the private
==> s/What it is needed in our case is just/It's required that/
In this way, all ingoing IPv6 over IPv4 traffic will be forwarded to
==> s/ingoing/incoming/
bidirectional way, even when no outgoing traffic is generated. IN
==> s/IN/In/
6to4 and Proto-41 forwarding can coexist in the same NAT box. In that
case, an IPv6 over IPv4 packet received, will be forwarded to the
==> s/an IPv6 over IPv4 packet received,/if an IPv6-over-IPv4 packet
is received, it/
compatibility reasons (with existing network configurations), it
could be still considered to maintain the support proto-41.
==> s/be still/still be/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings