Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
RFC 4787

Note: This ballot was opened for revision 08 and is now closed.

(Lisa Dusseault) Yes

Comment (2006-05-18 for -)
No email
send info
I asked if any other documents should be normative references,if only UDP

(Lars Eggert) Yes

Comment (2006-05-22 for -)
No email
send info
Section 1., para. 3:

>    This document is meant to cover NATs of any size, from small
>    residential NATs to large Enterprise NATs.  However, it should be
>    understood that Enterprise NATs normally provide much more than just
>    NAT capabilities: for example, they typically provide firewall
>    functionalities.  Firewalls are specifically out-of-scope for this
>    specification; however, this specification does cover the inherent
>    filtering aspects of NATs.

        Residential NATs typically have firewalls, too. (I'd argue that
        it's probably the enterprise NATs that don't have firewalls, because
        in such deployments, the functionality is often distributed.)

>    Approaches using directly signaled control of middle boxes such as
>    Midcom, UPnP, or in-path signaling are out of scope.

        Nit: Add references for the above approaches.

>    UDP Relays are out-of-scope.

        Nit: Ditto.

Section 2., para. 4:

>    The goals of this document are to define a set of common terminology
>    for describing the behavior of NATs and to produce a set of
>    requirements on a specific set of behaviors for NATs.  The
>    requirements represent what many vendors are already doing, and it is
>    not expected that it should be any more difficult to build a NAT that
>    meets these requirements or that these requirements should affect
>    performance.

        I thought that BEHAVE was not merely trying to describe what NATs
        are doing, but - to some degree at least - what NATs should be doing.
        This wouldn't necessarily need to be the optimal NAT behavior (for
        compliance reasons of the deployed NAT base), but I thought description
        of a "good enough" behavior was the goal. Is this describing Current
        Practice or Best Current Practice?

Section 4.2.3., para. 0:

4.2.3.  Port Contiguity

        This section doesn't include a requirement like the other ones.

Section 4.3., para. 3:

>       c) A default value of 5 minutes for the NAT UDP mapping timer is
>          RECOMMENDED.

        Why not "5 minutes or longer?"

Section 17.1., para. 0:

17.1.  Normative References

        Would have expected to see some informative refs as normative, such
        as 2663, 3424, 1812, etc. (Already raised by Lisa.)

(Sam Hartman) (was Discuss) Yes

(Jon Peterson) Yes

Magnus Westerlund Yes

(Jari Arkko) No Objection

Comment (2006-05-25 for -)
No email
send info
I would like to support Lars' suggestion that the
recommended 5 minute lifetime be changed to at least
5 minutes.

The reason that I'm concerned with this relates
to wireless media, particularly battery powered
devices and protocols that need to stay connected
even in idle mode through NAT keepalives. Frequent
keepalives consume battery power and consume overall
wireless bandwidth (if you do the math, the effect
can in some cases be dramatic). So I'd really like
us to make recommendations that make life easier
in these situations. At the very least, lets not
make a recommendation that might force someone's
NAT to lower the lifetime merely due to be
compliant with this document.

(Is there a reason why the lifetimes have to
be fixed, as opposed to determined on a
dynamic basis based on the need to allocate
new ports?)

Also, I'd be interested in hearing how much
discussion there was in the WG about this particular
lifetime value, and whether the chosen value is
supported by data that we have from the real world.


> This document only covers the UDP Unicast aspects of NAT traversal
> and does not cover TCP, IPSEC, or other protocols.  Since the
> document is for UDP only, packet inspection above the UDP layer

... IPsec (except maybe when carried in UDP) ...

> STUN [17]
> describes a UNilateral Self-Address Translation (UNSAF) mechanism
> [15].

This should be Self-Address Fixing.

> and make it easer to discuss and predict NAT behavior in


(Ross Callon) (was Yes) No Objection

(Brian Carpenter) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Russ Housley) No Objection

Comment (2006-05-24 for -)
No email
send info

  s/IANA- registered/IANA-registered/

(Dan Romascanu) No Objection

(Mark Townsley) (was Discuss) No Objection

Comment (2006-10-02)
No email
send info
Please include references to requirements in this section as suggested below:

> 13.  Security Considerations

>    This work recommends that the timers for mapping be refreshed only on
>    outgoing packets and does not make recommendations about whether or
>    not inbound packets should update the timers.  If inbound packets

insert reference to REQ-6.

>    This work recommends that the NAT filters be specific to the external
>    IP only and not to the external IP and port.  It can be argued that

IP _address_, please. Also add a reference to REQ-8.

>    this is less secure than using the IP and port.  Devices that wish to
>    filter on IP and port do still comply with these requirements.

(David Kessens) (was Discuss) Abstain

(Cullen Jennings) Recuse