From: Jon Mansey [mailto:jon_mansey@verestar.com]
Sent: Friday, September 07, 2001 12:44 PM>>> From: Jon Mansey [mailto:jon_mansey@verestar.com]
>>> Sent: Friday, September 07, 2001 11:57 AM
>>>
>>> I seem to be able to connect to port-forwarded services behind my
>>> office NAT firewall just fine from my laptop behind my
>>> home NAT box.
>>> Whats the problem?
>
>Can we talk ... using NetMeeting?NM, along with IPsec are examples of apps that dont play well here,
but thats the point, they are apps that have not been written with
the real world in mind, ie that a good proportion of the edge these
days is behind NAT.
NAT is the first and only method (I won't dignify it by calling it a
protocol) that munges the data. Most real protocols only mess with the
envelope and leave the data strictly alone. With NAT, its snafu. Now, if we
had bi-directional transparency, via a NAT proxyd, it wouldn't hurt so bad.
But, such a daemon is impossible to write and, if written, is impossible to
deploy.
Who gives in first here, the app developers (or their marketing
depts) who decide that supporting NAT is important, or the NAT
developers who decide they can fix cuseeme or PPTP by re-writing the
packet data?I am also playing devil's advocate here somewhat, we all know the
real solution to lack of IPv4 space, true end2end, and security lies
with IPv6, right?
<grin>
1) Feigned IPv4 addr shortages were ameliorated by recovery of legacy IPv4
allocations (/8s). IMHO, too late to prevent us from doing NAT.
2) Routeing table sizes are a routing architecture problem that won't go
away wrt IPv6. They will only get worse there.
<personal opinion>
Whomever shot down IPv6 imbedded routing, needs to be taken out and shot in
turn. The counter-arguments were not convincing, IMHO. I thought it was a
great idea. There is nothing inherently wrong with imbedding the routing
into the protocol itself and it sure helps (a bunch) to standardize things.
</personal opinion>