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

From: Steve Bellovin <[email-masked]>
Date: Mon, 08 Mar 1999 12:00:25 -0500

In message <[email-masked]>, John Bartas writes:
> 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.

Widespread use of IP options would break the performance of most routers,
which are optimized for the no-options case.
> 
> 	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.

No, you still can't change the IP addresses in the header, since the
transport checksums include those addresses.
> 
> 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.

That security benefit of NAT is mostly illusory in any event.
> 
> 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.

If the private addresses are dynamic, as your first paragraph implies (the
phrase "performs NAT"), how would you do that?

Fundamentally, what you are suggesting is relative addressing.  I
suspect that that's an architectural swamp.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Mar 1999 17:45:24 +0000

The closest idea to this one that has been discussed previously
was my "aeiou" proposal in March 1994. The difference was that
in aeiou, the address extension option was handled by hosts, not
by NAT boxes.

One of the convincing arguments that led me to drop aeiou was
the experimental evidence that new options cannot survive the
public Internet, i.e. some routers "out there" will drop 
packets containing unknown options. After 5 years I'm afraid
I can't remember the evidence in detail, but it was a show-stopper.

     Brian

-