Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
RFC 6146

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

Comment (2010-08-11)
No email
send info
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.


3.5.1.1.  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 3.5.2.3).

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2010-08-11)
No email
send info
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.

(Sean Turner) No Objection