H.323 Annex D in the Incoming directory of gctech ftp site

Vineet Kumar Vineet_Kumar at CCM.JF.INTEL.COM
Mon Mar 9 15:42:00 EST 1998

This is very similar to what an H.323 Proxy/firewall solution has to deal
with.  If you're interested you might want to check out


which has a paper on some of the issues/solutions...

Best Regards,

At 10:05 AM 3/9/98 +0100, you wrote:
>Network Address Translation (NAT) is used as a solution to the
>problem of few available IPv4 addresses. The idea is to use private
>addresses within a domain and when IP traffic leaves or enters the
>internal network the address fields are translated between the public IP
>addresses and the corresponding private address. A private address is
>only associated with a public address when the node communicates
>externally. By using this mechanism it is possible to have many more IP
>nodes in the private domain then the number of assigned public IP
>addresses to that domain. NAT is a defacto solution to connect for big
>groups of users.
>The combination of NAT and applications exchanging IP addresses in the
>protocol (like H.323 does) creates problems.
>The applications are either broken, or gets more difficult to run.
>There are different solutions for how to be able to run these
>application in combination with NAT. We list the
>alternatives in the bottom of this mail.
>Does anybody on the mailing have an opinion?
>For instance, a Gatekeeper might have to interact with the NAT
>(co-located), and possibly act as an application gateway.
>By the way the question might com up on the DAVIC meeting next week.
>Best regards,
>Annika Kilegran
>Telia Research
>S-136 80 HANINGE, Sweden
>Tel +46 8 707 55 15
>Fax +46 8 707 53 10
>Email: annika.w.kilegran at telia.se
>The differnt alternatives:
>1) Use an Application layer gateway, that translates addresses in the
>application protocol. Used today for FTP.
>Will work, but will be quite complex for H.323. The Application layer
>gateway would typically be co-located with the NAT-box.
>2) Use the location of servers, and the configuration of servers and
>clients to overcome the problem.
>DNS is handled this way today. Seems not to work for H.323.
>3) A combination of alternatives1 and 2 should be possible, and may
>acheive a lesser complexity than 1.
>4) NAT bypass using tunneling over the
>local network. The global address is
>available in the host and is used in the application, removing the
>problem. This kind of solution have been
>proposed in contributions to IETF.
>5) Skip NAT altogether. Instead use IPv.6, or something like NNAT (No
>NAT) for IPv.4. NNAT will completely replace NAT, and uses DHCPv.6 for
>assigning global addresses. NNAT remains to be specified for
>IPv.4 operation.

***  +1-503-264-8816(voice)             +1-503-264-3485(fax)          ***
***  jtoga at ideal.intel.com              Intel - Hillsboro, OR.        ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***

More information about the sg16-avd mailing list