2.7.2 Behavior Engineering for Hindrance Avoidance (behave)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-28


J Kuthan <jiri@iptel.org>
Cullen Jennings <fluffy@cisco.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: ietf-behave@list.sipfoundry.org
To Subscribe: ietf-behave-request@list.sipfoundry.org
In Body: with subscribe in body
Archive: http://list.sipfoundry.org/archive/ietf-behave

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

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. 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
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
prop osed 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
in the internet architecture. Discussion will start from several
existing drafts or RFCs, including:

RFC 3489

Goals and Milestones:

Mar 05  Produce a BCP document that describes the usage of protocols like STUN for performing black-box testing and characterizing NAT behavior
May 05  Produce a BCP that defines unicast UDP behavioral requirements for NATs
Jul 05  Any revisions to STUN required by other WG deliverables
Sep 05  Produce a BCP that defines TCP behavioral requirements for NATs
Nov 05  Produce a BCP that defines basic ICMP behavioral requirements for NATs
Dec 05  Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches
Jan 06  Close WG or recharter


  • draft-ietf-behave-rfc3489bis-02.txt
  • draft-ietf-behave-nat-udp-03.txt
  • draft-ietf-behave-multicast-00.txt

    No Request For Comments

    Current Meeting Report

    Behave WG IETF63, Tuesday 2-Aug-2005

    Scribe: Paul Kyzivat


    Presented by Francois Audet

    Discussed status and changes. There were two open issues: 

    1.     Removal of Section 5.2. 

    Final Resolution: Approved.

    2.     In new REQ-7 (a) there is debate whether to use MAY or SHOULD in: the filtering behavior {MAY/SHOULD} be an option configurable by the administrator of the NAT. Brian Ford advocated SHOULD, Cullen Jennings advocated MAY. 

    Cullen said applications can’t depend on this favor anyway, so no point in requiring it. 

    Paul Hoffmann noted that SHOULD must include the rationale when it can be violated, and he thought that may be hard to do in this case. 

    Jon Peterson thought there was confusion regarding the target for this requirement – a NAT builder or administrator. 

    Brian said just having the option is helpful for self organizing peer-to-peer systems where some of the nodes need to be super nodes that require special NAT behavior. He postulated that the objection to SHOULD was that some NAT vendors might object to meeting it. He asked if there were NAT vendors in the room that could answer, but none did. 

    Jon asked for anybody other than Brian in favor of SHOULD to respond. Nobody did. 

    Someone from Juniper (I didn’t catch who) spoke as a NAT vendor.  He said they are concerned about security in their NAT, and that if they were convinced to implement the option they would strongly encourage customers not to enable it. 

    Final resolution: this stays a MAY.

    Other discussion on the draft:

    Dan Wing suggested that maybe the document should be targeted at application developers (what they should expect) rather than what NAT vendors should do. 

    Brian Ford brought up an issue regarding fragmented UDP packets. He said some operating systems routinely send fragmented packets out of order, and this breaks applications. This was identified as a change from a MAY to a MUST in Requirement 13. Cullen claimed it is impossible because it opens up DOS attacks. Dave Oran said there is no DOS attack if reassembly of fragmented packets is done right. (By reserving a fixed number of reassembly buffers and only doing reassembly when a buffer is available.) 

    Final resolution: Agreed in principle to this change pending a write-up by Brian Ford.

    Brian brought up another issue: Twice NAT is becoming a big issue. Almost all consumer NATs use DHCP to obtain their IP address. If this gets an address from another NAT, then the downstream and upstream addresses could end up the same. Some NATs have been observed to fail in this case. He requested language that NAT vendors be sure to cope with this. There was some question of whether use of twice NAT is increasing or decreasing. However no one in the room had first hand knowledge of this situation – only hearsay. 

    Final resolution: Brian and Cullen will come up with wording to address this.

    Brian had an issue regarding document organization. 

    Final Resolution: Paul Hoffman said that can be done by chairs and AD – it doesn’t require consensus. 

    Brian had another issue about terminology and wanted to talk about the adoption of gen draft and overall organization of documents. Jon Peterson thought it appropriate to discuss this. 

    Brian complained he hasn’t had a hearing on all the documents he has tried to offer. Jon Peterson thought this has had ample hearing on the list. The room was polled for others agreeing with Brian. No one responded, so Brian agreed to drop his objections. 

    The end of the meeting was then at hand so there was no time to discuss other documents.


    NAT Behavioral Requirements for Unicast UDP
    General Issues Affecting Multiple Working Group Drafts