Subject: Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-behave-v6v4-xlate-stateful-11

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 09 Jul 2010 10:49:25 +0200

Hi Peter,

Thanks for the review.

all comments have been addressed, see log below.

El 16/06/10 0:09, McCann Peter-A001034 escribió:
> 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.
>    

right, but long prefix seems counterintuitive as well. I had simply 
removed the small from the previous sentence, since the next sentence in 
the paragraph states that normally the IPv4 pool is small.

The results is as follows:

        The IPv4 address pool is a set of IPv4 addresses,
        normally a prefix assigned by the local administrator. Since IPv4
        address space is a scarce resource, the IPv4 address pool is 
small and
        typically not sufficient to establish permanent one-to-one 
mappings with IPv6
        addresses.
> 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?
>    
right, the definition of BIB in section 2 should read BIB table rather 
than session table
i have changed that to

<t hangText="BIB:">Binding Information Base. A table of bindings kept
          by a NAT64.     Each NAT64 has a BIB for each translated 
protocol. An
             implementation compliant to this document would have a BIB
             for TCP, one for UDP and one for ICMP Queries. Additional BIBs
             would be added to support other protocols, such as SCTP.</t>

> 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.
>    

fixed and changed to the suggested notation
> 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
>    

done
> 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.
>    

changed
> 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.
>
>    
This was discussed in the WG and decided to discard the initial V4 SYN. 
This is so, because all this incoming v4 SYN processing is aimed to 
support only simultaneous opens, so, there is no need for the received 
to actually receive the v4 SYN and it would require state to store it.

> Section 3.5.3:
>     discarded packet is itself an ICMP message.
> SHOULD BE:
>     discarded packet is itself an ICMP error message.
>    

done
> 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.
>
>    

right, changed
> Nits/editorial comments:

fixed, thanks!
> 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.
>
>
>