I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-behave-v6v4-xlate-stateful-11
Reviewer: Pete McCann
Review Date: 2010-06-15
IETF LC End Date: 2010-06-15
IESG Telechat date: unknown
Summary: Some bugs need fixing before publication
Major issues: none
Minor issues:
Section 1.2.1:
The IPv4 address pool is a set of IPv4 addresses, normally a small
prefix assigned by the local administrator.
The pool is small but the prefix is long. Should say "long prefix
assigned"
here.
Section 3:
This section introduces the concept of separate BIB and Session Tables
for each of the three protocols. However, the definition of BIB in
Section 2 makes direct use of the term "session table". Does it need
to be re-worded, and a separate definition for "Session Table" added?
Section 3.5.1:
In the text describing handling an incoming IPv4 packet is the
following:
An IPv4 incoming packet, with an incoming tuple with source IPv4
transport address (Y,y) and destination IPv4 transport address (X,x)
is processed as follows:
The NAT64 searches for a UDP BIB entry that contains the BIB IPv4
transport address matching (Y,y), (i.e., the IPv4 destination
transport address in the incoming IPv4 packet).
You seem to have switched letters here. (Y,y) is the SOURCE, not
the destination, according to the first paragraph.
I suggest sticking with the earlier lettering and assume the packet
is sent to (T,t). The source of the packet could be (W,w) which
may or may not equal (Z,z) depending on whether Address-Dependent
filtering is in use.
Section 3.5.1:
* The STE destination IPv6 transport address is set to (Z'(Y),y),
y being the same port y than the destination IPv4 transport
address
SHOULD BE:
* The STE destination IPv6 transport address is set to (Z'(Y),y),
y being the same port y as the STE destination IPv4 transport
address and the same as the source port contained in the
received IPv4 packet
Or, if you follow my suggestion above:
* The STE destination IPv6 transport address is set to (Y'(W),w),
w being the same port w as the STE destination IPv4 transport
address and the same as the source port contained in the
received IPv4 packet
Section 3.5.2.2 (two places):
+ The STE destination IPv6 transport address contains the port
y (i.e. the same port than the destination IPv4 transport
address) and the IPv6 representation of Y (i.e. the IPv4
address of the destination IPv4 transport address),
generated using the algorithm described in Section 3.5.4.
SHOULD BE:
+ The STE destination IPv6 transport address contains the port
y (i.e. the same port as the STE destination IPv4 transport
address and the same as the source port contained in the V4
SYN)
and the IPv6 representation of Y (i.e. the IPv4
address of the destination IPv4 transport address),
generated using the algorithm described in Section 3.5.4.
In state V4 SYN RCV, when a V6 SYN arrives, should the stored V4 SYN be
translated and sent on to the IPv6 network? This would seem to match
the behavior in the V6 SYN RCV state.
Section 3.5.3:
discarded packet is itself an ICMP message.
SHOULD BE:
discarded packet is itself an ICMP error message.
Section 5.2:
offer "Endpoint-Independent Mapping". This means:
for any IPv6 packet with source (S'1,s1) and destination (Pref64::
D1,d1) that creates an external mapping to (S1,s1), (D1,d1),
for any subsequent external connection from S'1 to (D2,d2) within
a given binding timer window,
(S1,s1) = (S2,s2) for all values of D2,d2
SHOULD BE:
offer "Endpoint-Independent Mapping". This means:
for any IPv6 packet with source (S'1,s1) and destination (Pref64::
D1,d1) that creates an external mapping to (S1,s1v4), (D1,d1),
for any subsequent packet from (S'1,s1) to (Pref64::D2,d2)
that creates an external mapping to (S2,s2v4), (D2,d2), within
a given binding timer window,
(S1,s1v4) = (S2,s2v4) for all values of D2,d2
Rationale: the definition of Endpoint-Independent Mapping from
RFC 4787 does not require the equivalence when the first mapping
is from (S'1,s1) and the second mapping is from (S'1,s2)
where s1 != s2.
Nits/editorial comments:
Section 1.1:
node. this
SHOULD BE:
node. This
Section 1.2.1:
Pref64::/n, in the case
SHOULD BE:
Pref64::/n; in the case
Section 3.5.1:
NAT64 searches for the session table entry corresponding
containing the STE source
SHOULD BE:
NAT64 searches for the corresponding session table entry
containing the STE source
Section 3.5.2.2:
Section 3.5.2.3 The processing
SHOULD BE:
Section 3.5.2.3. The processing
following sections
SHOULD BE:
following sections.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
