Subject: (NAT) Domain Name Routing, DNR

From: "Hasan S. Alkhatib" <[email-masked]>
Date: Mon, 08 Mar 1999 16:28:51 -0800

Hi Everyone,

I am new to this list, but I was intrigued by the discussion about
"(NAT) IP option to extended IP address size" At IP Dynamics, we have
been working on the problem of extending the IPv4 address space for some
time.

We have introduced a method whereby we extend the IPv4 address space by
using the domain name space for the unique identification of end
machines inside privately addressed edge networks. We call the method
Domain Name Routing, or for short DNR.

The method allows a node that is given a private IPv4 address (or any
private address) to be reachable on the Internet through its fully
qualified domain name. The private node can be the client that initiates
connections too, in a manner similar to host/distributed NAT. The client
is required to insert the domain name of the server in the options field
of its IPv4 packet. The packets are addressed to a new type of edge
router that is used for the privately addressed edge network. We call
the new edge router the DNR gateway. When the packet arrives to the DNR
gateway it is tunneled to the end server on the private subnet. The DNR
gateway uses the embeded domain name to identify the private IP address
of the server. A split-DNS is employed to seperate global DNS
resolutions from private DNS resolutions.  The technique requires a
change to the client IP stack in the form of a shim. It also requires
the introduction of this new type of edge router which we call DNR
gateway. We do not require any change to the current DNS protocols. The
method also preserves full compatibility with todays applications, and
supports end-to-end use of IPsec among other benefits.

We have two implimentations for the technology, one in the Linux
platform and the other in the Windows 98 platform. If you are interested
in further details about the DNR technology, a white paper is available
on our web site at www.ipdynamics.com.

We own a (pending) patent on the technology and plan to introduce it as
a VPN solution. We plan to make the technology available to everyone at
a reasonable cost to licensees.

The technique can solve the end-to-end reachability problem on the
Internet if IPv6 does not get deployed widely. We have not yet submitted
a draft RFC, but we will in the near future.

Best Regards,
Hasan Alkhatib

-----Original Message-----
From:   Steve Bellovin [SMTP:[email-masked]]
Sent:   Monday, March 08, 1999 9:00 AM
To:     John Bartas
Cc:     [email-masked]
Subject:        Re: (NAT) IP option to extended IP address size

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

---

From: John Bartas <[email-masked]>
Date: Mon, 08 Mar 1999 21:59:40 -0800

Hi Hasan,

>a reasonable cost to licensees.

	I was really interested until I got to the patent part. It's been about 10
years since I did any standards work, but back then anything patented was
pretty much automatically rejected. When we think we have a good idea here
at my place of employment, we decide if it's better business to patent it,
or just give it away & hope our expertise with it results in increased
business. Something like a really slick algorithm for NAT table lookups
might make sense to patent - vendors could pay you if they use it, or
choose not to. A DNS improvement, however, is far more useful if it becomes
universal. Sun's NFS and FTP Software's "Packet Driver" spec. are just two
examples where giving away the technology probably made more money than
locking it up and trying to charge for it would have. An lots of companies
(unfortunatly not mine :-) pay their engineers to do IETF work just for the
"prestige" factor.

	On the other hand, I can't think of any cases where someone patented
Internet technology, got it accepted as a standard, and managed to collect
fees from all the vendors of TCP/IP software. I hope you'll reconsider.

-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: "Hasan S. Alkhatib, Ph.D." <[email-masked]>
Date: Mon, 08 Mar 1999 22:32:11 -0800

Hi John,

Thanks for your note. We have applied for the patent to protect our intellectual
property. We are though open as to what business model we will pursue. We are a small
R&D company and don't have the resources that big companies have. But, we are
flexible.

Best Regards,
Hasan