1. draft-ietf-behave-nat-00 NAT/Firewall Behavioral Requirements draft-ietf-behave-nat-00 François Audet - audet@nortelnetworks.com Cullen Jennings - fluffy@cisco.com

2. draft-ietf-behave-nat-00 Status Working Group Document Last version was draft-audet-nat-behave-00 presented at IETF 60 Integrates decisions made in IETF 60 on mailing list since then Presentation also describes new mailing list discussion concensus reached after current text was submitted No major outstanding issue

3. draft-ietf-behave-nat-00 Changes to Scope Covers only NAT –Firewall out-of-scope: only “inherent filtering aspects of NAT” is in-scope Covers only UDP Unicast –UDP Multicast in separate document –TCP Behavior to be in a separate document “Application” aspects still out-of-scope (but very important!)

4. draft-ietf-behave-nat-00 IP address assignment Multiple IP addresses on external side of NAT IP address pooling: –“Arbitrary”: MUST NOT (REQ-2a) –“Paired, strict”: MAY (REQ-2b) –“Paired, best-effort”: RECOMMENDED (REQ-2) Required for gaming and other protocols that don’t negotiate IP address for RTP/RTCP separately Minimize port exhaustion

5. draft-ietf-behave-nat-00 RTCP=RTP+1 No requirement to attempt to preserve the Port contiguity rule Mailing list consensus for new text for next release: –Explaining that techniques currently used (sequential assignment, port reservation) have significant issues with glare and/or is wasteful for non-RTP UDP packets. –OK with Magnus Westerlund (AVT): RTSP impact –Separate negotiation must be done by application (out- of-scope of this document, but very important for application document).

6. draft-ietf-behave-nat-00 Source Port Range Well-known (0-1023), Registered (1024-49151), Dynamic/Private (49152-65535) Current text: MUST NOT use Well-known (REQ-3c) Mailing list discussion: –Some applications will break with this (RFC 2623) Mailing list agreement for next version: –If the host's source port was in the range 0-1023, the NAT's source port MUST also be in the same range. If the host's source port was in the range 1024-65535, the NAT's source port MUST also be in that range. (REQ-3c) Everybody OK with this?

7. draft-ietf-behave-nat-00 Port Parity Preservation Port Parity Preservation Behavior –“Yes, best effort”: RECOMMENDED (REQ 4) –“Yes, strict”: MAY (REQ-4a) –“No”: MUST NOT (REQ-4b) Respect RTP/RTCP parity convention when possible, without running out of ports unnecessarily Some RFC 3550 has some wording that may cause applications to unilaterally subtract 1 to an odd RTP port Reasonable and Simple to implement

8. draft-ietf-behave-nat-00 Binding refresh direction Outbound Refresh = True: MUST (REQ-6) –No change Inband Refresh = True: MAY (REQ-6a) –To allow for multicast, described in new document (i.e., no conflict between 2 document)

9. draft-ietf-behave-nat-00 Fragmentation New text provided by Dan Wing –Much clearer than old text MUST support fragmentation of packets larger than link MTU (REQ-13) MUST support receiving in order fragments, so MUST be RF=O or RF=OO (REQ-14) MAY support receiving out of order fragments and be RF=OO (REQ-14a)

10. draft-ietf-behave-nat-00 ALGs Current text: –A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec (REQ-10) –Any NAT ALG for SIP MUST be turned off by default (REQ-10a) Mailing list discussion consensus text for next version: –If a NAT includes ALGs, all of those ALGs MUST be disabled by default. (REQ-10) –If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. (REQ- 10a) –IPsec is not relevant to UDP –Stronger stance against ALGs being “off” by default

11. draft-ietf-behave-nat-00 Open issues Do we need an explicit REQ for the “don’t attempt to fix RTCP=RTP+1 rule because you’ll break more things!”? –Or is explanatory text enough? Others?