Okay, here is the abstract and summary for RFC 4787 based on the provided transcript text.
Abstract:
RFC 4787, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", defines standardized terminology and a set of Best Current Practice (BCP) requirements for Network Address Translators (NATs) handling Unicast UDP traffic. The primary goal is to improve the consistency and predictability of NAT behavior, thereby increasing the likelihood that applications sensitive to NAT traversal issues, such as peer-to-peer multimedia communications (VoIP) and online gaming, will function correctly without requiring UDP relays. The document addresses the wide variability in existing NAT implementations by specifying desired behaviors for key functions including address and port mapping, filtering rules, mapping timeouts and refresh mechanisms, hairpinning, ICMP message handling, and IP fragmentation. It focuses on Traditional NATs (including NAPT) operating over IPv4 and provides specific recommendations aimed at NAT vendors to foster more application-friendly network environments.
Summary of NAT Behavioral Requirements for Unicast UDP (RFC 4787):
Section 1: Applicability: The document targets Traditional NATs (Basic NAT and NAPT) of all sizes, defining requirements to improve compatibility for Unicast UDP applications like VoIP and gaming. It excludes ALGs (mostly), signaled middlebox control, UDP relays, and application-specific aspects.
Section 3: Terminology: Adopts RFC 2119 keywords (MUST, SHOULD, etc.) and refers to RFC 2663 for basic NAT terms. It introduces specific behavioral terms (e.g., "Endpoint-Independent Mapping") finding previous STUN terminology ("Cone", "Symmetric") inadequate.
Section 4.1: Address and Port Mapping (REQ-1, REQ-2):
REQ-1: NATs MUST use "Endpoint-Independent Mapping", meaning the same external IP:port is reused for subsequent packets from the same internal IP:port, regardless of the destination.
REQ-2: For NATs with multiple external IPs, it is RECOMMENDED to use "Paired" IP address pooling, assigning the same external IP for all sessions from the same internal IP.
Section 4.2: Port Assignment (REQ-3, REQ-4):
REQ-3: NATs MUST NOT use "Port overloading" (forcing port preservation even on collision). It is RECOMMENDED to preserve the port range (0-1023 vs 1024-65535) if possible.
REQ-4: It is RECOMMENDED that NATs preserve port parity (mapping even internal ports to even external ports, and odd to odd) to aid RTP/RTCP compatibility with older implementations.
Section 4.3: Mapping Refresh (REQ-5, REQ-6):
REQ-5: UDP mapping timers MUST NOT expire in less than 2 minutes (default RECOMMENDED >= 5 minutes). Shorter timers MAY be used for specific well-known ports. Timer MAY be configurable.
REQ-6: Mappings MUST be refreshed by outbound traffic. Mappings MAY be refreshed by inbound traffic (with security caveats).
Section 4.4: Conflicting Address Spaces (REQ-7):
REQ-7: NATs with dynamic external IP configuration MUST either automatically avoid using internal RFC1918 ranges that conflict with the external range, or be able to correctly translate traffic even when conflicts exist.
Section 5: Filtering Behavior (REQ-8):
REQ-8: Recommends "Endpoint-Independent Filtering" (allows inbound from any source once mapping exists) for transparency, or "Address-Dependent Filtering" (allows inbound only from IPs previously sent to) for stricter security. Filtering MAY be configurable.
Section 6: Hairpinning Behavior (REQ-9):
REQ-9: NATs MUST support "Hairpinning", allowing two internal hosts to communicate via their external mapped addresses. The source address presented to the receiving internal host MUST be the external mapped address of the sending internal host.
REQ-10: ALGs for UDP protocols SHOULD be turned off by default to avoid interference with modern NAT traversal techniques. It is RECOMMENDED that ALGs be individually configurable by the administrator.
Section 8: Deterministic Properties (REQ-11):
REQ-11: NATs MUST behave deterministically; mapping and filtering rules MUST NOT change based on load or conflict situations without explicit configuration changes.
Section 9: ICMP Handling (REQ-12):
REQ-12: Receiving ICMP messages MUST NOT terminate a UDP mapping. NATs SHOULD NOT filter incoming ICMP based on source IP by default. It is RECOMMENDED that NATs process and forward ICMP Destination Unreachable messages.
Section 10 & 11: Fragmentation (REQ-13, REQ-14):
REQ-13: For outgoing packets too large for MTU: If DF=1, MUST send ICMP "Fragmentation Needed". If DF=0, MUST fragment the packet (SHOULD send fragments in order).
REQ-14: NATs MUST support receiving and correctly processing incoming IP fragments, even if they arrive out of order. Must implement safeguards against fragmentation-based DoS attacks.
Section 13: Security Considerations: Discusses security tradeoffs and implications related to inbound refresh, filtering strictness, determinism, and fragmentation handling.