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@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.
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
ftp://ftp.intel.com/pub/H.323/DOCS/h323_and_firewalls_wp.doc
which has a paper on some of the issues/solutions...
Best Regards, jimt.
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@telia.se
The differnt alternatives:
- 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.
- 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.
- A combination of alternatives1 and 2 should be possible, and may
acheive a lesser complexity than 1.
- 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.
- 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@ideal.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************
participants (2)
-
Annika Kilegran -
Jim Toga