NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Pyda Srisuresh <srisuresh@yahoo.com>
Matt Holdrege <matt@ipverse.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Scott Bradner <sob@harvard.edu>
General Discussion:nat@portmasters.com
To Subscribe: nat-request@portmasters.com
Archive: http://www.portmasters.com/cgi-bin/lwgate/NAT/archives/
IP V4 Network Address Translation (NAT) has become an increasingly common function in the Internet for a variety of reasons. NATs are used to interconnect a private network consisting of unregistered IP addresses with a global IP network using limited number of registered IP addresses. NATs are also used to avoid address renumbering in a private network when topology outside the private network changes for variety of reasons. And, there are many other applications of NAT operation.
A number of NAT deployments are currently in use and naturally, a large number of internet applications work transparently with NATs. However, there are applications for which NATs would fail and custom-specific Application Level Gateways (ALGs) are required to perform translations for those applications.
NAT has the potential to interrupt end-to-end nature of Internet applications, thereby threatening end-to-end security and other end-to-end functions. In addition, NAT has topology restrictions and other constraints on the protocols and applications that run across NATs. Thus NATs have a particular area of application and should not be considered a general solution.
This working group will provide a forum to discuss applications of NAT operation, limitations to NAT, and impact of NAT operation on internet protocols and applications. The Working Group recognizes that NAT may interfere with protocols that use cryptographic protection for authentication, integrity or confidentiality. The Working Group will NOT suggest changes in such protocols to make them NAT friendly when such modification will significantly reduce the security provided by those protocols. However, the Work Group will examine and discuss alternative solutions, and other new ideas relating to this issue. Broadly speaking, the objective of the work group is to come up with a series of documents in the following categories.
The first category of documents will address what NAT is, how NAT works and applications of NAT operation in address conservation, prevention of address renumbering, load sharing and other areas.
The second category of documents will address requirements of NAT and limitations to NAT operation. Specifically, this will include a detailed list of applications which are known to have problems working over NATs.
The third category of documents are Informational RFCs which will specify NAT friendly application and protocol design guidelines, interactions between NATs and applications such as DNS and protocols such as IP sec. Particular emphasis will be placed on security issues. The Work group will also examine and discuss various alternative solutions, and other ideas to identify areas where NATs or other protocols and applications can be improved to overcome the shortcomings in interoperability or functionality.
The fourth category of documents will deal with network management of NATs.
Exploration of the use of NATs for load sharing is not within the scope of this working group.
The goals and milestones section below lists just the subject matter of issues to be covered. This is done so deliberately because there may be some adjustments made to the packaging of the RFCs, while covering all of the contents below. The work group will decide how to group the contents into different RFCs.
Done |
|
Submit Internet-Draft on what is NAT and how NAT works. |
Done |
|
Submit Internet-Draft on NAT limitations and a list of applications and protocols known to have problems working with NAT. |
Dec 98 |
|
Submit Internet-Draft on NAT friendly application and protocol design guidelines. |
Dec 98 |
|
Submit Internet-Draft on Interaction of NATs with IP switching, roaming IP, mobile IP, IP multicast, DNS and other protocols and applications. |
Dec 98 |
|
Submit Internet-Draft on security implications of NAT. |
Apr 99 |
|
Submit Internet-Draft on Network Management Information Base for NATs. |
Feb 01 |
|
Submit Experimental RFC on Realm-Specific IP (RSIP) framework |
Feb 01 |
|
Submit Experimental RFC on Realm-Specific IP (RSIP) protocol specificatio |
Feb 01 |
|
Submit RFC on RSIP Support for End-to-end IPsec |
Mar 01 |
|
Submit Informational RFC on NAT friendly application design guidelines |
Mar 01 |
|
Submit Informational RFC on Framework for interfacing with NAT |
Mar 01 |
|
Submit Informational RFC on Framework for interfacing with NAT |
· NAT Friendly Application Design Guidelines
· Realm Specific IP: A Framework
· Realm Specific IP: Protocol Specification
· RSIP Support for End-to-end IPSEC
· Framework for interfacing with Network Address Translator
· Finding an RSIP Server with SLP
· Definitions of Managed Objects for Network Address Translators (NAT)
RFC |
Status |
Title |
RFC2663 |
IP Network Address Translator (NAT) Terminology and Considerations | |
RFC2694 |
DNS extensions to Network Address Translators (DNS_ALG) | |
RFC2709 |
Security Model with Tunnel-mode IPsec for NAT Domains | |
RFC2962 |
An SNMP Application Level Gateway for Payload Address Translation | |
RFC3022 |
Traditional IP Network Address Translator (Traditional NAT) | |
RFC3027 |
Protocol Complications with the IP Network Address Translator (NAT) |
NAT WG meeting minutes - 50th IETF - Minneapolis, MN - March 20, 2001, 14:15
=========================================================================
Chairs: Pyda Srisuresh - srisuresh@yahoo.com
Matt Holdrege - matt@ipverse.com
Scribed by Daniel Senie
--------------------------------------------------------------------------------
AGENDA:
1. NAT MIB draft - Rajiv, Rohit & Nalin - 20 mins.
<draft-ietf-nat-natmib-00.txt>
2. NAT friendly design Guidelines draft - 10 mins.
<draft-ietf-nat-app-guide-04.txt>
(Ready for WG last call? )
3. NAT interface framework draft - 10 mins.
<draft-ietf-nat-interface-framework-02.txt>
(Ready for WG last call? )
4. WG current status & Revised milestones - 10 mins.
5. Miscellaneous - 10 mins.
<draft-ietf-nat-natmib-00.txt>
Suresh covered the NAT MIB overview on behalf of the authors.
MIB in 3 groups:
* configuration group, covering NAT configuration.
* BIND group, covering BINDs and sessions.
* Statistics group, covering NAT statistics.
(See overheads for the details)
Open Issues:
* Notification not covered yet.
* Should the MIB be made extensible to cover IP protocols other than TCP and UDP?
Suresh(commenting on the second open item): We should try to keep the MIB under control. TCP/UDP/ICMP are the primary items. We should be careful about extending beyond. Suggest scoping the MIB to just those protocols.
There were no comments from the group.
Matt: Should we consider a separate MIB for the ALGs (or) should be extend NAT MIB to include MIB for ALGs?
Suresh: ALG MIB should probably be independent. Not sure, if it is a good idea to extend NAT MIB for ALGs.
<draft-ietf-nat-app-guide-04.txt>
Daniel spoke briefly to ask for any final comments.
No comments from the floor.
Suresh said he would meet off-line and provide some feedback and suggest text to include on peer-to-peer connectivity.
Chairs said the draft will be sent for WG last call, right after the meeting.
<draft-ietf-nat-interface-framework-02.txt>
Suresh presented the slides.
There has been some interface with the MIDCOM work group.
So Suresh reworked his slides a bit to orient the information in that direction.
The draft Provides the ability to externalize NAT middlebox
ALG processing and resource control.
The draft provides the following types of interface:
* Session-oriented, Service-neutral interface
* Asynchronous Call-back from NAT middlebox to ext. agents.
* NAT service specific interface
- to manage BINDs and NAT specific session parameters.
(See overheads for the details)
Suresh asked for comments. No comments from the floor.
Chairs said the draft will be sent for WG last call, right after the meeting, when the next rev of the draft is ready.
<WG current status & Revised milestones>
We reviewed the milestones and the only question was about RSIP.
The Chairs noted that all RSIP drafts were approved by IESG for publication as Experimental RFC's. They are in queue with RFC Editor/IANA.
The Chairs noted that MIB draft is the major remaining work item.
The App-guide and interface-framework will be going to WG last call shortly.
Architecture of the NAT-MIB
Framework for interfacing with NAT