Subject: palet-v6ops-proto41-nat-03 comments

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Nov 2003 14:22:51 +0200 (EET)

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

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 15 Nov 2003 13:24:48 -0600

Pekka,

Thanks a lot for your comments.

Will start working on addressing them immediately, and will provide any feekback or clarifications if needed.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, November 15, 2003 6:22 AM
Subject: palet-v6ops-proto41-nat-03 comments

>    As stated in [5], "with a Bidirectional NAT, sessions can be
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.