Subject: Re: [BEHAVE] Review Part 2(final) of draft-ietf-behave-v6v4-xlate-stateful-03

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 12 Dec 2009 23:21:43 +0100

second part
see replies below...

George Tsirtsis escribió:
> Hi all,
>
> This continues and concludes my review of
> draft-ietf-behave-v6v4-xlate-stateful-03
>
> So on with the review from section 3.2.2 where I left it in Part 1..
>
> Regards
> George
> ...
>
> 3.2.2.  TCP Session Handling
>
>    The state information stored for a TCP session:
>
>       Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
>
>       Lifetime: is a timer that tracks the remaining lifetime of the UDP
>       session.  The NAT64 decrements this timer at regular intervals.
>       When the timer expires, the TCP session is deleted.  If all the
>       TCP sessions corresponding to a TCP BIB entry are deleted, then
>       the TCP BIB entry is also deleted (only applies to the case of
>       dynamically created entries).
>
>    TCP sessions are expensive, because their inactivity lifetime is set
>    to 2 hours and 4 min (as per [RFC5382]), so it is important that each
>
> GT> according to RFC5382:    // to 2 hours... / to at least 2 hours.../
>
>   
fixed

>    TCP session table entry corresponds to an existent TCP session.
>
>    In
>    order to do that, the NAT64 tracks the TCP connection procedure.  In
>    this section we describe how the NAT64 does that tracking by
>    describing the state machine.
>
> GT> Maybe rephrase: "In order to do that, for each TCP session
> established through it, it tracks the corresponding state machine as
> follows":
>
>   
done

>    The states are the following ones:
>
>       CLOSED
>       V4 SYN RCV
>       V6 SYN RCV
>       ESTABLISHED
>       V4 FIN RCV
>       V6 FIN RCV
>       V6 FIN + V4 FIN RCV
>       RST RCV
>
>    The state machine for the TCP session processing is depicted next.
>
>
> GT> What state machine is this exactly? It is clearly not the TCP
> state machine according to RFC793.
> - Is it a state machine you expect the NAT64 to implement?
>   
Yes, i will clarify this by rephrasing the previous sentence as:

            <t>The state machine used by the NAT64 for the TCP session 
processing is depicted next.</t>

> - on which interface? on the one where the TCP client is or the TCP
> server? or is this state machine driven by either side (seems this is
> the case)?
>   
the state machine is driven by either side:

I have added a clarification on this issue as:

    The described state machine handles all TCP segments received 
through the IPv6 and IPv4 interface.</t>

> - are all states valid for all TCP session? It seems not. A given flow
> will either be initiated from the IPv6 or from the IPv4 side and thus,
> only some of these states will be valid for a given session. i think
> it is not immediately obvious which ones these are which leads to some
> confusion when reading through this.
>
>   
each potential connection has an associated state machine.
as such, any connection can be initiated by any side. Of course, not all 
connections will go through all states, but this is the same for TCP, or 
any state machine.
So i am not sure how to clarify this further.

> Bagnulo, et al.           Expires May 25, 2010                 [Page 18]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>      +----------------------------+   +-----------------------------+
>      |                            |   |                             |
>      |                            V   V                             |
>      |                 V6       +------+      V4                    |
>      |            +----SYN------|CLOSED|-----SYN------+             |
>      |            |             +------+              |             |
>      |            |                ^                  |             |
>      |            |                |4min T.O.         |             |
>      |            V                |                  V             |
>      |        +-------+         +-------+          +-------+        |
>      |        |V6 SYN |         |RST RCV|          |V4 SYN |        |
>      |        |  RCV  |         +-------+          |  RCV  |        |
>      |        +-------+          |    ^            +-------+        |
>      |           |         data pkt   |               |             |
>      |           |               |  V4 or V6 RST      |             |
>      2Hrs     V4 SYN             V    |           V6 SYN            |
>      T.O.        |          +--------------+          |             |
>      |           +--------->| ESTABLISHED  |<---------+             |
>      +--------------------->|              |                        |
>                             +--------------+                        |
>                               |           |                         |
>                           V4 FIN       V6 FIN                       |
>                               |           |                         |
>                               V           V                         |
>                       +---------+       +----------+                |
>                       | V4 FIN  |       |  V6 FIN  |                |
>                       +---------+       +----------+                |
>                               |           |                         |
>                           V6 FIN       V4 FIN                     4 min
>                               |           |                        T.O.
>                               V           V                         |
>                          +-------------------+                      |
>                          | V4 FIN + V6 FIN   |----------------------+
>                          +-------------------+
>
>
>
>    After bootstrapping of the NAT64 device, all TCP session are in
>    CLOSED state.  We next describe the state information and the
>    transitions.
>
> GT> RFC793 (which BTW should be referenced) describes the CLOSED state
> as imaginary...since in practice it only exists on paper to describe
> the absence of any state. I would also suggest that a brief
> description of each of the states similar to the ones listed in
> RFC793, section 3.2 would be useful.
>   

i have included the following text:

                    <t>CLOSED: Analogous to <xref 
