2.7.14 Network Address Translators (nat) BOF

Minutes of the NAT BOF Meeting

Network Address Translator (NAT) BOF met at the 39th IETF at Munich and was presided over by Pyda Srisuresh under the auspices of the Transport Area. More than 100 people from most of the IETF areas attended. Yakov Rekhter, Pyda SriSuresh and Steve Deering used slides during the presentations. I will try to have these slides available for view in the next couple of days.

Many thanks to Bertrand Buclin for painstakingly taking the BOF notes and sending them to me by e-mail in a very short time.

We now have a mailing list created to discuss NAT issues. The NAT mailing list is formed to address NAT related topics and issues such as NAT friendly application design rules, exploration of specific problems people think NATs create, identify topologies that NAT boxes do not seem to support, DNS, security, mobility and IPv6 issues effected by NATs, etc.

Initial membership consists of everyone who signed up at the Munich BOF (stated more accurately, everyone whose e-mail IDs we could decipher). If you do not want to get the mailing list please send email to majordomo@livingston.com with line "unsubscribe nat" in the body of message.

Details of the mailing list are as follows:

Mailing List: nat@livingston.com
To join the list: Send email to nat-request@livingston.com with "subscribe" in

To leave the list: Send email to nat-request@livingston.com with "unsubscribe"

Start of NAT BOF Meeting Minutes

I. Agenda presentation by Suresh
II. Word from Scott Bradner, Transport Area Director
III. Statement of Objective
IV. Overview on NAT by Yakov Rekhter
V. Talk on IP security considerations by Steve Bellovin
VI. Presentation of new internet draft on NAT by Suresh
VII. "Is NAT an alternative to IPv6 transition" by Steve Deering
VIII. Wrap up and closure by Scott Bradner

I. Agenda presentation by Suresh

Suresh presented the following agenda:

II. Word from Scott Bradner, Transport Area Director

NATs have been seen as something evil and ugly in the IETF. However, NAT is there and is being used, so the IESG decided to investigate how much NAT should be standardized. The internet-draft from Suresh and Kjeld started the discussion going and the IESG decided to use this as a basis to reopen the discussion within IETF with a BOF session. The arrival of the intranet concept and the draconian approach used by some of the ISPs in address allocation has forced people to revisit the applicability of NATs.

III. Statement of Objective

Suresh stated the objective of the meeting to be the following:

IV. Overview on NAT by Yakov Rekhter

Yakov Rekhter presented NATs (with no application specific knowledge) and Application Level Gateways (ALGs) as devices helping interconnect disparate routing realms. The Internet model was that there should be a single routing realm in the world. However, reality shows that there is more than one realm (for example, RFC1918 acknowledges the existing of multiple realms with the provision of re-usable address ranges). Two options for interconnecting realms are either ALGs or NATs. Both NATs and ALGs help interconnecting routing realms with either distinct or overlapping address spaces.

There are two flavors of ALGs, Non-transparent and Transparent. A non-transparent ALG, by its name is visible to end users and requires users to establish explicit connection with the ALG, whereas the transparent ALGs are non-visible and users are not aware of the ALG presence during their transactions. Non-transparent ALGs allow for other-than-address based authentication, whereas transparent ALGs relying solely on address based authentication.

NATs modify addresses in IP header and adjust transport layer (TCP/UDP) checksum. But, NATs are application independent and do not understand syntax and semantics of application data stream. NATs can use dynamic or static address mapping. Static is more robust because there is no need to determine if the mapping would be terminated. Dynamic mapping could be driven either by DNS requests, or by the data traffic (although the latter is the most common). NATs deal very poorly with application data that contain IP addresses. For example, FTP PORT command.

ALGs are application specific and may not be very efficient from performance stand point. As a middle ground between ALGs and NATs, Yakov suggests the use of ATs, which are NATs with application specific knowledge where possible, combined with ALGs for all other types of applications.

Specifically, ATs could incorporate DNS ALG functionality for the interconnecting routing realms. FQDNs have to be unique across realms. Usually, also DNS zones are constrained to a single realm. An AT should modify DNS RRs data when it traverses the gateway.

