Az RFC4787 követelményeire a következőket tudom írni:
REQ 1. A netfilter a cím és port független mappeléshez áll a legközelebb. Ha a "random" kapcsoló be van kapcsolva a NAT targeteknél, akkor mindíg. Ha nincs, akkor csak abban az esetben, ha az egyértelmű mappelés azt megköveteli (egyébként végpont független). Pl. az RFC4787 jelölését használva, amikor két kapcsolatról van szó (X1,x1) -> (Y, y) és (X2,x1) -> (Y, y) paraméterekkel, azaz két kliens ugyanahhoz a szerverhez, ugyanazon forrásporttal akar kapcsolódni: az egyértelműség érdekében az egyiket át kell mappelni és ezért csak a cím és port független mappelés jöhet szóba, az is történik.
REQ 2. Ha a NAT-nál egy poolból lehet válogatni, akkor SNAT/DNAT esetén a "least load" alapján történik a címkiválasztás, ami inkább "random", és semmi esetre sem "paired". A NETMAP target esetében egyértelműen fix IP címre történik a NAT-olás, vagyis "paired".
REQ 3. Nincs port overloading, és a netfilter megpróbálja a 0-512, 513-1023, 1024-65535 tartományokban tartani a mappelt portot.
REQ 4. Nem őrzi meg a port paritást és nincs port kontinuitás.
REQ 5. Az UDP timeout default három perc (az RFC4787 legalább két percet követel meg és öt percet javasol), konfigurálható.
REQ 6. A NAT mappelés időzítője frissül, akár kifelé, akár befelé megy csomag.
REQ 7. Az ütköző külső-belső IP címek elkerülése nem a netfilter dolga, hanem azé, aki/ami konfigurája.
REQ 8. Cím és port függő a válaszcsomagok elfogadása.
REQ 9. Nincs hairpinning, semmilyen formában.
REQ 10. A protokoll helperek modulként nem töltődnek be automatikusan.
REQ 11. A netfilterben implementált NAT nem determinisztikus az RFC4787 terminológiája szerint (azaz, ha szükséges, elkerüli az ütközést és átmappeli a forrás portot). Megjegyzem, roppant vicces, hogy az RFC semmit nem mond arról, ugyan mit kellen tenni az ütközések elkerülése érdekében. Inkább utasítsa vissza a kapcsolatot a tűzfal?
REQ 12. Ha úgy van konfigurálva (RELATED), akkor a netfilter átengedni a kapcsolatoknak megfelelő ICMP hibaüzeneteket.
REQ 13. Ez nem a NAT, hanem az IP stack dolga és a Linux rendben küld ICMP Frag needed csomagot UDP esetén is.
REQ 14. A netfilter conntrack defragmentál, vagyis a fragmentek érkezési sorrendje érdektelen a NAT számára.
Az RFC4787-t láthatóan az alkalmazásírók szemszögéből fogalmazták meg. És csak megerősít abban, hogy teljesen igazunk van amikor azt mondjuk, hogy sosem fogunk IPv6 NAT-ot implementálni.