NAT BOF Meeting Minutes This meeting was chaired by Pyda Srisuresh <suresh@livingston.com>. The minutes were taken by Andy Malis. The email list is nat@livingston.com. To join, send email to nat-request@livingston.com. Pyda introduced the meeting by recapping the results of the BOF meeting at the Munich IETF. Agenda: * Word from the area director * Word from the IAB Chair * NAT BOF/Working Group objectives * Review of NAT internet drafts * Questions and comments Scott Bradner, the Transport area director responsible for this WG, discussed the IESG view of the NAT working group's proposed charter and work. Concern has been expressed in the IAB and IESG on the implications of NAT, especially in the security area. This is not yet a working group (it has not been chartered due to these concerns, and the IESG's wanting to add more security work to the charter). It will become a working group once the charter issues have been resolved. This is expected to happen following the first of the year. Brian Carpenter, the IAB chair, presented the IAB's view of the NAT work and their concerns. They want the phrase "In fact, NAT seriously threatens the fundamental end-to-end principle of the Internet architecture" to be added to the charter, and want the WG to produce a realistic guide to what will and won't work in conjunction with NAT. They also are concerned about the architectural interactions between NAT, IP security, VPNs, and IPv6. The bottom line is that they are still very leery about NATs, although they do realize that they are part of the real world, and this conflict has to be resolved. Scott also does not want NATs to interfere with the differentiated service work now ongoing in the Integrated Services working group. NAT Working Group Objectives: * A Forum to discuss NAT applications, limitations, and impact on Internet protocols and applications. * Applications: prevent address renumbering, address conservation, load sharing, etc. * Limitations: Hard to debug, security limitations, topology constraints, cannot support IP addresses in payloads, etc. * Impact on IP protocols and applications: multicast IP, DNS, fast IP, firewalls, etc. Review of NAT drafts: 1. Network Address Translator, draft-rfced-info-srisuresh-03.txt, meant to replace RFC 1631. 2. Load sharing using IP Network Address Translation (LSNAT), draft-srisuresh-lsnat-00.txt. NAT Characteristics: * Address and TCP/UDP port mapping: Assign global addresses and TCP/UDP ports dynamically, based on session flow. * Address and TCP/UDP port translations: Translations based on state-full session translation parameters. * Topology restrictions to ensure packets in both directions traverse through the same NAT router. * Transparent to client and server applications. * NAT is a nice hack, but does not work in all applications. Question from the audience: Are we going to be looking at NAT applicability to both IPv4 and IPv6 immediately, or just IPv4? Pyda: This WG is going to be discussing IPv4 NATs only, at least at this time. Brian Carpenter: If we are going to have an IPv4 network that is heavily dependent on NAT, then we would have to discuss a transition to an IPv6 network that was also heavily dependent on NAT. Scott Bradner: There is a close relationship to the ngtrans working group that has to be resolved. Traditional NAT (the first draft above): * "Basic NAT" as borrowed from RFC 1631. * Based on outbound session translation. * Prevents address renumbering. * Includes a second feature, "NAPT" - Single Network Address Port Translator. * Both "Basic NAT" and "NAPT" operate on the border router to a stub domain with private address space. Network Address Port Translator: * Multiple private addresses use a single global address to run TCP/UDP/ICMP applications. * Translate TCP/UDP ports of private addresses into TCP/UDP ports of the assigned global address. * Translate Identifier Field in ICMP queries of private addresses into that of assigned global addresses. * Conflict-free TCP/UPD port assignments when assigned address is same as address of WAN interface. Pyda presented examples of NAT and NAPT operations and address translations. The primary difference is that NAT translates between sets of addresses and maintains port numbers, while NAPT changes port numbers in order to share the same global IP address between multiple local addresses. Load Share NAT (the second draft above): * Purpose is to distribute incoming session load across a pool of servers. * A single server can map of any of a pool of servers. * Individual services (e.g. web service) on a server can be mapped to different pools of load-share servers. * Based on inbound session translation and load-share algorithms. * Load Share NAPT configuration provides topology freedom for load-share servers. Local-Load Share Algorithms: * Round-Robin * Least Load First - Equate load on server to sessions assigned to the server. * Least Traffic First - Equate load on server to traffic to and from the server. * Least Weighted Load First - Assigns weights to servers based on resource capability; weights to sessions based on expected resource consumption. * Ping Load Share Server Load sharing applies to every incoming session. Distributed-Load Share Algorithms: * Weighted least Load First - Based on cost of access to load share server and number of session assigned to the server. * Weighted Least Traffic First - Based on cost of access to load share server and traffic (measured in packets/bytes) to and from the server. LS-NAPT: * No topological restraints on load-share servers location. * Load sharing would be limited to TCP/UDP applications. * Allows for bandwidth expansion for client access. * Computationally more intensive compared to traditional NAT or LSNAT. * The 16-bit length of TCP/UDP ort identifier field limits the maximum concurrent sessions to 63K TCP sessions and 63K UDP sessions. Scott Bradner asked for a show of hands as to why people were here. Most were here because they were concerned about the security information of NATs, rather than planning on building NATs. Many were also here because they plan to deploy NATs in their organizations. IBM announced that they have patents in this area, and they will be posting the information. The license to the patent will be made available on a reasonable and nondiscriminatory manner. Pyda mentioned that Van Jacobson may have prior art in this area. Scott Bradner added that if people know of prior art that precedes the IBM patent, they should notify IBM of that fact. Bob Moskowitz said that the ability to use end-to-end security must take precedence over the ability to use NATs. NATs only can apply if they are allowed by your security policy. Pyda presented some examples of how these algorithms work. Q: Does the load-share NAT do any address conservation? A: No, it only uses address translation in order to do load sharing. This is a different application of the NAT mechanisms. NAT has some interesting applications that go beyond the original address conservation goals. Question and answers: Q: Does it make sense to add a NAT MIB to the charter? A: Yes. Q: One of the big problems for NATs is protocols that embed the IP address in the protocol, especially the security protocols. The group should make a list of all the places where this occurs. Scott Bradner: Please send any concerns about the proposed charter to the area directors. Q: We're not really worried about the effects of NAT on IP security. A: There will be an item on the charter that says the WG has to deal with this issue.