Skip to main content

Last Call Review of draft-ietf-behave-v6v4-xlate-stateful-
review-ietf-behave-v6v4-xlate-stateful-secdir-lc-laganier-2010-06-29-00

Request Review of draft-ietf-behave-v6v4-xlate-stateful
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-06-15
Requested 2010-06-03
Authors Philip Matthews , Iljitsch van Beijnum , Marcelo Bagnulo
I-D last updated 2010-06-29
Completed reviews Secdir Last Call review of -?? by Julien Laganier
Assignment Reviewer Julien Laganier
State Completed
Request Last Call review on draft-ietf-behave-v6v4-xlate-stateful by Security Area Directorate Assigned
Completed 2010-06-29
review-ietf-behave-v6v4-xlate-stateful-secdir-lc-laganier-2010-06-29-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

Document abstract:

   This document describes stateful NAT64 translation, which allows
   IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or
   ICMP.  The public IPv4 address can be shared among several IPv6-only
   clients.  When the stateful NAT64 is used in conjunction with DNS64
   no changes are usually required in the IPv6 client or the IPv4
   server.

Comments:

The document is a nice read and in a good shape. I have a few comments below:

Section 1.2. "Overview": Repeated use of the term "transport address" but it is
only defined later in the Terminology section 2. Suggest moving "1.2 Overview"
in its own standalone section numbered 3, just after terminology.

Section 2 describes Hairpinning and Section 3.8 specifies NAT64 support for
Hairpinning. The document states that "Hairpinning support is important for
peer-to-peer applications, as there are cases when two different hosts on the
same side of a NAT can only communicate using sessions that hairpin through the
NAT." I understand that it is important for NAT44 because only RFC1918
ambiguous address space is available for hosts behind NAT44 which can make it
impossible for host to communicate. I however do not understand why it is
needed with NAT64 where non-ambiguous IPv6 address space is available to hosts
behind the NAT64. Why would the host be able to communicate only through a
NAT64? It seems that putting an IPv6 router next to the NAT64 would avoid the
need for hairpinning NAT64. Maybe I am missing something... If there's a easy
explanation, suggest extending the terminology with it.

Section 5.2.: "To avoid this type of abuse, a NAT64 MAY keep track of the
sequence number of TCP packets in order to verify that proper sequencing of
exchanged segments, in particular, the SYNs and the FINs." => I think you mean
"in particular, those of the SYNs and the FINs." Also, it seems to me that you
want to keep track of is the whole TCP state rather than the only the sequence
numbers, i.e., whether the connection is opened, half-closed, by watching at
SYNs, RSTs and FINs.

--julien