Subject: Writeups on why RFC1918 is bad?

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Sep 2003 08:33:35 +0300 (EEST)

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Sep 2003 16:18:00 +0930

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)

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 15 Sep 2003 09:48:29 +0200

> easier to convince them not to do so with IPv6").

Have a look at RFC 1627. However, it's probably a bit too old to be 
exactly what you're looking for.

And if any of you kids out there reading this are confused by the 
reference to RFC 1597: that's the predecessor to RFC 1918.  :-)

I think it's important to make the distinction between the use of 
private address space and the use of NAT, though. NAT is evil and 
anyone who wants to use it in IPv6 should be tarred and feathered, 
because it breaks communication that isn't simple client/server. But 
it's possible for reasonable people to have different views on the use 
of private addressing as stable address space.

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 15 Sep 2003 10:59:31 +0300

Pekka,

Unfortunately, if someone had this they probably would have used it to
explain why local addresses should be removed from IPv6.

Since no one was able to produce it then, I doubt it exists now.

But I would love to see it if there is one, as this would help close the
issue, because it would need to explain why they are bad and what can be
used to replace the perceived good that people (like the enterprise that you
mention) see in them.

Eric
----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 15, 2003 8:33 AM
Subject: Writeups on why RFC1918 is bad?

> --  ---------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Sep 2003 10:42:20 +0200

Pekka,

I believe RFC 2993 actually covers all the issues (including the one
of VPNs between RFC 1918 sites, especially in section 7.6). 

Given how difficult it was to get that RFC published, I wonder if it
is worth the effort of writing what would efefctively be the same
document, but with an emphasis on ambiguity instead of translation.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Sep 2003 15:51:58 +0300 (EEST)

Hi,

> of VPNs between RFC 1918 sites, especially in section 7.6). 

Thanks for the pointer.  Yes, RFC 2993 seems to cover many aspects which
seem surprisingly familiar ;-), but I'm not sure if it answers questions
like : "I want to use NAT or RFC1918 for purpose X.  Why shouldn't I do
it?  (Why might I want to do it anyway?)  What other feasible ways are
there to do it without such mechanisms?"

In other words, the document seems to cover the scenarios using a broad 
overview -- it may not be applicable to the most common cases of 
deployment.

But then again, I'll have to go read the RFC in detail.
 
> document, but with an emphasis on ambiguity instead of translation.

I can certainly envision how this could turn ugly.  Could you elaborate a 
bit on the difficulties that came across?

Pekka

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Sep 2003 14:02:54 +0200

Pekka,

The document came out of the IAB, while the NAT WG was active, so there was a
lot of diplomacy between the IAB, the IESG, and the NAT WG chairs, to get to
a version of the document that everybody was happy with. Since we don't have
a NAT WG today, that side of it might be easier, but it can very easily become
a religious war.

    Brian