Ahh, it doesn't have to damage routing transparency. If we were to use
a signaling protocol that is carefully crafted to preserve routing
transparency (e.g. RSVP) then we can avoid this issue.
The upnp guys are not really thinking of damaging routing transparency.
The protocols explicit probe the first hop router on the network for
upnp capabilities. In their model of a home gateway/LAN there is no
"internal" routing, the world is bridged, so the signaling should not
damage routing transparency. The limitation they have currently
introduced is that they do not "fix" NATs that run "in the network" or
allow initiation of "hole punching at the calle end of the network" from
the caller side. (RSVP could also solve this problem).
If you really want to cry in your green beer about routing transparency
then you should be crying about http proxies, tunnels, VPNs, bandwidth
brokers, ipsec, yes - midcom, etc. But as one might note, and you get
together 3 times a year at incredibly high prices (:-)), you are going
to get protocols and standards that put the meat of the solution into
middle boxes.
Cheers, peterf
-----Original Message-----
From: Melinda Shore [mailto:mshore(_at_)cisco(_dot_)com]
Sent: Monday, March 18, 2002 7:14 AM
To: Andrew McGregor
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Netmeeting - NAT issue
Microsoft has recently addressed the NAT traversal issue for
multimedia
scenarios by shipping Messenger in Windows XP and it uses universal
plug
and play protocols (www.upnp.org) to open holes on upnp capable
internet
gateways. There are many vendors building upnp capable NATs in 2002.
Nice.
Not really. It's just midcom, which solves some problems
and introduces other. It restores one kind of end-to-end
function (addressing) while damaging another (routing
transparency).
Melinda