Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
Note: This ballot was opened for revision 12 and is now closed.
(Jari Arkko) Yes
(David Harrington) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
Alexey Melnikov No Objection
3.4. Determining the Incoming tuple The NAT64 MUST handle fragments. In particular, NAT64 MUST handle fragments arriving out-of-order , conditioned on the following: * The NAT64 MUST limit the amount of resources devoted to the storage of fragmented packets in order to protect from DoS attacks. I think these 2 requirements are slightly in conflict, as an implementation claiming compliance can claim to never have resources, which means that support for fragments is truly optional. 220.127.116.11. Rules for Allocation of IPv4 Transport Addresses for UDP In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but MAY be in use in MAY here is not an implementation choice, so the use of MAY is not appropriate. I suggest changing this to "can". the other BIB (referring to the UDP and TCP BIBs). s/UDP/ICMP ? (Similar text in Section 18.104.22.168).
(Tim Polk) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
1. Please provide an informational reference to RFC 5245 for ICE, and expand the term on first use. 2. Please provide an informational reference to RFC 5389 for STUN, and expand the term on first use. 3. Among the contributors, Simon Parreault's last name is in fact Perreault.