begin quoting Tracy R Reed as of Mon, Mar 27, 2006 at 02:09:17PM -0800:
> Stewart Stremler wrote:
> > Bad protocols. They should be fixed. Easier to change protocols than
> > infrastructure. (It's not like the concept of _ports_ was new, or proven
> > useless. Sheesh.)
>
> Not necessarily. Take VOIP for instance. It is *extremely* useful to
> have signaling separate from voice data.
Yeah? So?
That is not precluded by NAT. It's only precluded for certian protocols
that made what turned out to be unwarranted assumptions.
[snip]
> and in most cases you will not be signaling with the same place that you
> will end up sending your voice data to so you cannot do it all in the
> same connection. How else are you going to use some out of band
> signalling protocol (such as Session Initiation Protocol) to set up to
> set up a real-time protocol (such as Real Time Protocol) session between
> a couple of other hosts without passing port and ip numbers? At some
What's wrong with passing port and IP numbers?
> point the two end points have to know how to get ahold of each other. I
Yes. And that's a matter of policy. It should be UNDER THE CONTROL OF
THE USER.
> imagine any solution you propose would be more complicated than just
> getting rid of NAT and using default-deny firewalls.
Why do you get to use lack of imagination as an excuse and not me?
> I think SIP/RTP are very well designed protocols which we will be seeing
I think they have one *obvious* flaw -- calling 'em "well-designed"
doesn't make that flaw go away. Especially when adding a couple of
bytes to each packet header makes the problem go away.
> a lot more of in the near future. Currently people are getting around
> the SIP/NAT thing by proxying all VOIP traffic. That is a nasty kludge
> (such as is often inspired by NAT traversal solutions) which will not be
> scalable, incurs a performance/call quality penalty, introduces more
> points of failure,
Sounds like a protocol design failure to me.
> and throws away a great deal of the fle
???
> > Obviously, the easy solution is to build NAT boxes that can be plumbed
> > with multiple IPs, and then allow "forwarding" to be allowed on a
> > per-IP as well as a per-port basis. (Presumably a soekris box could
> > do this easily.) Once this is "common functionality", the desktop
> > NAT boxen can do this as well.
>
> NAT boxes doing forwarding for multiple IP's? If you have multiple IP's
> available why not just route those IP's to their respective machines, do
> default deny, and have the problem solved cleanly?
Control.
Pure and simple.
If I'm re-arranging things internally, I need to either have an IP
per service, play silly games with DNS and accept hours-to-weeks lag time,
or do port/address translation anyway.
> > Of course, you're then up against the "not enough IPs" problem, so
> > nothing's really been accomplished. So blaming NAT is just a red
> > herring... the REAL whining is about how nobody wants to do IPv6.
> > Aside from the IPv6 geeks. :)
>
> Blaming NAT is definitely not a red herring for the breakage of VOIP and
> other protocols caused by NAT since ipv6 is not yet even involved in
> most networks.
It is. The VOIP protocols that are broken by NAT are _broken_.
Blame NAT is just a feeble excuse. We're at the point of foot-stomping
here, as accoriding to wikipedia, there are VoIP protocols that aren't
broken by NAT. It can be done, in principle. It has been done, in
practice. Therefore, the problem isn't NAT.
> I'm hoping we do find some killer-app to make everyone
^^^^
It's this sort of thinking that bothers me... encourage is one thing,
make is another. If you want to force people to adopt some solution,
then to be fair, you *don't* get to decide what that solution should be.
You slice, I choose.
> switch to ipv6. I am wondering if maybe the P2P networks will have the
> answer. If people start trading their files (illicit or not) on an
> ipv6-over-ipv4 tunneled network it will be harder for the ??AA
> organizations to find them (they won't figure out how to setup ipv6 for
> a while) and could drive adoption.
Depending on your opposition being stupid is always a stupid plan.
Plus, it breeds the wrong sort of arrogance.
> > (I can see an IPv6 world using a unique IP for every service, and every
> > ethernet device being plumbed with all those IPs... and ports would then
> > be ignored (probably assumed to be '80'). And this touted as a Good
> > Thing. I'd want to be convinced of this *before* I do anything to make
> > this sort of madness fait accompli.)
>
> I don't see what the advantage to that would be. Then you would have to
I don't see the advantage in designing a protocol that breaks with NAT,
or of demanding that people expose their internal networks to save on
having to use one of the other NAT-capable protocols. Put a port in
the protocol header already and it's an easy fix to make NAT boxen play
nice with it.
> have a name in dns for each of those ip's and remember all of the names
> etc. If you can run multiple services on one box it would be easier to just
?
I didn't say it would be a _good_ idea.
--
_ |\_
\|
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
