[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: palet-v6ops-proto41-nat-03 comments
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" <pekkas@netcore.fi>
To: <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Saturday, November 15, 2003 6:22 AM
Subject: 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
>
**********************************
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.