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

[George Tsirtsis <[e-mail]>]

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

   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":

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



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.

   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. It should also be
noted that IPv6 packets are only processed if the destination IPv6
address is from Pref64::/n.


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.

      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.


         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.

         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.

      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.

         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/

      The packet is translated and forwarded.

GT> point to translator draft

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

      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.

      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.

         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.


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

            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.

   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?

   For any other IPv4 packet,

GT> Again what other IPv4 packets? same questions as for IPv6 above.

GT> Use the proper notation for the searches

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

    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

[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/

   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)

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

   (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/

   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

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

   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. Also
what happens to lifetime when you move to FIN RCV?

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

   *** V4 FIN RCV ***

   If a packet is received, the packet is translated and forwarded.  The

GT> be specific on what packet

   lifetime is set to 2 hours and 4 min.  The state remains unchanged as
   V4 FIN RCV.

GT> to at least 2 hours...

   If a V6 FIN packet is received, the packet is translated and

GT> one that matches BIB/session

   forwarded.  The lifetime is set to 4 min.  The state is moved to V6
   FIN + V4 FIN RCV.

GT> to at least 4 min...


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.

   lifetime is set to 2 hours and 4 min.  The state remains unchanged as
   V6 FIN RCV.

GT> to at least 2 hours...

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

   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?

   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.

   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?

   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

      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


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.

   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?

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.

  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.

   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?

         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.

   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"?


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.

   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.

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

   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







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.

   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.

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

 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.

   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.