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.