Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
draft-ietf-behave-v6v4-xlate-stateful-12
Yes
(David Harrington)
(Jari Arkko)
No Objection
(Dan Romascanu)
(Gonzalo Camarillo)
(Ralph Droms)
(Ron Bonica)
(Sean Turner)
(Stewart Bryant)
(Tim Polk)
Note: This ballot was opened for revision 12 and is now closed.
David Harrington Former IESG member
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2010-08-11)
Unknown
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).
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2010-08-11)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown