[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt]
I read the draft in question an I found it rather good already. I think
it really does hit a spot. I had some mostly minor comments that I think
are more a matter of taste than substantial. However, I would like to
raise them for discussion:
General comment: I think the audience of the paper are people who are
already true believers of IPv6 and then people that are just trying to
find the functionality that they need, or think they need from NATs. I
think neither of these people groups actually need any health warnings
on NATs themselves or are even interested in the problems of NATs.
Discussion about these issues just distract people. I would propose to
remove most of the problems of NAT and put them in an annex if they are
not absolutely necessary in the text. I don't think the idea of the
paper is to say NATs are bad, but to inform how the things can be done
in IPv6 without NATs and even better!
Some comments about the text itself:
The title of 2.1 ("Simple Gateway..."). Maybe a different name would be
better than "Simple Gateway". Maybe virtually zeroconfig gateway, or
easy to configure, etc. NAT is maybe actually not that simple, but
deploying it is simple for the user.
2.2. Simple security, if the issues of NATs have to be listed in the
body of the document, maybe it is also worth while then mentioning that
private addressing does not actually always mean that the network would
be that private. For instance, my provider has this bizarre
configuration where there is NAT in the network but there is one-to-one
mapping between the private address and the public address. So, it
doesn't save any addresses, protect you at all, etc. In addition, if you
have an operator provided NAT (for a reason or another) there still
might be attackers within the private address space.
Continuing in 2.2
" In some cases, NAT operators (including domestic users) may be
obliged to configure quite complex port mapping rules to allow
external access to local applications such as a multi-player game or
web servers. In this case the NAT actually adds management
complexity compared to a simple router. In situations where 2 or
more devices need to host the same application this complexity shifts
from difficult to impossible."
This does not raise the issue that complex configuration may turn into
security threats. If that wasn't even the idea, I don't think this is a
security issue and shouldn't be here in the first place. It kind of
sounds like you have remembered another bad thing about NAT, and just
add it where you were typing at that time... ;)
Section 2.3, I have often heard that NATs are good, because they give
you control on what can be done through your network. So, if you don't
want people to surf on certain sites, you just add NATs and that's it.
Maybe the "operator/provider/administrator control" should be added as a
Section 4.1, there is discussion about DHCP-PD and how simple it is and
you don't have to run any routing protocol. I think this is fine, but
does not quite answer the whole question. It might be good to add some
words about when your home or whatever gateway can get a prefix of its
own, it does not _have to_ give private addresses, but it can give real
public addresses. This is in practice not possible in IPv4. So
basically, you don't need private addresses.
So, these were my comments - for now...
On Wed, 2005-01-26 at 11:35, ext Brian E Carpenter wrote:
> -------- Original Message --------
> Subject: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt
> Date: Tue, 25 Jan 2005 16:05:42 -0500
> From: Internet-Drafts@ietf.org
> Reply-To: firstname.lastname@example.org
> To: email@example.com
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> Title : IPv6 Network Architecture Protection
> Author(s) : G. Van de Velde, et al.
> Filename : draft-vandevelde-v6ops-nap-01.txt
> Pages : 30
> Date : 2005-1-25
> Although there are many perceived benefits to Network Address
> Translation (NAT), the primary benefit of "amplifying" available
> address space is not needed in IPv6. In addition to its many serious
> disadvantages there is a perception that other benefits exist, such
> as a variety of management and security reasons that could be useful
> for an Internet Protocol. IPv6 does not support NAT by design and
> this document shows how Network Architecture Protection (NAP) using
> IPv6 can provide the benefits without the need for NAT.
> A URL for this Internet-Draft is:
> To remove yourself from the I-D Announcement list, send a message to
> firstname.lastname@example.org with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-vandevelde-v6ops-nap-01.txt".
> A list of Internet-Drafts directories can be found in
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> Internet-Drafts can also be obtained by e-mail.
> Send a message to:
> In the body type:
> "FILE /internet-drafts/draft-vandevelde-v6ops-nap-01.txt".
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
Tel: +358 40 527 46 34