Subject: Re: (NAT) NAT operational issue

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Mar 1999 14:48:15 +0000

At 11:02 03/03/99 +0000, Brian E Carpenter wrote:
>Huh?
>
>If there are routers in the ISP path with 1918 addresses, it seems
>to me that much more than MTU discovery will end up broken.

I have a question
(for my edification, not because I'm suggesting it's a Good Thing):

Is this scenario broken?

                  +------------------------------------+
                  | ISP domain                         |
                  |                                    |
+--------+ public |               private              | public +----------+
| User   |  adrs  | +--------+     adrs     +--------+ |  adrs  | Public   |
| domain |----------| router |--------------| router |----------| Internet |
+--------+        | +--------+              +--------+ |        +----------+
                  |                                    |
                  +------------------------------------+

Assuming no hosts in the "private adrs" network of the "ISP domain"
communicate outside of that network, and assuming the leakage admonishment
of RFC1918 is properly respected.

I am thinking that the private address network may simply be a local
implementation technique for a "distributed router", which is kept hidden
from the outside.

#g

------------
Graham Klyne
([email-masked])

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Mar 1999 15:08:20 +0000

I can't see why it won't work, except that it will confuse
users of ping, traceroute and other operational
tools. It could also cause a problem if two ISPs doing this
happen to merge their networks. And if the ISP wants to run
servers inside its domain, it will need NAT/ALGs to make those
servers reachable from outside, and 2-faced DNS. And as we have 
seen there is a real practical possibility of leakage.
Altogether a messy situation.

   Brian

-

---

From: [email-masked] (Pyda Srisuresh)
Date: Wed, 10 Mar 1999 08:19:15 -0800 (PST)

Sorry to be late on this thread. I agree with Brian's comments 
below.  Using RFC 1918 address block inside a service provider
network could be a messy situation. I just want to add the 
following comments.

Clearly, the service provider using the RFC1918 addresses
could not advertise the block to outside. This implies that
the public-domain DMZ hosts (of the service provider) do not 
use this address space. (or) RFC1918 addressed host may 
be accessed from outside, if there exists a NAT and DNS-ALG 
enroute. It would be nice to have provided traceroute-ALG 
as well. I have seen NAT devices shipped with traceroute-ALG
integrated.

Also, if the MTAs in the service provider network use RFC-1918 
addresses and they prepend their IP Address (instead of their 
name) on "Received:" line -  It would make it hard to track the 
MTA chain. This causes a problem for people trying to prevent 
spam (Refer RFC 2505). In such a case, the service provider will 
need to employ SMTP-ALG to ensure that embedded addresses in 
SMTP payload are properly translated.

cheers,
suresh

-

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Mar 1999 15:50:13 -0800

Anything the public is really supposed to connect to should be on public
address space- that's what it's there for (hence the word public).  To
me this would include an ISP's {mail,news,web} server.

I believe Brian raises a good point about diagnostic tools and private
addresses on routing infrastructure.  If a customer is using net 10
confusion could certainly reign with a traceroute.
--
Eliot Lear
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 10 Mar 1999 19:00:23 -0500

[CC: mercifully trimmed]

>confusion could certainly reign with a traceroute.

Eliot,

This is not news.

- paul

-