Here is a preliminary BOF request that I've put together for a NAT66- related BOF at IETF 74. I'm sending it to all four of the Internet and Transport ADs, as I am not sure it has been decided which area would be the best home for this work.
Thoughts or comments on this BOF proposal? Margaret
IPv6 Address Independence (6AI) BOF =================================== Chairs: TBD Reponsible AD: TBD Mailing List: [email protected] To Subscribe: https://www.ietf.org/mailman/listinfo/nat66 Archive: http://www.ietf.org/mail-archive/web/nat66 Duration: 2-1/2 hours Expected Attendance: > 100 SUMMARY ======= As discussed in RFC 4864: "Local Network Protection for IPv6", Network Address Translation (NAT) offers a number of benefits for IPv4 networks, at the cost of certain limitations. In the opinions of many home, small office and enterprise network administrators, the benefits of IPv4 NAT have apparently outweighed the limitations, resulting in the widespread deployment of IPv4 NAT. Some of the IPv4 NAT benefits, such as the need to share globally routable addresses to conserve address space ("Address Amplification"), do not apply to IPv6 as it is defined and deployed today. However, IPv6 networks could benefit from some of the other properties of IPv4 NAT discussed in RFC 4864, such as "Simple Security", "Address Autonomy" and "Topology Hiding". Most home networks use IPv4 NAT because it is sold to them (or provided by their ISP) as part of an integrated home gateway solution that combines Address Amplification, Simple Gateway and Simple Security features. There are better ways to provide this functionality in IPv6 that result in fewer limitations and greater flexibility than a NAT-based solution, and the IETF should document and advocate such a solution. However, it seems that IPv4 NAT is used for different reasons in enterprise networks. In many cases, enterprises that have plenty private of IPv4 address space (from "swamp space" allocations) choose to deploy NAT for its other benefits, most notably the "Address Independence", "Simple Security", "Topology Hiding" and "Renumbering and Multihoming" benefits described in RFC 4864. We don't have well-understood and readily available ways to obtain all of these benefits in IPv6 without the use of NAT, and deploying the partial solutions we do have would be considerably more complex than deploying an IPv6 NAT box (or three). So it is expected that many of these network administrators will request, obtain and deploy NAT devices for their IPv6 networks. When IPv4 NATs were initially deployed, there were no standards regarding how NAT boxes should function. This lead to a wide diversity in NAT functionality, which greatly complicated the design and implementation of transport protocols and application protocols. The BEHAVE WG has done excellent work to retroactively classify existing NAT functionality, to make recommendations to improve IPv4 NAT implementations, and to design mechanisms to traverse IPv4 NAT devices. However, we are still dealing with the complexity inherent in supporting a diverse set of IPv4 NAT devices. In order to minimize the damage caused by the introduction of NAT devices in the IPv6 network, the IETF should standardize an IPv6 NAT mechanism that provides the benefits of IPv4 NAT that are required by enterprise network adminstrators, while minimizing the impact on transport layer and application layer protocols. An initial standard could focus on the most common and well-understood NAT requirements: Address Independence, with the provider-independence and renumbering benefits. In parallel, work could be done to better understand the Topology Hiding and Multihoming requirements, to see if we could recommend or specify an IETF solution to those problems that would be superior to the use of port-mapping NATs. Therefore, it is the purpose of this BOF to discuss the formation of an IETF WG to produce the following work items: 1) A Best Current Practices (BCP) RFC describing how to obtain the Simple Gateway and Simple Security features of NAT without performing address translation. This document is intended for home gateway manufacturers and other standards bodies that define home gateway functionality. 2) A Standards-Track (PS) RFC that describes an IPv6 Network Address Translation mechanism that provides the Simple Security and Address Independence benefits of IPv4 NAT, while minimizing the problems caused by IPv4 NAT. This solution is expected to involve a one-to-one, algorithmic address mapping mechanism with no port mapping. It may or may not include a checksum-neutral mapping algorithm and/or a cryptographic mapping mechanism. 3) Updates to the BEHAVE mechanisms (STUN, TURN, etc.), if needed, to allow applications to successfully traverse IPv6 NAT devices, as defined in (2). Alternatively, this work could be chartered in BEHAVE and done in consultation with this group. 4) An Informational RFC that describes the enterprise network requirements for Topology Hiding and Multihoming that are currently met by IPv4 NAT devices. Once these requirements are well-understood, the WG may be rechartered to work on NAT-based or non-NAT-based solutions to these problems. AGENDA ====== - Administrivia (Chairs, 5 min) - Purpose of BOF (Chairs, 10 min) [see above] - Presentation of NAT Benefits/IPv6 Solutions & Gaps from RFC 4864 (??, 20 min) > Home Gateway Requirements > Enterprise Requirements - Solution Proposals (20 - 40 min) > NAT66 (Margaret Wasserman) > Other? (??) - Proposed Charter (Chairs, 10 min) - Discussion of Proposed Charter/WG Formation (All, 45 min) - Questions/Next Steps (Chairs, 15 min)
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
