Subject: (NAT) (more) IP/ICMP option to extended IP address size

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

Hi All,

	I got a some really good feedback on my posting about extended IP
addresses, including some pointers to holes in my thinking. First, I'd like
to explain a bit about my motives. My employer sells TCP/IP stacks into the
embedded systems world, so I've spent the last few years talking to
customers making networked cell phones, security systems, even wall
thermostats and household appliances. I think a BIG application for NAT a
few years from now (trillion dollar market?) will be home & neighborhood
routers - I don't think there's enough IPv4 addresses for every blender,
VCR, and doorknob in the world; and I don't think IPv6 will get here fast
enough (I'm still waiting for OSI :-).

	When Joe Homeowner installs a new appliance (let's say a thermostat
controlled by an embedded web server), he's going to want to get at it
sooner or later through his "home router". This router might be a Set top
box, a cable modem, a DSL router, or something similar. Software wise, I
think it will be a sort of "idiot proof" small office router. It could
register a new appliance through DHCP or something like SUN's new "Jini"
technology (I'm  still trying to see if there any fire inside the marketing
smoke there), but It will almost certainly have to assign the thermostat a
private IP address. To address the thermostat from outside, the homeowner
will need to know something unique, like the local IP address or a reserved
port number. His home router may be behind a similar neighborhood or
apartment complex router, thus my concern about subdividing port numbering
space - a 16 bit number may be too small to cover all the potential devices
in a large residential development. 

	Thus I've been thinking about ways to address the devices behind NAT
routers directly. Extending the IP address via IP option with the private
portion of the address enclosed seemed like a reasonable idea, but several
of you responded that some routers would either perform poorly or not at
all if we used an IP option field. I have no firsthand experience with
this, since unknown options work through my router & I have not tried this
over the Internet yet. 

	Another (perhaps uglier) alternative that occurred to me after reading the
replies today was to use an ICMP header to contain the extended IP address
instead. The "real" IP header would indicate an ICMP protocol type, the
ICMP header would have the NAT addressing info and the "real" transport
type (TCP or UDP), and the original transport header & data could follow
the ICMP header. The byte size would be larger than an IP option, but still
smaller than tunnelling. 

	I guess  what I'm willing to do is try the IP options over the Internet. I
have two ISPs available so it makes sense to attach a router to each one
and see if the packets make it back & forth. (Also see if I get a nastygram
from either ISP about it :-). 

	If there's any interest in the ICMP flavor (and no one points out an
obvious flaw) I'll test that too. 

Thanks for the feedback,

-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: Steve Deering <[email-masked]>
Date: Tue, 9 Mar 1999 13:22:48 -0800

At 9:24 PM -0800 3/8/99, John Bartas wrote:
> ...I don't think there's enough IPv4 addresses for every blender,

If all the effort being spent on hacks to get around lack of IPv4 address
space were spent on getting IPv6 deployed instead, it would probably be
here by now.

Steve
-

---

From: Daniel Senie <[email-masked]>
Date: Tue, 09 Mar 1999 16:49:50 -0500

> space were spent on getting IPv6 deployed instead, it would probably be

If there were a registry handing out blocks of IPv6 addresses to
companies, and many other infrastructure components in place, your
statement would be QUITE applicable.

It does appear IPv6 is more likely to take form at the periphery and in
private, but interconnected, networks. This all depends on the
methodology used for handing out permanent address space to those who
need it, though. No policy appears to be forthcoming from ICANN or ARIN
that I've seen.

For all the great work done on IPv6, the only method of deployment today
is 6bone, and that's just not workable for real, commercial use.
Unfortunately, IETF is not in control of the numbers registry.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Steve Deering <[email-masked]>
Date: Tue, 9 Mar 1999 14:30:17 -0800

> need it, though. No policy appears to be forthcoming from ICANN or ARIN

Daniel,

This is getting off the topic, so I will be brief.  You are right that
address allocation policy has been a crucial missing piece, but there
is finally progress on that front: the three regional IP address
registries have drafted an IPv6 address allocation policy document
and are currently circulating it for comments.  I couldn't find it
on the ARIN web site, but there's a copy at APNIC's site:

		http://www.apnic.net/ipv6draft.html

For anyone interested in this topic who will be at the IETF in
Minneapolis next week, there's a tentative plan for a meeting to
discuss this draft at lunch time on Tuesday, in the same room as
the ngtrans working group meetings.

Steve
-