Behavior Engineering for Hindrance Avoidance (behave)

Last Modified: 2008-12-16

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

Chair(s):

  • Dan Wing <dwing@cisco.com>

  • Dave Thaler <dthaler@microsoft.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://www.ietf.org/mail-archive/web/behave

    Description of Working Group:

    The behavior of NATs varies 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 applications where one or both end-points are behind a NAT, such
    as multiuser games, interactive multimedia and P2P download.

    The working group documents best current practices to enable NATs to
    function in as deterministic a fashion as possible. The NAT
    behavior practices will be application independent. This has already
    completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP
    and any additional protocol deemed necessary to handle. The WG has
    documented approaches for characterizing and testing NAT devices.

    BEHAVE will develop protocol-independent toolkits usable by application
    protocols for NAT traversal. The WG has already produced an update of
    the binding discovery protocol STUN. It will now produce a relay
    protocol that focuses on security that is usable with both IPv4 and
    IPv6, and capable of relaying between the two IP versions.

    The goal of this work is to encourage migration to IPv6. 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.

    The BEHAVE WG will design solutions for the following four translation
    scenarios; other scenarios are out of scope:

    1. An IPv6 network to IPv4 Internet, i.e. perform translation between
    IPv4 and IPv6 for packets in uni- or bi-directional flows that are
    initiated from an IPv6 host towards an IPv4 host. The translator
    function is intended to service a specific IPv6 network of arbitary
    size. Port translation is necessary on the IPv4 side for efficient
    IPv4 address usage.

    2. IPv6 Internet to an IPv4 network, i.e. perform translation between
    IPv4 and IPv6 for packets in uni- or bi-directional flows that are
    initiated from an IPv6 host towards an IPv4 host. The translator
    function services is intended to service a specific IPv4 network
    using either private or public IPv4 addresses. Because this scenario
    has different constraints compared to (1), e.g. the IPv4 hosts that
    are to be reachable over IPv6 can be enumerated. The WG should
    attempt to design a simpler solution with less impact on
    applications.

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

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

    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 fundamental parts of ICMP are also required to work.
    Additional protocols directly on top of IP may be supported. Translation
    mechanisms must handle IP fragmentation.

    The translators should support multicast traffic and its control traffic
    (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any
    Source Multicast (ASM). However, the WG may determine that it becomes
    too complex or too difficult to realize with maintained functionality,
    for some or all cases of multicast functionality.

    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.

    DNS is a crucial part in making a large number of applications work
    across a translator. Thus the solution to the above translation cases
    shall include recommendations for DNS. If additional DNS functionality
    is needed, it may be developed. Any DNS extensions must be developed
    together with the DNSEXT WG, including issuing a joint WG last call for
    any documents.

    The WG needs to determine the best method for providing address space to
    a translator in the different deployment cases and documenting the pros
    and cons of the suggested approaches. The WG is to seek input from the
    Routing, Operations and Internet areas.

    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
    Dec 2008  Submit BCP document for SCTP NAT behavior
    Dec 2008  Submit standards-track relay protocol
    Jan 2009  Determine relative prioritization of the four translation cases.
    Mar 2009  Submit standards-track document for relaying of a TCP bytestream
    Mar 2009  Submit standard-track document of an IPv6 relay protocol to IESG
    Mar 2009  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.
    Sep 2009  Target for first solution to be submitted to IESG for publication as standards track RFC.

    Internet-Drafts:

    Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (202268 bytes)
    Traversal Using Relays around NAT (TURN) Extension for IPv6 (23919 bytes)
    NAT Behavior Discovery Using STUN (76172 bytes)
    Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations (26576 bytes)
    Test vectors for STUN (16697 bytes)
    Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol (21697 bytes)
    Stream Control Transmission Protocol (SCTP) Network Address Translation (48666 bytes)
    Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers (22187 bytes)
    IP/ICMP Translation Algorithm (53002 bytes)
    DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers (60470 bytes)

    Request For Comments:

    Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (RFC 4787) (68693 bytes)
    IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) (RFC 5135) (36528 bytes)
    State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) (RFC 5128) (81008 bytes)
    NAT Behavioral Requirements for TCP (RFC 5382) (50306 bytes)
    Session Traversal Utilities for NAT (STUN) (RFC 5389) (125650 bytes) obsoletes RFC 3489
    NAT Behavioral Requirements for ICMP (RFC 5508) (67985 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.