Hi Pekka,
I haven't looked at Keith's document, but having had to develop VPN / NAT solutions,
and also witnessed a number of NAT's short comings I'd be quite willing to contribute
to a document like this.
As an observation, it seems that a lot of "non-IETF" networking people aren't aware of
the architectual principles of the Internet. I had sat Cisco, Novell and Microsoft
TCP/IP courses, and had deployed NAT on a few occasions, but it wasn't until I read
the first chapter of Christian Huitema's "Routing In The Internet" did I gain an
understanding of the Internet architectual principles, and therefore, why NAT was not
a good solution. I'd suggest most TCP/IP courses just don't cover it, but they do
cover NAT, usually in a positive manner.
Information about NATs weaknesses exist in a number of places, but as you have pointed
out, not in one place - at least that I've come across.
If a single document is to be prepared, I'd suggest the following topics, not
necessarily in this order :
* An overview of the architectual principles of the Internet, in broad,
lay-networking-person terms.
* An overview of how NAT works.
* How it doesn't fit the architectual principles of the Internet, both a broad
description, and specific areas where it doesn't fit.
* Security and availablility examples where NAT doesn't work, or doesn't work as
people think it does.
* Myths that have driven the use of NAT eg. running out of IPv4 addresses, perceived
security advantages etc. and statements that discredit them.
I know a number of these topics are already covered in a number of RFCs, some of the
job may just be to re-write them in less technical / theoretical terms, and to
consolidate them in one place.
I'd see the target audience for this document to be the type of people you've been
talking to.
Hopefully, a one-stop "this is how the Internet is supposed to work, and this is why
NAT stops it working that way" document might go some way into changing the IPv4 NAT
mindset.
On Mon, 15 Sep 2003 08:33:35 +0300 (EEST)
Pekka Savola <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Regarding the local addressing debate...
>
> I had the misfortune to having to participate in a discussion where a
> multiple-branch (20-30+) enterprise, which has deployed private addresses
> and network-to-network VPN's inside it, wants to start using IPv6.
>
> I'm wondering whether there exist any educational material why
> RFC1918-like addressing is really *NOT* a good idea (or even, list and
> evaluate the tradeoffs), and how to get around it. ("If one can state
> clearly arguments why they shouldn't be doing it with IPv4, maybe it's
> easier to convince them not to do so with IPv6").
>
> It seems to me that there is a very severe need for a way to enlighten
> folks like that if we ever want to be successful..
>
> http://www.cs.utk.edu/~moore/what-nats-break.html is interesting, but not
> focused enough for RFC1918-like addressing itself.
>
> I.e., what I'd like to see is whether anyone has written up something
> regarding either "why local addressing would be a bad idea with IPv6", or
> "why local addressing is a bad idea with IPv4", especially from the
> security point-of-view.
>
> btw., one way to probably avoid the two-faced DNS issues with local
> addressing is probably to simply use a different naming for internal
> commuications like with example.com --> example.internal.
>
If I understand your example correctly, I might have done a similar thing a couple of
years or so ago.
I created a sub-domain for site-locals eg sl.example.com, and stuck all the site local
AAAA's under that sub-domain, where as all the global addresses were under
example.com, or general sub-domains of it.
To prevent public Internet nodes from querying this private name space, you could
delegate the local addressing sub-domain to a DNS server that only answers queries
from local addresses.
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