target="RFC793"></xref>, CLOSED is a fictional
                      because it represents the state when there is no 
state for this particular 5-tuple, and therefore,
                      no connection.</t>
                    <t>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 IPv4 
packet containing the TCP SYN in the opposite direction.</t>
                    <t>V6 SYN RCV: An IPv6 packet containing a TCP SYN 
was received by the NAT64, implying that a TCP connection is being 
initiated from the IPv6 side.
                        The NAT64 is now waiting for a matching IPv4 
packet containing the TCP SYN in the opposite direction.</t>
                    <t>ESTABLISHED: Represent an open connection, with 
data flowing in both directions.</t>
                    <t>V4 FIN RCV: An IPv4 packet containing a TCP FIN 
was received by the NAT64, data can still flow in the connection,
                        the NAT64 is waiting for a matching TCP FIN in 
the opposite direction.</t>
                    <t>V6 FIN RCV: An IPv6 packet containing a TCP FIN 
was received by the NAT64, data can still flow in the connection,
                            the NAT64 is waiting for a matching TCP FIN 
in the opposite direction.</t>
                    <t>V6 FIN + V4 FIN RCV: Both an IPv4 packet 
containing a TCP FIN and an IPv6 packet containing an TCP FIN for
                        this connection were received by the NAT64. The 
NAT64 keeps the connection state alive and forwards packet
                        in both directions for a short period of time to 
allow remaining packets (in particular the ACKs) to be delivered.</t>
                    <t>RST RCV: A packet containing a TCP RST was 
received by the NAT64 for this connection. The NAT64 will keep the state
                        for the connection for a short time and if no 
other data packets for that connection are received, the assumption is that
                        the node has accepted the RST packet and the 
state for this connection is then terminated.</t>

>    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.
>
>    *** CLOSED ***
>
>    If a V6 SYN is received, the processing is as follows:
>
> GT> It would be useful to note that this constitutes a TCP session
> initiation from the IPv6 side to the IPv4 side.

I have added that in the state description above
>  It should also be
> noted that IPv6 packets are only processed if the destination IPv6
> address is from Pref64::/n.
>   
I have already addressed this in the filtering section in common for TCP 
and UDP as a response to a previous comment from you

>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 19]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>       The state of the session is moved to V6 SYN RCV.
>
> GT> I think that it is more accurate to first successfully process the
> packet and then change the state, otherwise if something goes wrong
> you have to move the state back or move to a different state.
>   
right, done

