Subject: Re: (NAT) IP option to extended IP address size

From: "Mike Borella" <[email-masked]>
Date: Mon, 8 Mar 1999 12:10:25 -0600

Please correct me if I'm totally out to lunch on this one,
but wouldn't this *require* that the packet pass through two
NATs?  Otherwise how would the receiving host know to return
the private address in an option?

I looked at a similar scheme for some time but eventually
abandoned it, as it became more and more messy...

-Mike

John Bartas <[email-masked]> on 03/05/99 10:22:28 PM

Please respond to John Bartas <[email-masked]>

To:   [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  (NAT) IP option to extended IP address size

Hi All,

     I've been playing with an idea for some time which might help alleviate
several of the problems being cited in NAT, NAPT, and RTIP. The idea is to
define an IP option which would contain one or more private RFC1918-ish IP
addresses. A NAT router forwarding a packet from a private to a public net
could insert this option as it forwards (and performs NAT) on a packet, and
a NAT router receiving such a packet could use the address in the option as
a destination IP when reversing the NAT. for public to private forwarding.

     Here some of the issues this would address:

1) Current NAT routers have restrictions on connections originating from
the public net to the private net. The basic problem is that the NAT router
needs some prior information (e.g. a static mapping based on transport
layer port numbers; or a recent FTP PORT command). The IP option I'm
proposing would provide the local address in a packet received from the
outside "cold", such a TCP SYN. It would, in effect, allow IP addresses of
variable length, increasing in 32 bit increments.

2) Security - The specification of the private address would reduce the
need for NAPT - port translation - thus making encryption of the transport
layer header possible without affecting NAT functionality.

3) By joining several of these addresses together, we could contain a 128
bit v6 IP address in a v4 packet; effectively "tunnelling" v6 (or other
large address spaces) through the v4 Internet with the benefits of NAT and
without the overhead of conventional tunneling.

4) Unlike RTIP, no modifications to existing protocols would be required.
With some minor "DNS games" on the routers Legacy systems could continue
operating behind these routers; reaching a wide audience of public and
private systems.

5) I'm also concerned that RTIP's idea of subdividing pools of pre-assigned
port numbers would not scale well when you get tens of thousands of hosts
on a private network. Since I'm essentially proposing an arbitrarily long
IP address, each host would retain a full 64K of TCP and UDP ports (minus
reserved ones, of course).

Down sides:

1) This defeats one of NAT's nice security features by exposing private
addresses on the public net, but that's what fire walls are supposed to
fix. Since the local address in an IP options, not header per-se, It does
not break routing.

2) A modified DNS standard would be needed to find hosts on private nets.
Perhaps some of the v6 work could be used for this.

Any thoughts? Problems I've missed?

-JB-

-JB-

#############################################################

          H
(==)o(==) H John Bartas - Main Propeller head
   _I_    H InterNiche Technologies Inc. (408) 257-8014
  /   \   H 21801 Stevens Creek Blvd. Suite 5
  -----   H Cupertino, Ca. 95014
   O O    H [email-masked] (remove foo)
    "     H <http://www.iniche.com/>www.iniche.com
  \___/   H

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Mar 1999 10:45:16 +0000

Right. Bob Moskowitz's "Net 66" proposal did the same thing
using encapsulation instead of an option; that only needs
one NAT as it turns out, but it's at the far end. This 
class of solutions (including DNR and aeiou) all require 
cooperation at the far end. That's a major downside 
for deployment.

  Brian

Mike Borella wrote:
>   --------------------------------------------------------------------------------
> 
>           H
-