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@cisco.com] Sent: Monday, March 18, 2002 7:14 AM To: Andrew McGregor Cc: ietf@ietf.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