End-to-end IP security is jeopardized when packets cross routing realms, as NATs, ALGs and ATs alike perform routing address translations. IPSEC assumes that addresses are preserved on an end-to-end basis. IP SEC does not support applications crossing multiple realms. However, IPSEC is not the only way to achieve security. Yakov suggests enhancements to IP security to support communications spanning multiple routing realms.

The major use of NATs today is to interconnect routing realms based on RFC1918 private addresses. It also improves the address space utilization, and thus reduce the rate of consumption of IPv4 addresses. Enables scaleable routing via topologically significant address assignment while limiting the impact of renumbering to AT itself. It also provides scaleable routing support for multihomed sites and improves path symmetry for those. Finally, they could be used for migration from IPv4 to IPv6. Drawbacks are unpredictable failure modes when dealing with an application that is not supported via the ALG functionality but carries IP address at the application layer. IP SEC for inter-realm connectivity is problematic.

NGTRANS has a proposal on the table called No-NAT (NNAT) which addresses most of the drawbacks of NAT, however this proposal needs to be further developed to see if it is a viable alternative.

V. Talk on IP Security Considerations by Steve Bellovin

The very issue of security is to establish trust. IPSEC's purpose is to not trust the network, and establish trustable mechanisms between hosts. The main use of IPSEC is either host to host, or firewall to firewall (VPNs). In most case, all the hosts behind a firewall are considered as 'secure' thanks to the firewall. The main thing to worry when deploying IPSEC is determining the trust boundaries. With NATs, when DNSSEC is used, the signatures on the responses must be cut off. On a general basis, NATs prevent most of the services relying upon cryptographic services (e.g., non-repudiation because the NAT would need to act on proxy of the user and have the user private keys !). Application level security is by definition applying to an environment with different trust boundaries. Re-engineering IPSEC to cope with NAT would mean trusting a third party (the NAT), thus lessening the overall security level (theoretically). For example, with encrypted FTP data channels, NAT would not work unless the NAT device has the decrypting key of one of both parties involved in the transfer, which defeats the purpose of encrypted FTP.

VI. Presentation of New Internet Draft on NAT by Suresh

New internet draft to replace RFC 1631 was presented by Suresh. Srisuresh (suresh) and Kjeld Egevang author the ID. The new draft extends RFC1631 with the concept of Network Address and Port Translation. There are public domain implementations available from linux and freeBSD.

NAT has significant issues:

The new draft makes a few clarifications and corrections:

Network Address Port Translator:

Security considerations with NATs:

VII. "Is NAT an Alternative IPv6 Transition?" by Steve Deering

Steve does often IPv6 tutorials, and a very frequently asked question is whether NAT is an alternative to IPv6 transition?

NAT have kept the Internet alive and growing and helped buying time for the development of IPv6 NAT can help avoid renumbering when one changes service provider.

However, NATs do not nicely support using redundant paths out of a site, and breaks IP mobility in certain (likely) topologies. So, NAT as a new addressing and routing architecture, is a bad idea and significantly inferior to the current one. More complicated, more fragile, less efficient, messy interdependence between IP and DNS, and harder to debug and manage, less accommodating to new applications etc.

VIII. Wrap up and Closure by Scott Bradner

The issue is not anymore whether NAT is a good thing or not. It is merely whether the IETF should do something about it. Many questions were raised.

Arguments in favor of further work are:

NAT has been helping preserving address space. Even though, it should not be included as a recommended practice for the registries when assigning addresses. However, some of them set for themselves the policy of imposing NAT onto their local 'customers.'

Most of the attendees admit that a NAT WG should be set up within the IETF. The NAT WG will itself define the charter and what kind of deliverables it will produce (BCP, FYI or standards).

Jim Bound requested that the NoNAT concept be covered by NGTRANS. Jim also argued on the rationale that NAT is widely deployed and hence that justifies the creation of a WG so that the IETF stick to reality. While the IESG has mandated IPSEC for IPv6 while it can't be exported. This shows inconsistency with the definition of 'sticking to reality.'

Attendees List

Roster Not Received

Previous PageNext Page