Subject: (NAT) Extended IP tests.

From: John Bartas <[email-masked]>
Date: Mon, 29 Mar 1999 18:22:41 -0800

Hi All,

 A few weeks ago I threw out an idea about using NAT and in IP option to
extend
IP addresses. Some of you showed interest, and several of you advised that I
use an encapsulation protocol instead, since unusual IP options may not
traverse all commercial routers in a clean manner. 

 I promised to code a prototype and run some tests, and the result was pretty
successful. Below is a description of what I did and the results. There's also
an MS-word (office 95 flavor) version of the same text attached for those of
you who prefer that format. If no one sees any glaring problems with the
ideas,
I'd like to work on a draft. I'm posting here first because this group's feed
back was really helpful last time around.

BTW, the diagrams really need a non-proportional font.

-JB-

xNAT - Extension of IPv4 addresses through Encapsulation and NAT.

Goals:

The goals of the technology described herein are 

1)  Allow unrestricted access to an unlimited number of machines on 
    private (NAT) networks from other private networks and from the 
    public network. 
2)  Work with existing IPv4 end-node machines on the private 
    networks (as both clients and servers).
3)  Must operate over the existing public infrastructure (The 
    Internet).
4)  Be truly transparent to applications, not requiring NAT ALGs
5)  The design also should provide for a DNS based mechanism for 
    discovering these private machines.
6)  Allow for easy encryption of transport layer headers and data.

Encapsulation:

 The mechanism developed for moving the packets in this way 
involves encapsulating the Transport layer header inside a small 
encapsulation layer (thanks to all those who steered me away from using 
an IP option to do this!). The encapsulation header (herein "ENCAP") is 
inserted by the first "extended NAT" (xNAT) router, modified by each 
subsequent xNAT, and stripped out by the last xNAT router in the packets 
path. The Encapsulation header I used is a 32 bit header, followed by a 
number (two in my experimental case) of 32 bit IPv4 addresses. The 
encapsulation header is 4 8-bit fields, as follows:

+-----------------+------------------+---------------+---------------+
|   protocol_ID   | dest_IP_count    | src_IP_count  |  reserved     |
+-----------------+------------------+---------------+---------------+

 The fields are:

protocol_ID   - Transport protocol ID, e.g. 6 for TCP.
dest_IP_count     - number of private source IPs following header.
src_IP_count      - Number of private destination IPs following header  
reserved - Must be zero, added primarily for word alignment */

 Following this header are dest_IP_count number of private source 
IP addresses, followed by src_IP_count number of private destination IP 
addresses. In the my test (described below), there were one of each, one 
private source being 10.0.0.20, and the other 192.168.0.33. While 
traversing the public net, my TCP packets from 192.168.0.33 to 10.0.0.20 
had an ENCAP header with the following values:

+-----------------+------------------+---------------+---------------+
|   6 (for TCP)   |       1          |       1       |      0        |
+-----------------+------------------+---------------+---------------+
|                       10.0.0.20                                    |
+-----------------+------------------+---------------+---------------+
|                       192.168.0.33                                 |
+-----------------+------------------+---------------+---------------+
|  start of TCP header 
+

 The IP header had a destination address of 209.221.45.231 and a 
source address of 228.234.58.7; the public addresses of the two NAT 
routers.

Test setup:

    (******************************************************)
    (* The Internet (3)                  *)
    (******************************************************)
         |                                            |
 ------------------                          ------------------
|                  |                        |                  |
|  ISP router      |                        |  ISP router      |
| (Concentric)     |                        |  (best.com)      |
|                  |                        |                  |
 - 209.221.45.1 --                           -- 228.234.58.1 --
         |                                            |
         |(2) DSL link        (4) PPP over V.90 modem |
         |                                            |
 - 209.221.45.231--                          -- 228.234.58.7 --
|                  |                        |                  |
|  LAB NAT         |                        |  JB's NAT        |
|                  |                        |                  |
--- 10.0.0.1 ----                           -- 192.168.0.1----
        |                                            |
        | (1)Ethernet                   (5) Ethernet |
        |                                            |
       |                                            |
 --- 10.0.0.20---                            -- 192.168.0.33 --
|   "Linux"      |                          |     "Kermit"     |
|  Linux (x86)   |                          |   Windows 95     |
|                |                          |                  |
 ----------------                            ------------------

 I think the above setup is the minimum needed for a meaningful 
test. The two ISP routers are of unknown type (except as indicated by 
their link types) and belong to two different commercial ISPs. I felt 
using different ISPs provided a better test. The two NAT routers are the 
only machines which needed to run modified software to make this work. 
Note that I've numbered all the segments (1) through (5), lumping the 
whole Internet leg of the journey as (3).

I was able to successfully ping and establish TCP (http) 
connections from 192.168.0.33 to 10.0.0.20. The ping command on Kermit 
was simply "ping 10.0.0.20". All other IP addressing was similar.

