Behavior Engineering for Hindrance Avoidance (behave)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional BEHAVE Web page

Last Modified: 2007-10-05

Additional information is available at tools.ietf.org/wg/behave

Chair(s):

  • Dan Wing <dwing@cisco.com>

    Transport Area Director(s):

  • Magnus Westerlund <magnus.westerlund@ericsson.com>
  • Lars Eggert <lars.eggert@nokia.com>

    Transport Area Advisor:

  • Magnus Westerlund <magnus.westerlund@ericsson.com>

    Mailing Lists:

    General Discussion: behave@ietf.org
    To Subscribe: behave-request@ietf.org
    In Body: In Body: subscribe
    Archive: http://www1.ietf.org/mail-archive/web/behave/current/index.html

    Description of Working Group:

    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 describe 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.

    This working group proposes to generate requirements documents and best
    current practices to enable NATs 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 NAT
    behavior practices will be application independent.

    The group will also advise on how to develop applications that
    discover and reliably function in environments with NATs that follow
    the best current practices identified by this working group. This will
    include the development of protocol-independent toolkits usable by
    application protocols for NAT traversal. This will include a revision
    of RFC 3489 for NAT binding discovery and a relay protocol that
    focuses on security.

    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 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.

    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 IPv6 relay protocol 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
    Oct 2007  Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG
    Dec 2007  Submit standards-track IPv6 relay protocol
    Dec 2007  Submit standards-track relay protocol
    Jan 2008  Submit experimental document that describes how an application can determine the type of NAT it is behind
    Jan 2008  Close WG or recharter

    Internet-Drafts:

    Session Traversal Utilities for (NAT) (STUN) (116321 bytes)
    IP Multicast Requirements for a Network Address (and port) Translator (NAT) (37636 bytes)
    NAT Behavioral Requirements for TCP (50576 bytes)
    Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (93914 bytes)
    Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition (15512 bytes)
    NAT Behavioral Requirements for ICMP protocol (57719 bytes)
    State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) (81388 bytes)
    NAT Behavior Discovery Using STUN (67814 bytes)
    Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations (17552 bytes)
    Test vectors for STUN (12345 bytes)

    Request For Comments:

    Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (RFC 4787) (68693 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.