Well, NAPSTER comes pretty close. Two peers can exchange files if at
least one of them can act as a server, i.e. is not blocked by a NAT. If
both are behind NAT, they can't. The point being, NAT are only
transparent if the host behind a NAT acts as a "client", and initiates
the TCP connection. Peer-to-peer applications assume that every host can
be a server.
That's a great example! The other example that sometimes urks me is
the issue of bi-directionally managed SNMP devices (that use polling
and traps). You have to start doing all kinds of strange things, like
SNMP proxying to make this stuff work.... my view is an address should
be the address, unquestionably and undeniably. There is also the
issue of new distributed bi-directionally communicating firewall
technologies and things. These are kind of peer-to-peer applications.
It can be argued that all of this should be on the same side of the NAT,
but what happens if you are an MSP managing or securing remote customer
networks? NATs make life very difficult for them. You have to start
building VPNs into customer networks and then you are working with
multiple DNS and multiple NAT servers... very ugly stuff if you want
to reliably manage it all.
v4. Renumbering can be expensive. NATs are seen by many enterprises as a
way of removing the need to renumber should they change providers. Until
the issue of renumbering is addressed, NATs will not go away.
I'm still very intrigued by what David Conrad wrote above and I completely
agree with. Is there any way that ipv6 handles provider renumbering? I
can think of a couple ways it could be done given the huge ipv6 space.
But personally, I like the convention of just using DNS names for all
devices, and then you can renumber pretty much at will. But there are
problems there also.
I realize ipv6 renumbering has probably been covered in depth, but
is there any more thoughts incorporated into it related to provider
renumbering?
Kyle Lussier
www.AutoNOC.com