>       The NAT64 searches for a TCP BIB entry that matches the IPv6
>       source transport address.
>
> GT> Use the (X',x) <--> (T,t) notation to describe what this search involves.
>
>
>   
I have updated the description to use the terminology

>          If such entry does not exists, a new entry is created.
>
> GT> What should the NAT64 do if an entry already exists? is this an
> error or could it be a retransmission? In general I think you should
> check all the "if" statements to make sure that the "if not" case is
> also covered.
>
>   

Done, rephrased the text as follows

                                <t>If such entry does not exists, a new 
BIB entry is created.
                                The BIB IPv6 transport address is set to 
(X',x) (i.e. the source IPv6 transport address of the packet)
                                The BIB IPv4 transport address is the to 
an IPv4 transport address allocated using the rules defined
                                in <xref target="transport address 
alloc"></xref>
                                The processing  of the packet continues 
as described in the next paragraph.</t>
                                <t>If the entry already exists, then the 
processing continues as described in the next paragraph.</t>

>          As IPv6
>          address, the source IPv6 transport address of the packet is
>          included and an IPv4 transport address allocated using the
>          rules defined in Section 3.2.3 is included as the IPv4
>          transport address.
>
> GT> Use the (X',x) <--> (T,t) notation to describe how the new entry is created.
>
>   
done

>       Then a new TCP session entry is created in the TCP session table.
>       The information included in the session table is as follows:
>
> GT> Again use the (X',x),(Y',y) <--> (T,t),(Z,z) notation. I know this
> sounds painful but it will make things much clearer.
>
>   
done

>          The IPv6 transport source and destination addresses contained
>          in the received V6 SYN packet,
>
>          The IPv4 transport source address is extracted from the
>          corresponding TCP BIB entry and,
>
>          the IPv4 transport destination address contains the same port
>          as the IPv6 destination transport address and the IPv4 address
>          that is algorithmically generated from the IPv6 destination
>          address using the reverse algorithm as specified in
>          Section 3.2.5.
>
>          The lifetime of the TCP session table entry is set to 4 min
>          (the transitory connection idle timeout as defined in
>          [RFC5382]).
>
> GT>according to the RFC:  //is set to 4 min/is set to at least 4 min/
>
>   
done

>       The packet is translated and forwarded.
>
> GT> point to translator draft
>
>   
well, this is described int he next sections actually, so i have 
rephrased as:

                        <t>The NAT64 translates and forwards the packet 
as described
                            in the following sections</t>

>    If a V4 SYN packet is received, the processing is as follows:
>
> GT> It would be useful to note that this constitutes a TCP session
> initiation from the IPv4 side to the IPv6 side. 
done

> It should also be
> noted that IPv4 packets are only processed if the destination IPv4
> address is from the pool of IPv4 addresses explicitly used by NAT64
> for translation. This again ensures that NAT64 does not interfere with
> packets that do not need translation.
>
>   
I have added the following text int he filtering section

            Likewise, the NAT64 function will only process incoming
            IPv4 packets that contain a destination address that belong 
to the IPv4 pool assigned to the NAT64.</t>

>       If the security policy requires silently dropping externally
>       initiated TCP connections, then the packet is silently discarded,
>       else,
>
> GT> What is this "security policy"? this is the first time it is
> mentioned in the draft. I thought all filtering is either done by BIB
> or by session entries.
>
>   
but it is possible that irrespectively what is in the BIB or session 
tables, the NAT64 is configured to not accept new connections initiated 
from the IPv4 side.
that is what this sentence is trying to capture... not sure if can be 
phrased better...

>       If the destination transport address contained in the incoming V4
>       SYN is not in use in the TCP BIB, then the packet is discarded and
>       an ICMP Port Unreachable error (Type 3, Code 3) is sent back to
>       the source of the v4 SYN.  The state remains unchanged in CLOSED
>       If the destination transport address contained in the incoming V4
>       SYN is in use in the TCP BIB, then
>
> GT> Use the (X',x) <--> (T,t) notation to describe what these
> unsuccessful and then successful searches involve.
>
>   
done

>          The state is moved to V4 SYN RCV.
>
> GT> Again, I think it might be better if the state is changed after
> the following processing completes successfully.
>
>   

done
> Bagnulo, et al.           Expires May 25, 2010                 [Page 20]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>          A new session table entry is created in the TCP session table,
>          containing the following information:
>
> GT> Use the (X',x) <--> (T,t) notation
>
>   
done

>             The transport source and destination address contained in
>             the V4 SYN and,
>
>             The source IPv6 transport address (in the IPv6 --> IPv4
>             direction) contained in the existing TCP BIB entry.
>
>             The destination IPv6 transport address contains the same
>             port than the destination IPv4 transport address and the
>             IPv6 representation of the IPv4 address of the destination
>             IPv4 transport address, generated using the algorithm
>             described in Section 3.2.5.
>
>             The lifetime of the entry is set to 6 seconds as per
>             [RFC5382].
>
>          The packet is discarded.
>
> GT> Without reading RFC5382, which describes how this helps
> simultaneous-open, this sounds very weired and completly unorthodox.
> Initialy I thought the statement "The packet is discarded" was simple
> an error and only understood what was going on after talking to
> Marcelo. It would be beneficial to briefly outline why this is done to
> provide context to the reader and then encourage them to read RFC5382
> for the details.
>
>   
mmm, after our exchange, i realized that i needed to keep the packet in 
order to send a proper ICMP error back.

So i ahve rephrased the thing as:

                            <t>If the NAT64 is performing 
Address-Dependent filtering, the packet is stored (The motivation for
                                creating the session table entry and 
storing the packet (instead of simply dropping the packet based on the 
filtering) is
                                to support simultaneous open of TCP 
connections)
                            <t>If the NAT64 is not performing 
Address-Dependent filtering, it translates and forwards the packet as 
described
                                in the following sections. </t>

>    For any other IPv6 packet, depending on the security policy other
>    packets MAY be forwarded or MAY be silently discarded.  In any case,
>    the state remains unchanged.
>
> GT> this statement sounds hand-waving and wrong. What "other IPv6
> packets" it refers to? and "MAY be forwarded or MAY silently
> discarded" based on what? for example other IPv6 SYN  packets to
> different source/dest? other IPv6 UDP packets? ICMPv6?
>
>   

mmm, since we are in the state machine and the state machine is per 
connection, then this only refers to IPv6 packets of that particular TCP 
connection.
The situation that is considered here is what do we do with other 
packets from that connection that show up while we are in this 
particular state i.e. in CLOSED state.
I mean suppose that we receive a TCP data packet for a connection that 
is closed. Suppose that we do have the information to process it (i.e. a 
corresponding BIB entry) So what do we do? do we drop the packet or do 
we froward the packet. The only thing i am convinced is that we 
shouldn't create a session entry for that packet, since it is too 
expensive (we only do that if we had the full 3 way handshake), but do 
we need to drop the packet? I am not sure. I think this is a policy 
decision and that i why i left it open. But we can discuss it. This 
applies to all non expected packets in all the rest of the states. So 
the same discussion applies.

In any case, i have clarified that this only refers to packets from this 
connection. and i have made a common text both for v4 and v6 as follows:

                <t>For any other packet belonging to this connection,
                    <list>
                    <t>If there is a corresponding entry in the TCP BIB
                    depending on the security policy other packets MAY 
be forwarded or MAY be silently discarded.
                    In any case, the state remains unchanged.</t>
                    <t>If there is no corresponding entry in the TCP BIB
                    the packet is silently discarded.</t>
                    </list>
                </t>   

>    For any other IPv4 packet,
>
> GT> Again what other IPv4 packets? same questions as for IPv6 above.
>
>   
see previous comments

> GT> Use the proper notation for the searches
>
>   
done

>       If the destination transport address contained in the incoming
>       IPv4 packet is in use in the TCP BIB depending on the security
>       policy other packets MAY be forwarded or MAY be silently
>       discarded.  In any case, the state remains unchanged.
>
>       If the destination transport address contained in the incoming
>       IPv4 packet is not in use in the TCP BIB the packet is silently
>       discarded.
>
>    *** V4 SYN RCV ***
>
> GT> Unlike the CLOSED state where any TCP SYN packets would be
> processed as defined since these are the only packets that
> instantiate the state machine, from here one a packet will only affect
> an instance of the state machine if it matches the BIB and session
> entries.
but that is true also for the closed state.

I mean, we do have a instance of the state machine per connection.
So, when a packet arrives, it is associated to a single state machine. 
The only difference between the closed state and the others is that in 
closed state there is actual state being stored in the nat64, while in 
the other it is. But the abstract binding to the state machine is the 
same for all of them

>  so this should be examined first again using our favorite
> notation.
>
>    If a V6 SYN is received, then the state is moved to ESTABLISHED.
>
> G> change state after processing
>   

done
>     The
>    lifetime of the corresponding TCP session table entry is updated to 2
>    hours 4 min (the established connection idle timeout as defined in
>
> GT> to at least 2 hours and 4 min
>
>   
done

> [RFC5382]).  The packet is translated and forwarded.
>
>    If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code
>
> GT> //if the lifetime expires/If no relevant V6 SYN is received and
> the lifetime of the session entry expires/
>
>   

mm, if the relevant IPv6 SYN was received before, the state is no longer 
V4 SYN RCV, buty moved to ESTABLISHED

>    3) is sent back to the source of the v4 SYN, the session table entry
>    is deleted and, the state is moved to CLOSED.
>
>
>
>    For any other packet, depending on the security policy other packets
>    MAY be forwarded or MAY be silently discarded.  In any case, the
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 21]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    state remains unchanged.
>
> GT> again hand waving regarding "other" packets. we should state what
> happens to other packets that match the same BIB/session entries and
> specifically what happens to other V4SYN packets (e.g. retransmitted)
>
>   

but packets that are processed by this particular state machine belong 
only to this connection in particular.
I have added the following text to clarify this.

                There is one state machine per TCP connection that is 
potentially established through the NAT64.
                After bootstrapping of the NAT64 device, all TCP session 
are in CLOSED state. As we mention above,
                the CLOSED state is a fictional state that there is not 
state for that
                particular connection in the NAT64.</t>

About other V4 SYN packets for the same connection, from the NAT64 
persepctive, i don't think they change much (potentially they could set 
the timer again to its initial value). whether forwarding them or not, i 
am uncertain.
>    *** V6 SYN RCV ***
>
>    If a V4 SYN is received (with or without the ACK flag set), then the
>    state is moved to ESTABLISHED.  The timer is updated to 2 hours 4 min
>
> GT> to at least 2 hours...
>
>   
done

>    (the established connection idle timeout as defined in [RFC5382]).
>    The packet is translated and forwarded.
>
>    If the lifetime expires, the session table entry is deleted and the
>    state is moved to CLOSED.
>
> GT> //if the lifetime expires/If no relevant V4 SYN is received and
> the lifetime of the session entry expires/
>
>   
same than above

>    For any other packet, depending on the security policy other packets
>    MAY be forwarded or MAY be silently discarded.  In any case, the
>    state remains unchanged.
>
> GT> same hand waving as earlier
>
>   
same than above

>    *** ESTABLISHED ***
>
>    If the lifetime expires, the session table entry is deleted and the
>    state is moved to CLOSED.
>
> GT> This could be deleted since it is repeated below.
>
>   
done

>    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.
>
> GT> Be specific about FIN packet matching BIB/session entries.
all packets processed in the state machine belong to this particular 
connection.
I have added text in the begining describing the state machine that 
makes that clearer (i hope)

>  Also
> what happens to lifetime when you move to FIN RCV?
>
>   
no change in the timer, since it may be a half closed connection

>    If a packet is received, the packet is translated and forwarded.  The
>    lifetime is set to 2 hours and 4 min.  The state remains unchanged as
>    ESTABLISHED.
>
>
> GT> Again be more specific i.e., any TCP packet that matches the
> BIB/Session entries
not the bib entry, but the session table entry i.e. a packet for this 
connection. I hope this is clearer with the new text

>  for this TCP state machine resets the timer to at
> least 2 hours and 4min i.e., the lifetime at the  ESTABLISH state is
> an "idle-timeout" affected by any packet on this session, including
> regular data TCP packets and TCP keep-alives.
right, i have moved this to the end of the processing and stated that if 
any other packet is received, then...

>  This is not the case in
> some of the other states where only specific control packets affect
> them. Make similar clarifications for V6/V4 FIN packets
>
>    If the lifetime expires, the session table entry is deleted and the
>    state is moved to CLOSED.
>
>    If a V4 RST or a V6 RST packet is received, the packet is translated
>    and forwarded.  The lifetime is set to 4 min and state is moved to
>    RST RCV.
>
> GT> Some justification for this would be useful.
>   

I have added:

(Since the NAT64 is uncertain whether the peer will accept the RST 
packet, instead of moving the state to
                    CLOSED, it moves to the RST RCV, which has a shorter 
lifetime. If no other packets are received for this connection during the
                    short timer, the NAT64 assumes that the peer has 
accepted the RST packet and moves to CLOSED. If packet keep flowing,
                    the NAT64 assumes that the peer has not accepted the 
RST packet and moves back to ESTABLISHED state.)
>    *** V4 FIN RCV ***
>
>    If a packet is received, the packet is translated and forwarded.  The
>
> GT> be specific on what packet
>
>   
right, i have changed the order, put this bullet last and stated any 
other packet

>    lifetime is set to 2 hours and 4 min.  The state remains unchanged as
>    V4 FIN RCV.
>
> GT> to at least 2 hours...
>
>   
done

>    If a V6 FIN packet is received, the packet is translated and
>
> GT> one that matches BIB/session
>
>   
This is hopefully clarified by the text above
>    forwarded.  The lifetime is set to 4 min.  The state is moved to V6
>    FIN + V4 FIN RCV.
>
> GT> to at least 4 min...
>
>   
done

> Bagnulo, et al.           Expires May 25, 2010                 [Page 22]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    If the lifetime expires, the session table entry is deleted and the
>    state is moved to CLOSED.
>
>    *** V6 FIN RCV ***
>
>    If a packet is received, the packet is translated and forwarded.  The
>
> GT> be specific on the  packet.
>
>   
hopefully this is clear now

>    lifetime is set to 2 hours and 4 min.  The state remains unchanged as
>    V6 FIN RCV.
>
> GT> to at least 2 hours...
>
>   
done

>    If a V4 FIN packet is received, the packet is translated and
>    forwarded.  The lifetime is set to 4 min.  The state is moved to V6
>    FIN + V4 FIN RCV.
>
> GT> to at least 4 min...
>
>   
done

>    If the lifetime expires, the session table entry is deleted and the
>    state is moved to CLOSED.
>
>    *** V6 FIN + V4 FIN RCV ***
>
>    All packets are translated and forwarded.
>
> GT> be specific on which packets?
>
>   
hopefully this is clear

>    If the lifetime expires, the session table entry is deleted and the
>    state is moved to CLOSED.
>
>    *** RST RCV ***
>
>    If a packet is received, the lifetime is set to 2 hours and 4 min and
>    the state is moved to ESTABLISHED.
>
> GT> be specific on which packet.
>
>   
hopefully this is clear.

>    If the lifetime expires, the session table entry is deleted and the
>    state is moved to CLOSED.
>
> 3.2.3.  Rules for allocation of IPv4 transport addresses
>
> GT> Shouldn't this section be after section 3.2.4 on ICMP?
>   
done
>    If the rules specify that a new BIB entry is created for a source
>    transport address of (S',s), then the NAT64 allocates an IPv4
>    transport address for this BIB entry as follows:
>
>       If there exists some other BIB entry containing S' as the IPv6
>       address and mapping it to some IPv4 address T, then use T as the
>       IPv4 address.  Otherwise, use any IPv4 address assigned to the
>       IPv4 interface.
>
> GT> from the pool specifically used for translation
>
>   
done

>       If the port s is in the Well-Known port range 0..1023, then
>       allocate a port t from this same range.  Otherwise, if the port s
>       is in the range 1024..65535, then allocate a port t from this
>       range.  Furthermore, if port s is even, then t must be even, and
>       if port s is odd, then t must be odd.
>
> GT> It is not immediately obvious why the above is so...some
> justification would be useful. Section 7.1 of RFC5382 provides some
> justification
>
>   
added a reference

> Bagnulo, et al.           Expires May 25, 2010                 [Page 23]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>       In all cases, the allocated IPv4 transport address (T,t) MUST NOT
>       be in use in another entry in the same BIB, but MAY be in use in
>       the other BIB.
>
> GT> I have no clue what this means.
>
>   
it refers to the TCP vs UDP bib

added a clarification

>    If it is not possible to allocate an appropriate IPv4 transport
>    address or create a BIB entry for some reason, then the packet is
>    discarded.
>
> GT> are we sure this is appropriate in all cases? should appropriate
> ICMP error be sent?
>
>   
added the possibility of sending an ICMP packet back
I have added:

The NAT64 MAY send an ICMPv6 Destination Unreachable/Address unreachable 
(Code 3) message.

> 3.2.4.  ICMP Query Session Handling
>
>    The state information stored for an ICMP Query session in the ICMP
>    Query session table includes a timer that tracks the remaining
>    lifetime of the session.
>
> GT> As with TCP and UDP we should repeat the notation here for the
> sessions and use it throughout the section
>
>  The NAT64 decrements this timer at regular
>    intervals.
>
> GT> I do not understand what this means.a timer is a timer and it is
> decremented as time passes. What is missing though it some indication
> on when the timer is reset to its initial value.
>   

deleted the sentence
>   When the timer expires, the session is deleted.  If all
>    the sessions corresponding to a ICMP Query BIB entry are deleted,
>    then the ICMP Query BIB entry is also deleted in the case of
>    dynamically created entries.
>
>
> GT> for the rest of this sub-section the usual comment sapply i.e., be
> specific on what packet it is being processed and use our favorit
> notation to explain how entries are searched or created.
>   
right, tried to do that

>    An incoming ICMPv6 Informational packet is processed as follows:
>
>       If the local security policy determines that ICMPv6 Informative
>       packets are to be filtered, the packet is silently discarded.
>       Else, the NAT64 searches for a ICMP Query BIB entry that matches
>       the (IPv6 source address, ICMPv6 Query Id) pair.  If such entry
>       does not exist, a new entry is created.  As (IPv6 address, ICMPv6
>       Query Id) pair, the source IPv6 address of the packet and the
>       ICMPv6 Query Identifier are included.  The IPv4 address and ICMPv4
>       Query Identifier values are allocated as follows:
>
>          If there exists some other BIB entry containing the same IPv6
>          address and mapping it to some IPv4 address T, then use T as
>          the IPv4 address.  Otherwise, use any IPv4 address assigned to
>          the IPv4 interface.
>
>          As ICMPv4 Identifier use any available value i.e. any
>          identifier value for which no other entry exists with the same
>          (IPv4 address, ICMPv4 Query Id) pair.
>
>       The NAT64 searches for the session table entry corresponding to
>       the incoming 3-tuple.  If no such entry is found, a new entry is
>       created.  The information included in the session table is as
>       follows: the IPv6 source and destination addresses contained in
>       the received IPv6 packet, the IPv4 source address, the ICMPv4
>       Query Id and the ICMPv6 Query Id are extracted from the
>       corresponding ICMP Query BIB entry and the IPv4 destination
>       address is algorithmically generated from the IPv6 destination
>       address using the reverse algorithm as specified in Section 3.2.5.
>
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 24]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>       The NAT64 sets or resets the timer in the session table entry to
>       maximum session lifetime.  By default, the maximum session
>       lifetime is 60 seconds.  The maximum lifetime value SHOULD be
>       configurable.  The packet is translated and forwarded as described
>       in the following sections.
>
>    An incoming ICMPv4 Query packet is processed as follows:
>
>       The NAT64 searches for a ICMP Query BIB entry that matches the
>       IPv4 destination address and ICMPv4 query Id pair.  If such entry
>       does not exists, the packet is dropped.  An ICMP message MAY be
>       sent to the original sender of the packet, unless the discarded
>       packet is itself an ICMP message.  The ICMP message, if sent, has
>       a type of 3 (Destination Unreachable).
>
>       If the NAT64 filters on its IPv4 interface, then the NAT64 checks
>       to see if the incoming packet is allowed according to the address-
>       dependent filtering rule.  To do this, it searches for a session
>       table entry with a source IPv4 address and ICMP Query Id pair
>       equal to the destination IPv4 address and ICMP Query Id in the
>       incoming 3-tuple and destination IPv4 address (in the session
>       table entry) equal to the source IPv4 address in the incoming
>       3-tuple.  If such an entry is found (there may be more than one),
>       packet processing continues.  Otherwise, the packet is discarded.
>       If the packet is discarded, then an ICMP message MAY be sent to
>       the original sender of the packet, unless the discarded packet is
>       itself an ICMP message.  The ICMP message, if sent, has a type of
>       3 (Destination Unreachable) and a code of 13 (Communication
>       Administratively Prohibited).
>
>       The NAT64 searches for the session table entry corresponding to
>       the incoming 3-tuple.  If no such entry is found, a new entry is
>       created.  The ICMP Query session table entry contains the ICMPv4
>       Query Identifier, source and destination address contained in the
>       IPv4 packet and the source IPv6 address and the ICMPv6 Query Id
>       (in the IPv6 --> IPv4 direction) contained in the existing ICMP
>       Query BIB entry.  The destination IPv6 address contains is the
>       IPv6 representation of the IPv4 address of the destination IPv4
>       address, generated using the algorithm described in Section 3.2.5.
>
>       The NAT64 sets or resets the timer in the session table entry to
>       maximum session lifetime.  By default, the maximum session
>       lifetime is 60 seconds.  The maximum lifetime value SHOULD be
>       configurable.  The packet is translated and forwarded as described
>       in the following sections.
>
>
>
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 25]
>
> Internet-Draft                    NAT64                    November 2009
>
>
> 3.2.5.  Generation of the IPv6 representations of IPv4 addresses
>
>    NAT64 support multiple algorithms for the generation of the IPv6
>    representation of an IPv4 address.  The constraints imposed to the
>    generation algorithms are the following:
>
>       The same algorithm to create an IPv6 address from an IPv4 address
>       MUST be used by:
>
>          The DNS64 to create the IPv6 address to be returned in the
>          synthetic AAAA RR from the IPv4 address contained in original A
>          RR, and,
>
>          The NAT64 to create the IPv6 address to be included in the
>          destination address field of the outgoing IPv6 packets from the
>          IPv4 address included in the destination address field of the
>          incoming IPv4 packet.
>
>       The algorithm MUST be reversible, i.e. it MUST be possible to
>       extract the original IPv4 address from the IPv6 representation.
>
>       The input for the algorithm MUST be limited to the IPv4 address,
>       the IPv6 prefix (denoted Pref64::/n) used in the IPv6
>       representations and optionally a set of stable parameters that are
>       configured in the NAT64 (such as fixed string to be used as a
>       suffix).
>
> GT> In this case the same "set of stable parameters" has to also be
> configured in DNS64?
>
>   
yes, not sure if i should mention that here though

>          If we note n the length of the prefix Pref64::/n, then n MUST
>          the less or equal than 96.  If a Pref64::/n is configured
>          through any means in the DNS64 (such as manually configured, or
>          other automatic mean not specified in this document), the
>          default algorithm MUST use this prefix.  If no prefix is
>          available, the algorithm MUST use the Well-Known prefix
>          (include here the prefix to be assigned by IANA) defined in
>          [I-D.ietf-behave-address-format]
>
> GT> In either case, for a site using a given NAT64, the Prefix64::/
> MUST be uniquely routable to the NAT64 function defined here, correct?
> This prefix I assume should be globally routable? this seems necessary
> if the IPv6 side is the whole IPv6 Internet....but is this required
> even in if the IPv6 site is a stab connected to the IPv4 Internet? Or
> maybe all this is defined in draft-ietf-behave-address-format; if that
> is the case then point to it not just for the format but for other
> requirements on the Prefix64.
>   
I am not sure i understand this comment, so i don't know what change to 
make here.

>    NAT64 MUST support the following algorithms for generating IPv6
>    representations of IPv4 addresses defined in
>    [I-D.ietf-behave-address-format]:
>
>       Zero-Pad And Embed, defined in section 3.2.3 of
>       [I-D.ietf-behave-address-format]
>
>       Compensation-Pad And Embed, defined in section of 3.2.4 of
>       [I-D.ietf-behave-address-format]
>
>       Embed And Zero-Pad, defined in section of 3.2.5 of
>       [I-D.ietf-behave-address-format]
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 26]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>       Preconfigured Mapping Table, defined in section of 3.2.6 of
>       [I-D.ietf-behave-address-format]
>
> GT> The pointers need updating
>
>    The default algorithm used by NAT64 must be Embed and Zero-Pad.
>    While the normative description of the algorithms is provided in
>    [I-D.ietf-behave-address-format].
>
> GT> is the "must" above normative? should it be "MUST"?
>
>   
i have updated the pointer and now there is only one algorithm, so no 
longer needed.

