Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt]

["EricLKlein" <ericlklein@softhome.net>]

Speaking for myself, as one of the Authors - see comments below.

Thanks for the serious read through and comments.

Eric
----- Original Message ----- 
Soininen Jonne wrote:

> I read the draft in question an I found it rather good already. I think
> it really does hit a spot.

Thank you.

> 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.

Actually when I got involved with writing this it was for the IPv6 nay
sayers who felt that NAT was the mos timportant feature in the IP world. I
spoke with people in network security and network administration roles and
when they hear that we had depriciated RFC1918 like addressed in IPv6 they
compleatly freaked out. They felt that NAT was needed for site security, or
for seperation of subnets, or other of the "percieved values" that we put
into the paper.

So in short my goal was a paper that could be used by the IPv6 true belivers
to either explain to newbies or disbelivers why their NAT was not being
upgraded with the rest of the addresses and networking.

> 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!

We tried to not do too much NAT bashing, but there were so many
misconceptions as to why a network "just has to have NAT" that the
explinations made the rest seem to make sense to us. If there is a real
problem and the WG all agrees, we can review moving these.

> Some comments about the text itself:

> 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.
>

If your provider is doing this (and it is not the first time I have heard of
this configuration) then are you using NAT after the fixed address to share
the connection between multiple hosts? Thus making it:

Fixed address (Carreir to carrier) <-> NAT (Carrier to Customer) <-> NAT
Customer Network  <-> Host

If so then it is you that are saving the IP addresses not the carrier (this
is why we have many diffrent catagories in section 5).
As to the security concerns, where I have seen this done the carriers are
usually using NAT to subnet their network (as described in 5.4) so that they
have one large block and are using it to reduce problems in their
administration network. But you are right to you there is still no security
benifit.

> 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... ;)

Not all that is bad with NAT is limited to security.
>
> 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
> perceived benefit.
>
Good point.

> 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.
>
Also a good point.
>