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

From: Bruce Wootton <[email-masked]>
Date: Tue, 9 Mar 1999 11:48:28 -0800

John Bartas wrote
>Hi All,

.. some deleted parts

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

Encapsulation seems like a good idea in general.  

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

We've done some testing with this in the past and come up with mixed
results.  Some option numbers seem to be dropped more often then others. It
is certainly possible to get the packets through.  ( We did it over a number
of different 12-hop Internet connections ).  

I think that the performance problem might be larger than it seems at 
first.   I haven't designed any routers, but I imagine that too many 
packets in the slow path could cause routers to start dropping packets
wholesale.  The danger there is that you wouldn't know it's a problem
until you had wide scale deployment. Over here, we're moving away
from IP options to an encapsulation scheme here, for precisely that
reason

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

Good luck,

Bruce
[email-masked]

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