> 3.3.  Computing the Outgoing Tuple
>
>    This step computes the outgoing tuple by translating the addresses
>    and ports or ICMP Query Id in the incoming tuple.
>
>    In the text below, a reference to the the "BIB" means either the TCP
>    BIB the UDP BIB or the ICMP Query BIB as appropriate.
>
>       NOTE: Not all addresses are translated using the BIB.  BIB entries
>       are used to translate IPv6 source transport addresses to IPv4
>       source transport addresses, and IPv4 destination transport
>       addresses to IPv6 destination transport addresses.  They are NOT
>       used to translate IPv6 destination transport addresses to IPv4
>       destination transport addresses, nor to translate IPv4 source
>       transport addresses to IPv6 source transport addresses.  The
>       latter cases are handled applying the algorithmic transformation
>       described in Section 3.2.5.  This distinction is important;
>       without it, hairpinning doesn't work correctly.
>
> 3.3.1.  Computing the outgoing 5-tuple for TCP, UDP and ICMP error
>         messages
>
>    The transport protocol in the outgoing 5-tuple is always the same as
>    that in the incoming 5-tuple.
>
>    When translating in the IPv6 --> IPv4 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 BIB contains a entry (S',s) <--> (T,t), then
>    the outgoing source transport address is (T,t).
>
>    The outgoing destination address is computed algorithmically from D'
>    using the address transformation described in Section 3.2.5.
>
>    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.2.5.
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 27]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    The outgoing destination transport address is computed as follows:
>
>       If the BIB contains an entry (X',x) <--> (D,d), then the outgoing
>       destination transport address is (X',x).
>
>       Otherwise, discard the packet.
>
> GT> This section is about calculating a tuple. the decision to discard
> a packet seems completly out of place.
>
>   
right, removed

>    If the rules specify that the packet is discarded, then the NAT64 MAY
>    send an ICMP reply to the original sender, unless the packet being
>    translated contains an ICMP message.  The type should be 3
>    (Destination Unreachable) and the code should be 0 (Network
>    Unreachable in IPv4, and No Route to Destination in IPv6).
>
> GT> same here, looks out of place.
>
>   
removed

> 3.3.2.  Computing the outgoing 3-tuple for ICMP Query messages
>
>    When translating in the IPv6 --> IPv4 direction, let the incoming
>    source and destination addresses in the 3-tuple be S' and D'
>    respectively and the ICMPv6 Query Identifier be I1.  The outgoing
>    source address is computed as follows: the BIB contains a entry
>    (S',I1) <--> (T,I2), then the outgoing source address is T and the
>    ICMPv4 Query Id is I2.
>
>    The outgoing IPv4 destination address is computed algorithmically
>    from D' using the address transformation described in Section 3.2.5.
>
>    When translating in the IPv4 --> IPv6 direction, let the incoming
>    source and destination addresses in the 3-tuple be S and D
>    respectively and the ICMPv4 query Id is I2.  The outgoing source
>    address is generated from S using the address transformation
>    algorithm described in Section 3.2.5.  The outgoing destination
>    address and ICMPv6 Query Id are computed as follows:
>
>       If the BIB contains an entry (X',I1) <--> (D,I2), then the
>       outgoing destination address is X' and the outgoing ICMPv6 Query
>       Id is I1.
>
>       Otherwise, discard the packet.
>
> GT> same here
>
>   
removed

>    NOTE: Not sure if this applies to ICMP query messages....If the rules
>    specify that the packet is discarded, then the NAT64 MAY send an ICMP
>    reply to the original sender, unless the packet being translated
>    contains an ICMP message.  The type should be 3 (Destination
>    Unreachable) and the code should be 0 (Network Unreachable in IPv4,
>    and No Route to Destination in IPv6).
>
> GT> same here
>
>
>
>   

removed
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 28]
>
> Internet-Draft                    NAT64                    November 2009
>
>
> 3.4.  Translating the Packet
>
>    This step translates the packet from IPv6 to IPv4 or vice-versa.
>
>    The translation of the packet is as specified in section 3 and
>    section 4 of IP/ICMP Translation Algorithm
>    [I-D.ietf-behave-v6v4-xlate], with the following modifications:
>
>    o  When translating an IP header (sections 3.1 and 4.1), the source
>       and destination IP address fields are set to the source and
>       destination IP addresses from the outgoing 5-tuple.
>
>
> GT> clarify that the outgoing 5-tuple  is defined in an earlier
> section of this document.
>   

done
>    o  When the protocol following the IP header is TCP or UDP, then the
>       source and destination ports are modified to the source and
>       destination ports from the outgoing 5-tuple.  In addition, the TCP
>       or UDP checksum must also be updated to reflect the translated
>       addresses and ports; note that the TCP and UDP checksum covers the
>       pseudo-header which contains the source and destination IP
>       addresses.  An algorithm for efficiently updating these checksums
>       is described in [RFC3022].
>
>    o  When the protocol following the IP header is ICMP and it is an
>       ICMP Query message, the ICMP query Identifier is set to the one of
>       the outgoing 3-tuple.
>
> GT> clarify that the outgoing 3-tuple  is defined in an earlier
> section of this document.
>   

done
>    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).
>
>    The size of outgoing packets as well and the potential need for
>    fragmentation is done according to the behavior defined in IP/ICMP
>    Translation Algorithm [I-D.ietf-behave-v6v4-xlate]
>
> 3.5.  Handling Hairpinning
>
>    This step handles hairpinning if necessary.
>
>    If the destination IP address is an address assigned to the NAT64
>    itself (i.e., is one of the IPv4 addresses assigned to the IPv4
>    interface, or is covered by the Pref64::/n prefix assigned to the
>    IPv6 interface), then the packet is a hairpin packet.
>
> GT> This is not a sufficient definition of "hairpinning"....since it
> describes ALL packets that go through the NAT64.  Hairpinning is
> defined in detail in Section 6 of RFC4787, and more compactly Section
> 7.2 of RFC5382. to paraphrase the latter:
> "   A NAT64 that forwards packets originating from an IPv6 address,
>    destined for an IPv4 address that matches the active mapping for
>    another IPv6 address, back to that IPv6 address are defined as as
> supporting "hairpinning". "
>
>   
I have added this text to the document

>  The outgoing
>    5-tuple becomes the incoming 5-tuple, and the packet is treated as if
>    it was received on the outgoing interface.  Processing of the packet
>    continues at step 2 Section 3.2
>
>
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 29]
>
> Internet-Draft                    NAT64                    November 2009
>
>
> 4.  Application scenarios
>
> GT> this is clearly no longer normative. I wonder if it should be
> either moved to the front or placed in an appendix.
>   
mmm, i will move it to an appendix

>    In this section, we describe how to apply NAT64/DNS64 to the suitable
>    scenarios described in [I-D.ietf-behave-v6v4-framework] .
>
> GT> That's it....the security section looks ok so far, but I will try
> to check it again in more detail during WGLC or closer to it.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>