BEHAVE BOF (Behavior Engineering for Hindrance AVoidancE) Cullen Jennings Jiri Kuthan

NOTE WELL Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: the IETF plenary session, any IETF working group or portion thereof, the IESG, or any member thereof on behalf of the IESG, the IAB or any member thereof on behalf of the IAB, any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details.

Agenda Scribe? Agenda bashing (5 min.) Problem Statement, Scope, and Charter (30 min.) Behavior Recommendations (15 min.) draft-audet-nat-behave-00.txt Summary and conclusions (10 min.)

Problem Very large deployment of NATs in public internet Inconsistent behavior Difficult to detect or predict behavior Contributes to problems and difficulty of deployment of end to end applications

Proposal Consider what is broken Generate a BCP to enable vendors to build NATs with appropriate behavior Consider how to characterize and test NATs Advise application developers on how to reliably function in environments with conforming NATs Done is a way consistent with UNSAF and transition to IPv6

Goals & Milestones Jan 05 –produce a BCP document that describes the usage of protocols like STUN for performing black- box testing and characterizing NAT behavior Mar 05 –produce a BCP that defines behavioral requirements for NATs May 05 –produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches Jun 05 –Any revisions to STUN required by other WG deliverables

Proposed Charter 1 Given the current near-universal deployment of NATs (Network Address Translators) in the public Internet, the lack of standards for NAT behavior has given rise to a crisis. While it is widely acknowledged that NATs create problems for numerous Internet applications, our inability to understand precisely what a NAT is or how it behaves leaves us few solutions for compensating for the presence of NATs. The behavior of NATs varies dramatically from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end interactive applications such as multiuser games and interactive multimedia. NATs continue to proliferate and have seen an increasing rate of deployment. IPv6 deployments can eliminate this problem, but there is a significant interim period in which applications will need to work both in IPv4 NAT environments and with the IPv6 to IPv4 transition mechanisms (e.g. 6to4).

Proposed Charter 2 This working group proposes to generate requirements documents and best current practices to enable vendors of both traditional NATs and IPv6 to IPv4 transition mechanisms (e.g. 6to4) to function in as deterministic a fashion as possible. It will consider what is broken by these devices and document approaches for characterizing and testing them. The group will also advise on how to develop applications that discover and reliably function in environments with NATs and IPv6 to IPv4 transition mechanisms that follow the best current practices identified by this working group. The group will consider the security implications (or non-implications) of these devices. The work will be done with the goal of encouraging eventual migration to IPv6 and compliance with the UNSAF [RFC 3424] considerations. It will not encourage the proliferation of NATs. The behavior that will be considered includes the behavior includes IP fragmentation and parameters that impact ICMP, UDP, TCP, IGMP, MLD, and multicast. The proposed WG will coordinate with v6ops, midcom and nsis. The work is largely limited to examining various approaches that are already in use today and providing suggestions about which ones are likely to work best in the internet architecture.

Proposed Charter 3 Discussion will start from several existingdrafts or RFCs, including: draft-jennings-midcom-stun-results draft-audet-nat-behave RFC 3489 draft-ford-midcom-p2p