Perhaps the most encouraging result of this exercise was the 
observation that the ICMP and TCP headers in packets on segment (5) were 
identical to those on segment (1) - including checksums. This means 
security software in the NAT boxes could encrypt the packets from the 
TCP headers on up - much enhancing security over private to private 
connections. It suggests a very easy way to do VPN like functionality.

Unique Global addressing.

 To facilitate using this technology, a syntax is needed to 
globally and uniquely describe each privately addressed IP host. This is 
done by appending the private portions of the addresses to the public 
addresses, resulting in a "Universal IP address", or UIP. In this case 
the UIPs are 

source - 228.234.58.7.192.168.0.33
destination - 209.221.45.231.10.0.0.20

 Using this syntax, any private IP host behind a publicly connected 
NAT can be uniquely identified. Note that the first 4 octets of a UIP is 
in the IP header, the rest is in the ENCAP header.

 Also note that these can be infinitely (well, almost infinitely) 
extendible. If  "Linux" (10.0.0.20) and Kermit (192.168.0.33) were also 
xNAT routers supporting this mechanism, with 10.0.0.20 as it's 
"upstream" (closer to the public net) interface, and an downstream 
interface with IP 10.1.0.20, then these NAT routers could host yet 
another layer of private hosts behind it. For example:

    (******************************************************)
    (* The Internet (4)                  *)
    (******************************************************)
         |                                            |
 ------------------                          ------------------
|                  |                        |                  |
|  ISP router      |                        |  ISP router      |
| (Concentric)     |                        |  (best.com)      |
|                  |                        |                  |
 - 209.221.45.1 --                           -- 228.234.58.1 --
         |                                            |
         |(3) DSL link        (5) PPP over V.90 modem |
         |                                            |
 - 209.221.45.231--                          -- 228.234.58.7 --
|                  |                        |                  |
|  LAB NAT         |                        |  JB's NAT        |
|                  |                        |                  |
--- 10.0.0.1 ----                           -- 192.168.0.1----
        |                                            |
        | (2)Ethernet                   (6) Ethernet |
        |                                            |
       |                                            |
 --- 10.0.0.20---                            -- 192.168.0.33 --
|    Linux       |                          |     "Kermit"     |
|  another NAT   |                          |   Windows 95     |
|                |                          |   another NAT    |
 ----10.1.0.1----                            ---192.168.1.33---
       |                                            |
        | (1) Ethernet                  (7) Ethernet |
        |                                            |
       |                                            |
 --- 10.1.0.3----                            -- 192.168.1.34 --
|                |                          |                  |
|     "Bert"     |                          |     "Ernie"      |
|                |                          |                  |
 ----------------                            ------------------

In this case, Bert's UIP would be:

209.221.45.231.10.0.0.20.10.1.0.3

And Ernie's would be:

228.234.58.7.192.168.0.33.192.168.1.34

An IP datagram targeted to Bert on the Public net would have the 
209.221.45.231 portion in the IP header as the target address, and the 
last 8 octets in the ENCAP header. The ENCAP header for a TCP packet 
from Ernie (192.168.1.33) to Bert (10.1.0.3) would look like this:

+-----------------+------------------+---------------+---------------+
|   6 (for TCP    |       2          |       2       |      0        |
+-----------------+------------------+---------------+---------------+
|                       10.0.0.20                                    |
+-----------------+------------------+---------------+---------------+
|                       10.1.0.3                                     |
+-----------------+------------------+---------------+---------------+
|                       192.168.0.33                                 |
+-----------------+------------------+---------------+---------------+
|                       192.168.1.33                                 |
+-----------------+------------------+---------------+---------------+
|  start of TCP header 
+

 To illustrate in more detail, lets consider the various Addresses 
(IP & ENCAP) which would appear in a packet as it travels from Bert to 
Ernie. In all cases the first 4 octets of the Address are what appear in 
the IP header as source or dest address; the remaining info is encoded 
in the ENCAP header. 

Seg   Source                    Dest
(1)  10.1.0.3          ->    192.168.1.34

 This is a simple IPv4 packet - no ENCAP header.

(2)  10.0.0.20.10.1.0.3        
                      ->    228.234.58.7.192.168.0.33.192.168.1.34

The first NAT inserted the ENCAP header containing the 
destination's full UIP and it's own upstream address, thus building the 
beginnings of a source UIP. 

(3) 209.221.45.231.10.0.0.20.10.1.0.3
                       ->    228.234.58.7.192.168.0.33.192.168.1.34

The second router only slightly modifies the ENCAP header.  Since 
the packet still heading "upstream" (towards the public net) the second 
router inserted it's own upstream IP address, further building (in this 
example completing) the source UIP. The destination, still a full UIP at 
this point, does not need to be modified until the packet starts heading 
"downstream" away from the public net. 

Segments (4) and (5) are identical to (3) since they are all 
public net, and contain the full UIP of both hosts.

(6) 209.221.45.231.10.0.0.20.10.1.0.3
                         ->    192.168.0.33.192.168.1.34

 The first downstream NAT router (JB's NAT) has stripped it's 
upstream public address from the UIP and forwards the packet to Kermit, 
the next downstream router. Thus the UIP of the sender is delivered 
intact to the final NAT router in the chain, where it can be used to 
build a table for reply packets.

(7) 10.1.0.3          ->    192.168.1.34

 The packet on final segment is identical to the original packet on 
segment (1) except for IP hop count. The last NAT router (Kermit) at the 
end of the chain has completely stripped the ENCAP header and cached the 
FULL UIP of the remote host.

UIP resolution via DNS:

 For my test, the UIPs of my target machines were set up in static 
tables in the NAT routers. Obviously xNAT technology is far more useful 
if DNS queries from the clients can result in the creation of UIP tables 
in the NAT routers. By making the NAT routers double as DNS servers, 
this is doable. In the example above, Bert, when connecting to Ernie in 
the domain jbslab.com, could send out a DNS query for [email-masked]. 
The query would eventually be forwarded (based on the domain name) to 
either Kermit or JB's NAT, whichever was responsible for the domain 
"jbslab". Since these are participating NAT routers, they can craft the 
usual DNS reply with 228.234.58.7 as the "answer" RR, and add the 
private portion of the UIP (192.168.0.33.192.168.1.34) in the reply's 
"Additional" RR. As the DNS reply gets back to Bert, the final NAT 
routers DNS (Linux) would recognize it's previous query and extract the 
Additional RR information. The DNS reply which ultimately reaches Bert 
would indicate to Bert's plain old IPv4 stack that Ernie's IP address is 
192.168.1.34. 

Locally Duplicate private addresses:

 On problem not yet addressed is the possibility of duplicate 
"local" private addresses. Once Ernie has connected to Bert, any further 
IP packets on Ernie's local segment addressed to 10.1.0.3 would be 
picked up by Kermit and xNAT routed to Bert. Suppose a later DNS query 
from Ernie or some other host on his segment returned a UIP with the 
same last private address, in this case 10.1.0.3. The two UIPs would be 
distinct in Kermit's tables, however a packet on the local segment 
addressed to 10.1.0.3 could be reasonably matched to either UIP. 

 Some techniques can be used to minimize the ambiguity. The NAT 
router can track which local IP issued the DNS request resulting in each 
UIP, and thereafter favor that UIP for packets from the IP address that 
issued the initial DNS request.

 This is still not foolproof. It's possible two applications on the 
same machine could want to reach different locally duplicated addresses. 
Still worse, they may even want to reach the same port on different 
machines whose UIPs share same last 4 octets. This is an area which 
needs more study.

Glossary:

xNAT - NAT with the extensions described herein.

Upstream - the direction through an xNAT router caring a packet towards 
the public network.

Downstream - the direction through an xNAT router caring a packet 
towards the public network.

UIP - Universal IP address - globally unique extend IP address for 
private IP hosts.

ENCAP - The encapsulation header used by xNAT to contain extended IP 
address information. 

-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, 30 Mar 1999 16:12:14 +0100

John, 

What happens if both "linux" and "kermit" happen to have
the address 10.0.0.20? This can of course happen when the
two ends are in different, uncoordinated enterprise networks.

    Brian
-

---

From: John Bartas <[email-masked]>
Date: Tue, 30 Mar 1999 12:17:46 -0800

Hi Brian,

At 04:12 PM 3/30/99 +0100, Brian E Carpenter wrote:
>the address 10.0.0.20? 

	Then I slowly realize I missed an obvious problem :-{

>This can of course happen when the

	Good point. Even worse, packets Kermit sends to any 10 net address will
(in most default setups) just stay on the local network - they won't get
directed to the "JB's-NAT" machine for routing at all. 

	One possibility is doing an xNAT alias via DNS. Kermit would send a DNS
query for Linux.iniche.com, and while forwarding the reply the DNS software
on JBs-NAT would recognize the conflict and substitute a more palatable
private address (after all, this IS NAT).  But that starts to break up
xNATs transparency benefits.

	I can think of bunch of ways to solve this by adding something to Kermit
(xNAT shim, route table entries) but I really don't want to require
modification of the existing nodes involved.
		Lemme think about this a bit....

-JB-

-JB-

-

---

From: John Bartas <[email-masked]>
Date: Wed, 31 Mar 1999 20:31:27 -0800

Hi all,

>two ends are in different, uncoordinated enterprise networks.

	Another idea on this - xNAt could specify certain private subnets for
hosts which are intended to be reachable from the public net. For example,
if any host intended to be accessable should be in the 10.254.0.0 net, then
most server machines would be 10.254.X.X, and most client machines would not. 

	Machines which might want to be both client and sever, such Linux boxes,
could maintain 2 IPaddresses on their local net - one from each group.

-JB-

-