On Tue, 1 Jun 2010, The IESG wrote:
- 'Stateful NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers '
<draft-ietf-behave-v6v4-xlate-stateful-11.txt> as a Proposed Standard
I've reviewed draft-ietf-behave-v6v4-xlate-stateful-11 for ops-dir.
I believe the document is ready for publication, but there are a couple
of areas where minor clarifications could improve the document.
As a general comment, spec has good detail (esp S 3.5) on how to
handle TCP, UDP and ICMP query traffic, but I did not find similar
detail on how ICMP errors sent in response to such traffic would
affect packet processing, state tables, etc.
It would be great if e.g. TCPM WG reviewed Section 3.5.2, especially its
state table and said it's OK. There could be a number of unthought-of
cornercases.
From O&M perspective, the specification appears to be sufficiently operable
and configurable in IPv6->IPv4 translation. IPv4->IPv6 translation requires
manually configured or unspecified bindings. Operationally this is not going
to be sufficiently as the management interface is unspecified and e.g. MIB
module or other configuration methods do not exist and are not in Behave WG
charter. But this issue should not delay the publication of this document
and rather should be tackled later, if needed.
The default TCP maximum session lifetime is 2 hours (from RFC5382). I
personally believe this is too small for long-lived sessions.
some detailed comments:
-----------------------
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. [...]
.. which material is potentially covered by this? While the non-WG version
was available prior to Nov 10, 2008, the authors should be able to say so.
It would be better if this disclaimer could be removed. License info is
also an older version (from id-nits checker).
In S 3.4:
If the incoming packet is an IPv6 packet that contains a protocol
other than TCP, UDP or ICMPv6 in the last Next Header, then the
packet SHOULD be discarded and, if the security policy permits, the
NAT64 SHOULD send an ICMPv6 Destination Unreachable error message
with Code 3 (Destination Unreachable) to the source address of the
received packet. NOTE: This behaviour may be updated by future
documents that define how other protocols such as SCTP or DCCP are
processed by NAT64.
.. I suppose this assumes the packet is unicast, as NAT64 is an unicast-only
specification. Nonetheless I'd suggest that somewhere (probably earlier in
the spec) you'd explicitly say about one sentence on multicast; it's
currently not mentioned at all. E.g. "A NAT64 device MUST ignore any
translation or actions when IPv4 or IPv6 destination address is a multicast
or the limited broadcast address (255.255.255.255)." (maybe with more
precise definition what to do instead.)
The same applies but more strongly to the following IPv4 paragraph. More
strongly because IPv4 spec does not allow generating ICMPv4's in response to
multicast packets while in ICMPv6 this is acceptable under certain
conditions.
NB: I see that IPv6 destination address is covered under 2nd paragraph of S
3.5 but a more explicit mention might be worthwhile.
In S 3.5.1:
* The STE destination IPv4 transport is set to (Z(Y'),y), y being
the same port as the STE destination IPv6 transport address and
Z(Y') being algorithmically generated from the IPv6 destination
address (i.e. Y') using the reverse algorithm as specified in
Section 3.5.4.
.. S 3.5.2 can hardly be said to specify any algorithm, but it certainly
doesn't even mention the reverse algorithm (however trivial it might be).
In S 3.5.2:
V4 SYN RCV: An IPv4 packet containing a TCP SYN was received by
the NAT64, implying that a TCP connection is being initiated from
the IPv4 side. The NAT64 is now waiting for a matching IPv6
packet containing the TCP SYN in the opposite direction.
...
A TCP segment with the SYN flag set that is received through the IPv6
interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6
FIN + V4 FIN, V6 RST and V4 RST.
.. this is somewhat confusing because you appear to be using "V4 SYN RCV" to
mean "only SYN flag set" (due to "being initiated from ...") while "V4 SYN"
later means "SYN [and possibly ACK] flag set". The same applies to V6 of course.
Maybe reword? Maybe "being initiated from.." and this distinction is not
even necessary, because you don't have it on V4 FIN RCV side either? (Though
when creating sessions, the semantics differ slightly depending on the
initiator.)
V4 FIN RCV, V6 FIN RCV and V4 FIN + V6 FIN are listed in the state diagram
without "RCV" keyword, and this should be corrected.
I'm also a bit hesitant to include 4 min T.O., 2hrs etc. in the diagram as
these seem to be certain _minimum_ values and the implementation would be
free to use some other values as well. More general description would be
slightly better.
A cornercase from specification language point of view are those TCP flags
that could at least in theory be applicable alongside "state flags": URG and
PSH.
In S 3.5.2.2:
+ The STE transport IPv6 source address is left unspecified
and may be populated by other protocols out of the scope of
this specification.
... what does leaving source address unspecified mean in the context of TCP
session table searches, packets on the wire etc.?
The lifetime of the STE entry is set to TCP_INCOMING_SYN as per
[RFC5382] and the packet is stored. The result is that the
NAT64 will not drop the packet based on the filtering, nor
create a BIB entry. Instead, the NAT64 will only create the
session table entry and store the packet. The motivation for
this is to support simultaneous open of TCP connections.
... for how long is the packet supposed to be stored? Will it ever be sent
out on the wire? If yes, what will replace the "unspecified" IPv6 source
address then? If not, what's the point of storing a packet in the first
place (instead of just creating a state entry and dropping it)? An explicit
reference how the packet processing continues could be useful here (it seems
it does not continue). The same also applies in the case a TCP BIB entry
exist (similar description).
*** ESTABLISHED ***
If a V4 FIN packet is received, the packet is translated and
forwarded. The state is moved to V4 FIN RCV.
If a V6 FIN packet is received, the packet is translated and
forwarded. The state is moved to V6 FIN RCV.
.. I suppose you're referring here to _only_ FIN flag set. Does a V4 FIN
packet with FIN+ACK flag set more the state to V4 FIN RCV?
In S 3.5.3,
If the packet is discarded, then an ICMP error message
MAY be sent to the original sender of the packet, unless the
discarded packet is itself an ICMP message.
.. there are copy/paste/logical errors here, and this also seems to apply to
similar sections on UDP (at least). First of all, under UDP section, isn't
it already known which kind of packet is in question? Isn't the
"itself an ICMP message" condition wrong and should be "itself an ICMP error
message"? Is it intentional that the "ICMP packet" condition is different
for BIB entry search and address-dependent filtering search?
S 3.5.3 deals with ICMP Query sessions, so from that perspective, this
should always result in an ICMP error message generation?
In S 3.6.1:
When translating in the IPv4 --> IPv6 direction, let the incoming
source and destination transport addresses in the 5-tuple be (S,s)
and (D,d) respectively. The outgoing source transport address is
computed as follows:
The outgoing source transport address is generated from S using
the address transformation algorithm described in Section 3.5.4.
The BIB table is searched for an entry (X',x) <--> (D,d), and if
one is found, the outgoing destination transport address is set to
(X',x).
.. you don't mention what happens if an entry is not found in the BIB table.
(maybe the assumption is that you should never arrive at this step if the BIB
entry does not exist..) -- the same also applies in 3.6.2.
5.3. Attacks on NAT64
.. it might be worth also mentioning the "packet is stored" case already
mentioned above in the context of simultaneous opens.
editorial:
----------
In S 3.2 also later:
(X',Y',I1) <--> (T,Z,I2)
.. because ICMP identifier corresponds to a port number in some sense, and
port numbers are designated with lower-case letters, I wonder if in this
case as well it would be better to use 'i1' and 'i2'.
* The NAT64 MAY require that the UDP, TCP, or ICMP header be
completely contained within the fragment that contains OFFSET
equal to zero.
s/OFFSET/fragment offset/
o When the protocol following the IP header is ICMP (Sections 3.4
and 4.4) and it is an ICMP error message, the source and
destination transport addresses in the embedded packet are set to
the destination and source transport addresses from the outgoing
5-tuple (note the swap of source and destination).
.. you're referring to S 3.4 & S 4.4 of [I-D.ietf-behave-v6v4-xlate], not
this document, and this may be confusing. But reference to S 3.4 and 4.4
appears to be redundant and could maybe be removed here altogether.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
.. now published as an RFC.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf