App: Ref: Transport BEHAVE Specs

[gorryfair]

Should RFC7857 also be cited? (NAT update BCP)
Should RFC4787 also be cited? (behaviour for UDP NAT)

[mirjak]

Not sure. We cite RFC4787 in the manageability doc. In this doc we refer to RFC8085 instead which then refers to RFC4787. I'd say that's about right.

However, I'm open to add more information if people think that's helpful. If so, what more do we need to say where?

[gorryfair]

In 3.5 the ID currently states: " According to a 2010 study ([Hatonen10]), UDP
applications can assume that any NAT binding or other state entry can
expire after just thirty seconds of inactivity."
Whereas in RFC 4787 (BCP) Requirement 6 states:
" REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two
minutes, unless REQ-5a applies.
a) For specific destination ports in the well-known port range
(ports 0-1023), a NAT MAY have shorter UDP mapping timers that
are specific to the IANA-registered application running over
that specific destination port.
b) The value of the NAT UDP mapping timer MAY be configurable.
c) A default value of five minutes or more for the NAT UDP mapping
timer is RECOMMENDED."
I suggest we directly refer to this RFC before or after the above sentence, before the ID then continues in the next sentence to discuss the topic of keep alive (aka RFC8085).

[mirjak]

There was always a reference to RFC4787. Text is

{{?RFC4787}} requires a timeout that is not less than 2 minutes for most UDP traffic. However, in pratice, timers are often lower, in the range of 15 to 30 seconds.

What else should be added?

[ianswett]

I suggested changing the latter from "15 to 30 seconds" to "30 seconds to 1 minute," or something like Gorry's quote:

"According to a 2010 study ([Hatonen10]), UDP
applications can assume that any NAT binding or other state entry can
expire after just thirty seconds of inactivity."

[gorryfair]

When I review "experience" reported in OPS drafts, I usually try to avoid wording that might convey the IETF endorses the reported behaviour, rather than be aware of the reported behaviour. I suggest this is one of these cases.

So suggest a style something like:

{{?RFC4787}} requires a timeout that is not less than 2 minutes for most UDP traffic. However, protocols traversing NATs should be aware of systems using lower values, in the range of 15 to 30 seconds. A study in 2010 study ([Hatonen10]), reported that UDP applications can experience that NAT binding or other state entries expire after just thirty seconds of inactivity.

[mirjak]

There is new proposed text on this part in PR #222 - Can review and comment any proposed changes there...? @ianswett @gorryfair