Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Working Group Chair(s): Dan Wing Dave Thaler Transport Area Director(s): David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: David Harrington Mailing Lists: General Discussion:behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The working group creates documents to enable NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will adopt additional work items to finish four scenarios: An IPv6 network to IPv4 Internet, IPv6 Internet to an IPv4 network, An IPv6 network to an IPv4 network, and An IPv4 network to an IPv6 network. These additional work items include suggestions to application developers to improve application interactions with those translation scenarios. The following scenario remains in scope for discussion, and new milestones can be created to address this scenario: * An IPv4 application running on an IPv6-only connected host to the IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is embedded in the IPv4 host. The following scenarios remain in scope for discussion, but creating new milestones will require re-chartering: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. * multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Done Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: relaying of a TCP bytestream (std) Done Submit to IESG: relay protocol (std) Done Submit to IESG: TURN-URI document (std) Done Submit to IESG: IPv6 relay protocol (std) Done Submit to IESG: framework for IPv6/IPv4 translation (info) Done Submit to IESG: stateless IPv6/IPv4 translation (std) Done Submit to IESG: stateful IPv6/IPv4 translation (std) Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Done Determine need and scope of multicast 6/4 translation Oct 2010 Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Dec 2010 Submit to IESG: large scale NAT requirements (BCP) Feb 2011 Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info) Apr 2011 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Apr 2011 Submit to IESG: SCTP NAT behavior (BCP) Apr 2011 Submit to IESG: NAT64 load balancing (std/info) Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2010 Jan 2012 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) Oct 2010 Nov 2011 Common requirements for Carrier Grade NATs (CGNs) Jan 2011 Dec 2011 Analysis of Stateful 64 Translation May 2011 Dec 2011 Analysis of solution proposals for hosts to learn NAT64 prefix May 2011 Jan 2012 Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC4787BCP Jan 2007 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP RFC5135BCP Feb 2008 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) RFC5128 I Mar 2008 State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) RFC5382BCP Oct 2008 NAT Behavioral Requirements for TCP RFC5389 PS Oct 2008 Session Traversal Utilities for NAT (STUN) RFC5508BCP Apr 2009 NAT Behavioral Requirements for ICMP RFC5597BCP Sep 2009 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol RFC5766 PS Apr 2010 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) RFC5769 I Apr 2010 Test Vectors for Session Traversal Utilities for NAT (STUN) RFC5780 E May 2010 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) RFC5928 PS Aug 2010 Traversal Using Relays around NAT (TURN) Resolution Mechanism RFC6052 PS Oct 2010 IPv6 Addressing of IPv4/IPv6 Translators RFC6062 PS Nov 2010 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations RFC6144 I Apr 2011 Framework for IPv4/IPv6 Translation RFC6145 PS Apr 2011 IP/ICMP Translation Algorithm RFC6146 PS Apr 2011 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers RFC6147 PS Apr 2011 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers RFC6156 PS Apr 2011 Traversal Using Relays around NAT (TURN) Extension for IPv6 RFC6384 PS Oct 2011 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation