Subject: Re: [BEHAVE] Review Part 1 of draft-ietf-behave-v6v4-xlate-stateful-03

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 03 Dec 2009 19:30:45 +0100

Hi George,

thanks for the thorough review.

find my replies below.

George Tsirtsis escribió:
> Hi all,
>
> I have been reviewing this draft in considerable detail. I think the
> document is on the right track but I also I think it needs a fair
> amount of work to make it comprehensible and clear enough to be
> implementable.
>
> Specifically I propose:
> -  to more clearly identify the type of mapping and filtering
> (Endpoint-Independent., Address-Dependent, Address and Port-Dependent)
> supported in general and/or described in particular in certain parts
> of the document. This will help put context and reason in some of the
> processing described.
>   
right, will try to do that

> - to utilise the notation (X',x) <--> (T,t) and  (X',x),(Y',y) <-->
> (T,t),(Z,z) when describing the searching or setting of the BIB and
> session table entries. This will help make descriptions much easier to
> understand, because some of them at the moment are little
> mind-twisters.
>
>   
ok

> I also provide a number of other comments/clarifications/corrections.
>
> Due to the extend of the comments and description style changes I
> propose for Section 3 and below, I stopped the review at section
> 3.2.2. for now, to get some feedback from the WG and the authors. If
> the authors and WG think the comments are reasonable and useful, I
> will continue the review to the rest of the document, and will work
> with the authors as needed.
>
> Regards
> George
> -----------
>
>
>                 draft-ietf-behave-v6v4-xlate-stateful-03
>
> 1.  Introduction
>
> ...
>
> 1.1.  Features of NAT64
>
> GT> I think it would be beneficial to state clearly the type of NAT
> mapping and filtering that is supported in this document. The document
> seems to specifically support ONLY Endpoint-Independent Mappings,
> while WRT to filtering types it says it adheres to RFC4787 and
> RFC5382.
right, it supports both endpoint independent filtering and address 
dependent filtering for both TCP and UDP. I will state that up front in 
the feature description

>  In practice, however, it is not clear to what extend it does
> that. see below.
>
>   

I am not sure what do you meanby this maybe will become clearer when i 
continue reading...

>    The features of NAT64 and DNS64 are:
>
>    o  It enables IPv6-only nodes to initiate a client-server connection
>       with an IPv4-only server, without needing any changes on either
>       IPv4 or IPv6 nodes.  This works for roughly the same class of
>       applications that work through IPv4-to-IPv4 NATs.
>
>    o  It supports peer-to-peer communication between IPv4 and IPv6
>       nodes, including the ability for IPv4 nodes to initiate
>       communication with IPv6 nodes using peer-to-peer techniques (i.e.,
>       using a rendezvous server and ICE).  To this end, NAT64 is
>       compliant with the recommendations for how NATs should handle UDP
>       [RFC4787], TCP [RFC4787], and ICMP [RFC5508].
>
> GT> //TCP [RFC4787]/TCP [RFC5382]
>
>    o  NAT64 supports IPv4 initiated communications to a subset of the
>       IPv6 hosts through statically configured bindings in the NAT64
>       device.
>
>    o  Compatible with ICE.
>
>
> GT> It would be better to spell things out a bit more clearly:
>   a) in the *absence* of any state in NAT64 regarding a given IPv6
> node, only said IPv6 node can initiate sessions to IPv4 nodes
>   b) depending on the filtering used (Endpoint-Independent,
> Address-Dependent, Address and Port-Dependent), IPv4-nodes MAY be able
> to initiate sessions to a given IPv6 node, if the NAT64 somehow has an
> appropriate mapping (i.e.,state) for said IPv6 node, via one of the
> following mechanism.
>           i) the IPv6 node has recently initiated a session to the
> same or other external-IPv4 node
>           ii) The IPv6 node has used ICE which essentially results in (i)
>           iii) if static configuration (i.e., mapping) exists
> regarding said IPv6 node
>
>    o  Supports additional features with some changes on nodes.  These
>       features include:
>
>       *  Support for DNSSEC
>
> GT> in some cases only though, no?
>
>       *  Some forms of IPsec support
>   

So, i have rephrased the section, used you text and now looks like

1.1.  Features of NAT64

   The features of NAT64 are:

   o  NAT64 as specified in this document is compliant with the
      recommendations for how NATs should handle UDP [RFC4787], TCP
      [RFC5382], and ICMP [RFC5508].  As such, NAT64 only supports
      Endpoint-Independent mappings and supports both Endpoint-
      Independent and Address dependent filtering.  Because of the
      compliance with the aforementioned requirements, NAT64 is
      compatible with ICE.

   o  In the absence of any state in NAT64 regarding a given IPv6 node,
      only said IPv6 node can initiate sessions to IPv4 nodes.  This
      works for roughly the same class of applications that work through
      IPv4-to-IPv4 NATs.

   o  Depending on the filtering policy used (Endpoint-Independent, or
      Address-Dependent), IPv4-nodes MAY be able to initiate sessions to
      a given IPv6 node, if the NAT64 somehow has an appropriate mapping
      (i.e.,state) for said IPv6 node, via one of the following
      mechanism.

      *  The IPv6 node has recently initiated a session to the same or
         other external-IPv4 node.

      *  The IPv6 node has used a NAT-traversal technique (such as ICE)
         which essentially results in the previous bullet point.

      *  If static configuration (i.e., mapping) exists regarding said
         IPv6 node

> 1.2.  Overview
>
>    This section provides a non-normative introduction to the mechanisms
>    of NAT64.
>
>    NAT64 mechanism is implemented in an NAT64 box which has two
>    interfaces, an IPv4 interface connected to the the IPv4 network, and
>    an IPv6 interface connected to the IPv6 network.
>
> GT> I think this is an overly simplistic view of the world.

Right, the goal of this section is to provide an introduction of the 
behaviour of the nat64, so that people can have an initial approach to 
the mechanism
I have added a clarification in this respect as follows:

    <t>This section provides a non-normative introduction to the mechanisms
     of NAT64.    This is achieved by describing the NAT64 behavior 
involving a simple
    setup, that involves a single NAT64 box, a single DNS64 box and a simple
    network topology. The goal of this description is to provide the 
reader with
    a general view of NAT64.  It is not the goal of this
    section to describe all possible configurations nor to provide a 
normative
    specification of the NAT64 behavior. The normative specification of 
NAT64
    is provided in <xref target="">.

>  If for the
> purpose of specification this makes descriptions easier then so be it
> but there should at least be a section towards the end of the document
> dealing with more complex scenarios where more than two interfaces
> exist, IPv4-only, IPv6-only, and dual stack nodes are mixed in a given
> site; identification and handling of packets not needing translation
> etc, if there is interest in clarifying any of this we can discuss
> separately.
>   
Right, several people in the list have previously commented that it 
would be useful to have some operational guidelines of how to handle 
more complex scenarios, including multiple nat64 boxes multiple dns64 
and so on. My understanding is that we decided that it would be good to 
do that, but do it in a separated document.

>    Packets generated
>    in the IPv6 network for a receiver located in the IPv4 network will
>    be routed within the IPv6 network towards the NAT64 box.  The NAT64
>    box will translate them and forward them as IPv4 packets through the
>    IPv4 network to the IPv4 receiver.
>
> GT> We should not refer to NAT64 as a "box". Instead it is a function
> that may operate on any interface of any router device. As a function,
> NAT64 may only consider two IFs but a "box" may have many more IFs
> etc.
>   
throughout the document, we use different ways to refer to the NAT64, 
including NAT64, NAT64 mechanism, NAT64 function, NAT64 box and NAT64 
device.
It is clearly stated in several places that the NAT64 is a mechanism 
that is executed in a device.

When we use the expression NAT64 device or NAT64 box is basically 
because we are describing an aspect of the behaviour that is related to 
a box, for instance, it is clearer (to me at least) to send packet to a 
box than to send packets to a function.

So, while i agree wihth you that is a bit of an abuse of language, i 
think it is useful to refer to the NAT64 box (as a short for the box 
that is executing the NAT64 function)

If there is any particular case where the usage of the expression is 
really bothering you, we can discuss the specific case, but i would 
rather use it in some cases.

> The reverse takes place for
>    packets generated in the IPv4 network for an IPv6 receiver.  NAT64,
>    however, is not symmetric.  In order to be able to perform IPv6 -
>    IPv4 translation NAT64 requires state, binding an IPv6 address and
>    port (hereafter called an IPv6 transport address) to an IPv4 address
>    and port (hereafter called an IPv4 transport address).
>
>    Such binding state is created when the first packet flowing from the
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                  [Page 5]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    IPv6 network to the IPv4 network is translated.  After the binding
>    state has been created, packets flowing in either direction on that
>    particular flow are translated.  The result is that NAT64 only
>    supports communications initiated by the IPv6-only node towards an
>    IPv4-only node.  Some additional mechanisms, like ICE, can be used in
>    combination with NAT64 to provide support for communications
>    initiated by the IPv4-only node to the IPv6-only node.  The
>    specification of such mechanisms, however, is out of the scope of
>    this document.
>
> GT> I think the above is inaccurate in multiple levels.
> - static configuration is not mentioned
> - assuming filtering allows it, endpoint independent mappings mean
> that even w/o ICE, an IPv4 node may be able to contact an IPv6 node
> itf the latter has initiated a session to the same or other IPv4 node.
>
>   
Right, i have rephrased the paragrpah as follows, to capture that:

     Such binding state is either statically configured in the NAT64 or 
it is
     created when the first packet flowing from the
     IPv6 network to the IPv4 network is translated. After the binding state
     has been created, and if the filtering policy permits,
     packets flowing in either direction on that particular
     flow are translated. The result is that, in the general case, NAT64 
only supports
     communications initiated by the IPv6-only node towards an IPv4-only
     node. Some additional mechanisms (like ICE) or static binding 
configuration, can be used
     to provide support for communications initiated by the
     IPv4-only node to the IPv6-only node.

> 1.2.1.  NAT64 solution elements
>
>    In this section we describe the different elements involved in the
>    NAT64 approach.
>
>    The main component of the proposed solution is the translator itself.
>    The translator has essentially two main parts, the address
>    translation mechanism and the protocol translation mechanism.
>
>    Protocol translation from IPv4 packet header to IPv6 packet header
>    and vice-versa is performed according to IP/ICMP Translation
>    Algorithm [I-D.ietf-behave-v6v4-xlate].
>
>    Address translation maps IPv6 transport addresses to IPv4 transport
>    addresses and vice-versa.  In order to create these mappings the
>    NAT64 box has two pools of addresses i.e. an IPv6 address pool (to
>    represent IPv4 addresses in the IPv6 network) and an IPv4 address
>    pool (to represent IPv6 addresses in the IPv4 network).  Since there
>    is enough IPv6 address space, it is possible to map every IPv4
>    address into a different IPv6 address.
>
>    NAT64 creates the required mappings by using as the IPv6 address pool
>    an IPv6 IPv6 prefix (hereafter called Pref64::/n).  This allows each
>    IPv4 address to be mapped into a different IPv6 address by simply
>    concatenating the Pref64::/n prefix assigned as the IPv6 address pool
>    of the NAT64, with the IPv4 address being mapped and a suffix (i.e.
>    an IPv4 address X is mapped into the IPv6 address Pref64:X:SUFFIX).
>    The NAT64 prefix Pref64::/n is assigned by the administrator of the
>    NAT64 box from the global unicast IPv6 address block assigned to the
>    site.
>
>    The IPv4 address pool is a set of IPv4 addresses, normally a small
>    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.  So, mappings using the IPv4 address pool will be created
>    and released dynamically.  Moreover, because of the IPv4 address
>    scarcity, the usual practice for NAT64 is likely to be the mapping of
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                  [Page 6]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    IPv6 transport addresses into IPv4 transport addresses, instead of
>    IPv6 addresses into IPv4 addresses directly, which enable a higher
>    utilization of the limited IPv4 address pool.
>
>    Because of the dynamic nature of the IPv6 to IPv4 address mapping and
>    the static nature of the IPv4 to IPv6 address mapping, it is easy to
>    understand that it is far simpler to allow communication initiated
>    from the IPv6 side toward an IPv4 node, which address is permanently
>
> GT> instead of "permanently" maybe use the term "deterministically" or
> maybe  "algorithmically"?
>   

ok

>    mapped into an IPv6 address, than communications initiated from IPv4-
>    only nodes to an IPv6 node in which case IPv4 address needs to be
>    associated with it dynamically.  For this reason NAT64 supports only
>    communications initiated from the IPv6 side.
>
> GT> Delete the last statement, which is NOT true given possible static
> configuration as well as some other rather peculiar tricks the
> document supports below for p2p apps etc.
>   
done

>    An IPv6 initiator can know or derive in advance the IPv6 address
>    representing the IPv4 target and send packets to that address.  The
>    packets are intercepted by the NAT64 device, which associates an IPv4
>    transport address of its IPv4 pool to the IPv6 transport address of
>    the initiator, creating binding state, so that reply packets can be
>    translated and forwarded back to the initiator.  The binding state is
>    kept while packets are flowing.  Once the flow stops, and based on a
>    timer, the IPv4 transport address is returned to the IPv4 address
>    pool so that it can be reused for other communications.
>
>    To allow an IPv6 initiator to do the standard DNS lookup to learn the
>    address of the responder, DNS64 [I-D.ietf-behave-dns64] is used to
>    synthesize an AAAA RR from the A RR (containing the real IPv4 address
>    of the responder).  DNS64 receives the DNS queries generated by the
>    IPv6 initiator.  If there is no AAAA record available for the target
>    node (which is the normal case when the target node is an IPv4-only
>    node), DNS64 performs a query for the A record.  If an A record is
>    discovered, DNS64 creates a synthetic AAAA RR that includes the IPv6
>    representations of the IPv4 address created by concatenating the
>    Pref64::/n of a NAT64 to the responder's IPv4 address and a suffix
>    (i.e. if the IPv4 node has IPv4 address X, then the synthetic AAAA RR
>    will contain the IPv6 address formed as Pref64:X:SUFFIX).  The
>    synthetic AAAA RR is passed back to the IPv6 initiator, which will
>    initiate an IPv6 communication with the IPv6 address associated to
>    the IPv4 receiver.  The packet will be routed to the NAT64 device,
>    which will create the IPv6 to IPv4 address mapping as described
>    before.
>
> 1.2.2.  Walkthrough
>
>    In this example, we consider an IPv6 node located in a IPv6-only site
>    that initiates a communication to a IPv4 node located in the IPv4
>    network.
>
>    The notation used is the following: upper case letters are IPv4
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                  [Page 7]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    addresses; upper case letters with a prime(') are IPv6 addresses;
>    lower case letters are ports; prefixes are indicated by "P::X", which
>    is a IPv6 address built from an IPv4 address X by adding the prefix
>    P, mappings are indicated as "(X,x) <--> (Y',y)".
>
>    The scenario for this case is depicted in the following figure:
>
>
>      +---------------------------------------+       +---------------+
>      |IPv6 network    +-------------+        |       |               |
>      |  +----+        | Name server |   +-------+    |   IPv4        |
>      |  | H1 |        | with DNS64  |   | NAT64 |----| Network       |
>      |  +----+        +-------------+   +-------+    |               |
>      |    |IP addr: Y'     |              |  |       |  IP addr: X   |
>      |    ---------------------------------  |       |  +----+       |
>      +---------------------------------------+       |  | H2 |       |
>                                                      |  +----+       |
>                                                      +---------------+
>
>    The figure shows a IPv6 node H1 which has an IPv6 address Y' and an
>    IPv4 node H2 with IPv4 address X.
>
>    A NAT64 connects the IPv6 network to the IPv4 network.  This NAT64
>    has a /n prefix (called Pref64::/n) that it uses to represent IPv4
>    addresses in the IPv6 address space and an IPv4 address T assigned to
>    its IPv4 interface. the routing is configured in such a way, that the
>    IPv6 packets addressed to a destination address containing Pref64::/n
>    are routed to the IPv6 interface of the NAT64 box.
>
> GT> I think it might be good to indicate that for this site,
> Pref64::/n is uniquely used for mapping the IPv4 address space  to
> IPv6 i.e., no address from Pref64::/n is to be assigned to a native
> IPv6 interface. It should also be said that Pref64::/ should only be
> given to a single NAT64 in a given site. Anything other than that
> requires a lot more explanation.
>   
the reccomendations about how to assign the prefix and what to do with 
it are contained in
http://www.ietf.org/id/draft-ietf-behave-address-format-01.txt

I think they are better there, since they address both stateful and 
stateless considerations

>
>    Also shown is a local name server with DNS64 functionality.  The
>    local name server needs to know the /n prefix assigned to the local
>    NAT64 (Pref64::/n).  For the purpose of this example, we assume it
>    learns this through manual configuration.
>
>    For this example, assume the typical DNS situation where IPv6 hosts
>    have only stub resolvers and the local name server does the recursive
>    lookups.
>
>    The steps by which H1 establishes communication with H2 are:
>
>    1.  H1 performs a DNS query for FQDN(H2) and receives the synthetic
>        AAAA RR from the local name server that implements the DNS64
>        functionality.  The AAAA record contains an IPv6 address formed
>        by the Pref64::/n associated to the NAT64 box and the IPv4
>        address of H2 and a suffix.
>
>    2.  H1 sends a packet to H2.  The packet is sent from a source
>        transport address of (Y',y) to a destination transport address of
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                  [Page 8]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>        (Pref64:X:SUFFIX,x), where y and x are ports set by H1.
>
>    3.  The packet is routed to the IPv6 interface of the NAT64 (since
>        the IPv6 routing is configured that way).
>
>    4.  The NAT64 receives the packet and performs the following actions:
>
>        *  The NAT64 selects an unused port t on its IPv4 address T and
>           creates the mapping entry (Y',y) <--> (T,t)
>
>        *  The NAT64 translates the IPv6 header into an IPv4 header using
>           IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate].
>
>        *  The NAT64 includes (T,t) as source transport address in the
>           packet and (X,x) as destination transport address in the
>           packet.  Note that X is extracted directly from the
>           destination IPv6 address of the received IPv6 packet that is
>           being translated.
>
>    5.  The NAT64 sends the translated packet out its IPv4 interface and
>        the packet arrives at H2.
>
>    6.  H2 node responds by sending a packet with destination transport
>        address (T,t) and source transport address (X,x).
>
>    7.  The packet is routed to the NAT64 box, which will look for an
>        existing mapping containing (T,t).  Since the mapping (Y',y) <-->
>        (T,t) exists, the NAT64 performs the following operations:
>
>        *  The NAT64 translates the IPv4 header into an IPv6 header using
>           IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate].
>
>        *  The NAT64 includes (Y',y) as destination transport address in
>           the packet and (Pref64:X:SUFFIX,x) as source transport address
>           in the packet.  Note that X is extracted directly from the
>           source IPv4 address of the received IPv4 packet that is being
>           translated.
>
>    8.  The translated packet is sent out the IPv6 interface to H1.
>
>    The packet exchange between H1 and H2 continues and packets are
>    translated in the different directions as previously described.
>
>    It is important to note that the translation still works if the IPv6
>    initiator H1 learns the IPv6 representation of H2's IPv4 address
>    (i.e.  Pref64:X:SUFFIX) through some scheme other than a DNS look-up.
>    This is because the DNS64 processing does NOT result in any state
>    installed in the NAT64 box and because the mapping of the IPv4
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                  [Page 9]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    address into an IPv6 address is the result of concatenating the
>    prefix defined within the site for this purpose (called Pref64::/n in
>    this document) to the original IPv4 address and a suffix.
>
> 1.2.3.  Filtering
>
>    A NAT64 box may do filtering, which means that it only allows a
>    packet in through an interface if the appropriate permission exists.
>    A NAT64 may do no filtering, or it may filter on its IPv4 interface.
>    Filtering on the IPv6 interface is not supported, as mappings are
>    only created by packets traveling in the IPv6 --> IPv4 direction.
>
> GT> Again this NOT strictly true given the rest of the document. What
> is it that you mean here by "filtering on the IPv6 interface"?
>   
I have changed the references to IPv6 interface to incoming IPv6 packets.
In addition, i have rewritten the section to account for the comments 
you make below

the reuslt is:

       <t>A NAT64 box may do filtering, which means that it only allows a
       packet in through an interface if the appropriate permission 
exists. A
       NAT64 may do no filtering, or it may filter incoming IPv4 packets.
       Filtering of incoming IPv6 packets is not described in this 
specification.</t>

       <t>NAT64 filtering is consistent with the recommendations of RFC
       4787 <xref target="RFC4787"></xref>, and the ones of
        RFC 5382 <xref target="RFC5382"></xref>. Because of that, the NAT64
        as specified in this document, supports both 
Endpoint-Independent filtering
        and Address-Dependent filtering, both for TCP and UDP.</t>

        <t>If a NAT64 performs Endpoint-Independent filtering of 
incoming IPv4 packets,
            then an incoming IPv4 packet is dropped unless the NAT64 has 
state for the
            destination transport address of the incoming IPv4 packet.</t>

       <t>
        If a NAT64 performs Address-Dependent filtering of incoming IPv4 
packets, then an incoming IPv4 packet is dropped
        unless the NAT64 has state involving the destination transport 
address of the IPv4 incoming packet
        and the particular source IP address of the incoming IPv4 
packet.</t>

>    If a NAT64 performs address-dependent filtering according to RFC4787
>    [RFC4787] on its IPv4 interface, then an incoming packet is dropped
>    unless a packet has been recently sent out the interface with a
>    source transport address equal to the destination transport address
>    of the incoming packet and destination IP address equal to the source
>    IP address of the incoming packet.
>
>    NAT64 filtering is consistent with the recommendations of RFC 4787
>    [RFC4787], and the ones of RFC 5382 [RFC5382]
>
>
> GT> I think this section should be re-written. RFCs4787/5382 provide
> very detailed requirements and reasoning for each type of filtering,
> most of which is lost in this section. The brief description of only
> some cases is misleading and over-simplified. Since it is rather
> pointless to repeat the contents of these RFCs, It would be beneficial
> to simply list the known filtering behaviours ("Endpoint-Independent
> Filtering", "Address-Dependent Filtering", "Address and Port-Dependent
> Filtering") and then summarize what the quoted RFCs recommend i.e. use
> Endpoint-Independent Filtering whenever possible, use
> Address-Dependent Filtering when you have to, and avoid using Address
> and Port-Dependent Filtering if at all possible. Then the reader
> should be encourage to really read these quoted RFCs to get all the
> details, w/o which it is actually very difficult to understand the
> rest of this document.
>
>   
right, see above

> 2.  Terminology
>
>    This section provides a definitive reference for all the terms used
>    in document.
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].
>
>    The following terms are used in this document:
>
>    3-Tuple:  The tuple (source IP address, destination IP address, Query
>       Identifier).  A 3-tuple uniquely identifies an ICMP Query session.
>       When an ICMP Query session flows through a NAT64, each session has
>       two different 3-tuples: one with IPv4 addresses and one with IPv6
>       addresses.
>
>    5-Tuple:  The tuple (source IP address, source port, destination IP
>       address, destination port, transport protocol).  A 5-tuple
>       uniquely identifies a UDP/TCP session.  When a UDP/TCP session
>       flows through a NAT64, each session has two different 5-tuples:
>       one with IPv4 addresses and one with IPv6 addresses.
>
>
>
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 10]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    BIB:  Binding Information Base.  A table of mappings kept by a NAT64.
>       Each NAT64 has three BIBs, one for TCP, one for UDP and one for
>       ICMP Queries.
>
>    DNS64:  A logical function that synthesizes AAAA Resource Records
>       (containing IPv6 addresses) from A Resource Records (containing
>       IPv4 addresses).
>
>    Endpoint-Independent Mapping:  In NAT64, using the same mapping for
>       all the sessions involving a given IPv6 transport address of an
>       IPv6 host (irrespectively of the transport address of the IPv4
>       host involved in the communication).  Endpoint-independent mapping
>       is important for peer-to-peer communication.  See [RFC4787] for
>       the definition of the different types of mappings in IPv4-to-IPv4
>       NATs.
>
> GT> It would probably be useful to also include the terms "Address-
>       Dependent" and "Address and Port-Dependent"
>   

mmm, in this spec we don't use other forms of mappings (i.e. address 
dependent mappings or address and port dependent mappings)

It would make sense to add a definition of endpoint independent 
filtering and address dependent filtering i guess.
I don't think it is worth adding the definition of address and and port 
dependent filtering, as it is not supported.

I have added:

         <t hangText="Endpoint-Independent Filtering:"> The NAT64 
filters out
         only incoming IPv4 packets not destined to a transport address for
         which there is not state in the NAT64, regardless of the source
         IPv4 transport address. The NAT forwards any packets destined to
         any transport address for which it has state. 
         In other words, having state for a given transport address is 
sufficient
         to allow any packets back to the internal endpoint.</t>

           <t hangText="Address-Dependent Filtering:">
         The NAT64 filters out incoming IPv4 packets not destined to a 
transport
         address for which there is no state (similar to the 
Endpoint-Independent
         filtering).  Additionally, the NAT64 will filter out incoming
         IPv4 packets coming from IPv4 address X and
         destined for a transport address that it has state for if the 
NAT64 has not
         sent packets to X previously (independently of the port
         used by X).
         In other words, for receiving packets from a
         specific IPv4 endpoint, it is necessary for the IPv6
         endpoint to send packets first to that specific IPv4
         endpoint's IP address.</t>

>    Hairpinning:  Having a packet do a "U-turn" inside a NAT and come
>       back out the same interface as it arrived on.  Hairpinning support
>       is important for peer-to-peer applications, as there are cases
>       when two different hosts on the same side of a NAT can only
>       communicate using sessions that hairpin through the NAT.
>
>    Mapping:  A mapping between an IPv6 transport address and a IPv4
>       transport address.  Used to translate the addresses and ports of
>       packets flowing between the IPv6 host and the IPv4 host.  In
>       NAT64, the IPv4 transport address is always a transport address
>       assigned to the NAT64 itself, while the IPv6 transport address
>       belongs to some IPv6 host.
>
> GT> What about the term  "Filtering"?
>   
Filtering as the general concept is defined in the previous section

I have added the definition the both flavours of filtering that we use
>    NAT64:  A device that translates IPv6 packets to IPv4 packets and
>       vice-versa, with the provision that the communication must be
>       initiated from the IPv6 side.  The translation involves not only
>       the IP header, but also the transport header (TCP or UDP).
>
>    Session:  A TCP, UDP or ICMP Query session.  In other words, the bi-
>       directional flow of packets between two ports on two different
>       hosts.  In NAT64, typically one host is an IPv4 host, and the
>       other one is an IPv6 host.
>
>    Session table:  A table of sessions kept by a NAT64.  Each NAT64 has
>       three session tables, one for TCP, one for UDP and one for ICMP
>       Queries.
>
>    Synthetic RR:  A DNS Resource Record (RR) that is not contained in
>       any zone data file, but has been synthesized from other RRs.  An
>       example is a synthetic AAAA record created from an A record.
>
>
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 11]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    Transport Address:  The combination of an IPv6 or IPv4 address and a
>       port.  Typically written as (IP address, port); e.g. (192.0.2.15,
>       8001).
>
>    Tuple:  Refers to either a 3-Tuple or a 5-tuple as defined above.
>
>    For a detailed understanding of this document, the reader should also
>    be familiar with DNS terminology [RFC1035] and current NAT
>    terminology [RFC4787].
>
>
> 3.  NAT64 Normative Specification
>
>    A NAT64 is a device with at least one IPv6 interface and at least one
>    IPv4 interface.  Each NAT64 device MUST have one unicast /n IPv6
>    prefix assigned to it, denoted Pref64::/n.  Additional consideration
>    about the Pref64::/n are presented in Section 3.2.5.  Each NAT64 box
>    MUST have one or more unicast IPv4 addresses assigned to it.
>
>    A NAT64 uses the following dynamic data structures:
>
>    o  UDP Binding Information Base
>
>    o  UDP Session Table
>
>    o  TCP Binding Information Base
>
>    o  TCP Session Table
>
>    o  ICMP Query Binding Information Base
>
>    o  ICMP Query Session Table
>
>    A NAT64 has three Binding Information Bases (BIBs): one for TCP, one
>    for UDP and one for ICMP Queries.  In the case of UDP and TCP BIBs,
>    each BIB entry specifies a mapping between an IPv6 transport address
>    and an IPv4 transport address:
>
>       (X',x) <--> (T,t)
>
> GT> This notation is very useful, I wish you used it much more in the
> descriptions below...see more on that later.
>   

any specific suggestions of were the usage of this notation could be useful?
>    where X' is some IPv6 address, T is an IPv4 address, and x and t are
>    ports.  T will always be one of the IPv4 addresses assigned to the
>    NAT64.  A given IPv6 or IPv4 transport address can appear in at most
>    one entry in a BIB: for example, (2001:db8::17, 4) can appear in at
>    most one TCP and at most one UDP BIB entry.
>
> GT> Maybe it should be noted that this is what implements/ensure
> "Endpoint-Independent mappings"?.
>   

Right, i have added

This implementation of the BIBs ensures Endpoint-Independent mappings in 
the NAT64.
>    TCP and UDP have
>    separate BIBs because the port number space for TCP and UDP are
>    distinct.
>
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 12]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    In the case of the ICMP Query BIB, each ICMP Query BIB entry specify
>    a mapping between an (IPv6 address, Query Identifier) pair and an
>    (IPv4 address, Query Identifier pair).
>
>       (X',I1) <--> (T,I2)
>
>    where X' is some IPv6 address, T is an IPv4 address, and I1 and I2
>    are Query Identifiers.  T will always be one of the IPv4 addresses
>    assigned to the NAT64.  A given (IPv6 or IPv4 address, Query Id) pair
>    can appear in at most one entry in the ICMP Query BIB.
>
>    Entries in any of the three BIBs can be created dynamically as the
>    result of the flow of packets as described in the section Section 3.2
>    but the can also can be created manually by the system administrator.
>
> GT> //can also can/can also
>
>   

ok
>    NAT64 implementations SHOULD support manually configured BIB entries
>    for any of the three BIBs.  Dynamically-created entries are deleted
>    from the corresponding BIB when the last session associated to the
>    BIB entry is removed from the session table.
>
> GT> MUST/SHOULD/MAY??? sounds like a SHOULD to me. or is a MUST if
> associated with a max-wait time.
>
>   
mmm, i think this is how the mechanism work, didn't wanted to abuse on 
the usage of the normative language, i think it should be either a 
SHOULD or a MUST, but i am not convinced we need to use normative 
language for this

>    Manually-configured BIB
>    entries are not deleted when there is no corresponding session table
>    entry and can only be deleted by the administrator.
>
>
> GT> All of the text above regarding BIBs, says what BIBs are but it
> does not say what BIBs are for. e.g.,

well, BIBs contain the mapping information, and that is mentioned earlier.
In any case, i have added text stating that endpoint indpeepndet 
filtering is implemented using the bibs.

The resulting text is:

       <t>A NAT64 has three Binding Information Bases (BIBs): one for 
TCP, one for
       UDP and one for ICMP Queries. In the case of UDP and TCP BIBs, each
         BIB entry specifies a mapping between an IPv6 transport address
       and an IPv4 transport address:<list>
           <t>(X',x) &lt;--&gt; (T,t)</t>
         </list>where X' is some IPv6 address, T is an IPv4 address, and 
x and t
       are ports. T will always be one of the IPv4 addresses assigned to 
the NAT64.
       A given IPv6 or IPv4 transport address can appear
       in at most one entry in a BIB: for example, (2001:db8::17, 4) can
       appear in at most one TCP and at most one UDP BIB entry. TCP and UDP
       have separate BIBs because the port number space for TCP and UDP are
       distinct. This implementation of the BIBs ensures 
Endpoint-Independent mappings in the NAT64.
        The information in the BIBs is also used to implement 
Endpoint-Independent filtering.
        (Address-Dependent filtering is implemented using the Session 
tables described below.)</t>

>  BIBs implement
> "Endpoint-Independent filtering"....other types of filtering can be
> implemented with session entries. All session table entries MUST have
> corresponding BIB entries. right?
>
>    A NAT64 also has three session tables: one for TCP sessions, one for
>    UDP sessions and one for ICMP Query sessions.  Each entry keeps
>    information on the state of the corresponding session.  In the TCP
>    and UDP session tables, each entry specifies a mapping between a pair
>    of IPv6 transport address and a pair of IPv4 transport address:
>
>       (X',x),(Y',y) <--> (T,t),(Z,z)
>
>    where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and
>    x, y, z and t are ports.  T will always be one of the IPv4 addresses
>    assigned to the NAT64.  Y' is always the IPv6 representation of the
>    IPv4 address Z, so Y' is obtained from Z using the algorithm applied
>    by the NAT64 to create IPv6 representations of IPv4 addresses. y is
>    always equal to z.  In addition, each session table entry has a
>    lifetime.
>
> GT> Instead of "is" this and "will always be" that, consider using
> normative MUSTs.
>   
ok

>
>    In the ICMP query session table, each entry specifies a mapping
>    between a 3-tuple of IPv6 source address, IPv6 destination address
>    and ICMPv6 Query Id and a 3-tuple of IPv4 source address, IPv4
>    destination address and ICMPv4 Query Id:
>
>       (X',Y',I1) <--> (T,Z,I2)
>
>    where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and
>    I1 and I2 are ICMP query Ids. T will always be one of the IPv4
>    addresses assigned to the NAT64.  Y' is always the IPv6
>    representation of the IPv4 address Z, so Y' is obtained from Z using
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 13]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    the algorithm applied by the NAT64 to create IPv6 representations of
>    IPv4 addresses.  In addition, each session table entry has a
>    lifetime.
>
>    The NAT64 uses the session state information to determine when the
>    session is completed, and also uses session information for ingress
>    filtering.
>
> GT> what kind? Address-Dependent? Address and Port-Dependent
> Filtering? both? other?
>   

Address dependent filtering, i ahve removed the ingress filtering cause 
is indeed misleading and stated that this is for address dependent 
filtering.

>  A session can be uniquely identified by either an
>    incoming tuple or an outgoing tuple.
>
> GT> what is "ingress" in this context?
>
>   
I have removed the ingress from above

>    For each session, there is a corresponding BIB entry, uniquely
>    specified by either the source IPv6 transport address or the source
>    IPv6 address and ICMPv6 Query Id (in the IPv6 --> IPv4 direction) or
>    the destination IPv4 transport address or the destination IPv4
>    address and the ICMPv4 Query Id (in the IPv4 --> IPv6 direction).
>
> GT> It is not clear why the above is ICMP specific and why the BIB
> entry can be identified in so many different ways. I am a bit
> confused.
>   

right, the thing is that UDP and TCP sessions are identified in one way, 
while ICMP queries sessions are identified in another way.
I have rewritten the paragraph as follows:

   For each TCP or UDP session, there is a corresponding BIB entry,
   uniquely specified by either the source IPv6 transport address (in
   the IPv6 --> IPv4 direction) or the destination IPv4 transport
   address (in the IPv4 --> IPv6 direction).  For each ICMP Query
   session, there is a corresponding BIB entry, uniquely specified by
   either the source IPv6 address and ICMPv6 Query Id (in the IPv6 -->
   IPv4 direction) or the destination IPv4 address and the ICMPv4 Query
   Id (in the IPv4 --> IPv6 direction).  However, for all the BIBs, a
   single BIB entry can have multiple corresponding sessions.  When the
   last corresponding session is deleted, if the BIB entry was
   dynamically created, the BIB entry is deleted.

>    However, a single BIB entry can have multiple corresponding sessions.
>    When the last corresponding session is deleted, if the BIB entry was
>    dynamically created, the BIB entry is deleted.
>
> GT> this was said also earlier...see if one instance can be removed.
>
>   
mmm, i would preffer keep this both in the bib description and the 
session table description
If someone else complains, i will remove it

>    The processing of an incoming IP packet takes the following steps:
>
>    1.  Determining the incoming tuple
>
>    2.  Filtering and updating binding and session information
>
>    3.  Computing the outgoing tuple
>
>    4.  Translating the packet
>
>    5.  Handling hairpinning
>
>    The details of these steps are specified in the following
>    subsections.
>
>    This breakdown of the NAT64 behavior into processing steps is done
>    for ease of presentation.  A NAT64 MAY perform the steps in a
>    different order, or MAY perform different steps, as long as the
>    externally visible outcome is the same.
>
> 3.1.  Determining the Incoming tuple
>
> GT> It would be helpful to make clear what "incoming IP packet" the
> text refers to. Since no IP version is indicated, I assume that this
> section is common to all IPv4, IPv6, and ICMP packets received by the
> NAT64 function.
>
>   

I have added this text:

       <t>The NAT64 will receive packet through its interfaces. These 
packets can be either IPv6
        packets or IPv4 packets and they may carry TCP traffic, UDP 
traffic or ICMP. The processing
        of the packets will be described next. In the case that the 
processing is common to all the aforementioned
        types of packets, we will refer to the packet as the incoming 
packet in general. In case that the processing
        is specific to IPv6 packets, we will refer to the incoming IPv6 
packet and similarly to the IPv4 packets.</t>

>    This step associates a incoming tuple with every incoming IP packet
>    for use in subsequent steps.  In the case of TCP, UDP and ICMP error
>    packets, the tuple is a 5-tuple consisting of source IP address,
>    source port, destination IP address, destination port, transport
>    protocol.  In case of ICMP Queries, the tuple is a 3-tuple consisting
>    of the source IP address, destination IP address and Query
>    Identifier.
>
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 14]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    If the incoming IP packet contains a complete (un-fragmented) UDP or
>    TCP protocol packet, then the 5-tuple is computed by extracting the
>    appropriate fields from the packet.
>
>    If the incoming packet is an ICMP query message (i.e. an ICMPv4 Query
>    message or an ICMPv6 Informational message), the 3-tuple is the
>    source IP address. the destination IP address and the ICMP Query
>    Identifier.
>
>    If the incoming IP packet contains a complete (un-fragmented) ICMP
>    error message, then the 5-tuple is computed by extracting the
>    appropriate fields from the IP packet embedded inside the ICMP error
>    message.  However, the role of source and destination is swapped when
>    doing this: the embedded source IP address becomes the destination IP
>    address in the 5-tuple, the embedded source port becomes the
>    destination port in the 5-tuple, etc.  If it is not possible to
>    determine the 5-tuple (perhaps because not enough of the embedded
>    packet is reproduced inside the ICMP message), then the incoming IP
>    packet is silently discarded.
>
>       NOTE: The transport protocol is always one of TCP or UDP, even if
>       the IP packet contains an ICMP Error message.
>
> GT> I do not understand this note.
>
>   
I have removed it

>    If the incoming IP packet contains a fragment, then more processing
>    may be needed.  This specification leaves open the exact details of
>    how a NAT64 handles incoming IP packets containing fragments, and
>    simply requires that a NAT64 handle fragments arriving out-of-order.
>    A NAT64 MAY elect to queue the fragments as they arrive and translate
>    all fragments at the same time.  Alternatively, a NAT64 MAY translate
>    the fragments as they arrive, by storing information that allows it
>    to compute the 5-tuple for fragments other than the first.  In the
>    latter case, the NAT64 will still need to handle the situation where
>    subsequent fragments arrive before the first.
>
> GT> Has the option of NAT64 reassembling packets before translating
> been discussed at all?
>   

not sure what the question is here, but i have rewritten this section 
already as result from the discussions in the ml and the new text is:

   If the incoming IP packet contains a fragment, then more processing
   may be needed.  This specification leaves open the exact details of
   how a NAT64 handles incoming IP packets containing fragments, and
   simply requires that the external behavior of the NAT64 is compliant
   with the following conditions:

      The NAT64 MUST handle fragments arriving out-of-order conditioned
      to the following:

         The NAT64 MUST limit the amount of resources devoted to the
         storage of fragmented packets in order to prevent from DoS
         attack.

         The NAT64 MUST allow the fragments to arrive over a time
         interval.  The time interval MUST be configurable and the
         default value MUST be of at least 10 seconds.

         The NAT64 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the first fragment.

      A NAT64 MAY elect to queue the fragments as they arrive and
      translate all fragments at the same time.  Alternatively, a NAT64
      MAY translate the fragments as they arrive, by storing information
      that allows it to compute the 5-tuple for fragments other than the
      first.  In the latter case, subsequent fragments may arrive before
      the first.

      Implementers of NAT64 should be aware that there are a number of
      well-known attacks against IP fragmentation; see [RFC1858] and
      [RFC3128].  Implementers should also be aware of additional issues
      with reassembling packets at high rates, described in [RFC4963].

> GT> On a different note, this section is supposed to be about
> "determining the incoming tuple". I think handling fragments should
> only be discussed in as far as it is needed to determine the
> tuple....other fragmentation concerns (i.e., most of the rest of the
> text) should not be here IMO.
>
>   
but the only difficulty in handling fragments is that fragments other 
than the first one do not contain the port information so we need to do 
extra work to determine the incoming tuple, so i still think it is a 
reasonable match to describe it here, since it is most of the work.

>    Implementors of NAT64 should be aware that there are a number of
>    well-known attacks against IP fragmentation; see [RFC1858] and
>    [RFC3128].
>
>    Assuming it otherwise has sufficient resources, a NAT64 MUST allow
>    the fragments to arrive over a time interval of at least 10 seconds.
>    A NAT64 MAY require that the UDP, TCP, or ICMP header be completely
>    contained within the first fragment.
>
>    Except from the retrieval of 5-tuple information from the incoming
>    packets as discussed above, all other fragmentation and PMTUD related
>    processing performed by the NAT64 device is performed as defined in
>    [I-D.ietf-behave-v6v4-xlate], including the translation of all
>    related fragmentation fields in the IP header, the determination of
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 15]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>    the outgoing packet size, the fragmentation of outgoing packets and
>    the generation and processing of ICMP Packet Too Big errors.
>
>    In particular, the NAT64 must generate ICMP Packet Too Big error
>    messages in the case the outgoing packet does not fit in the outgoing
>    MTU and needs to be discarded.
>
> GT> Is this correct? Section 2.1 of [I-D.ietf-behave-v6v4-xlate]
> indicates that IPv4 packets can be fragmented further to fit in IPv6
> packets... why don't we just stay silent on the issue and just point
> to [I-D.ietf-behave-v6v4-xlate]?
>   
will do that i.e. i will simply remove the last paragraph and leave the 
previous one with a pointer to the xlate

> 3.2.  Filtering and Updating Binding and Session Information
>
>    This step updates binding and session information stored in the
>    appropriate tables.  This step may also filter incoming packets, if
>    desired.
>
>    Irrespectively of the transport protocol used, the NAT64 must
>    silently discard all incoming IPv6 packets containing a source
>    address that contains the Pref64::/n.  This is required in order to
>    prevent hairpinning loops as described in the Security Considerations
>    section.
>
>    The details of this step depend on the protocol (UDP TCP or ICMP
>    Query).
>
> 3.2.1.  UDP Session Handling
>
>    The state information stored for a UDP session in the UDP session
>    table includes a timer that tracks the remaining lifetime of the UDP
>    session.  The NAT64 decrements this timer at regular intervals.  When
>    the timer expires, the UDP session is deleted.  If all the UDP
>    sessions corresponding to a UDP BIB entry are deleted, then the UDP
>    BIB entry is also deleted (only applies to the case of dynamically
>    created entries).
>
> GT> I commented on this earlier so align any changes you make earlier with this.
>   
mmm, i think this text is coherent with the previous text including the 
changes, not sure if you think something needs to be changed here...

>    An IPv6 incoming packet is processed as follows:
>
> GT> Presumably such a packet is only processed if the destination
> address is from Pref64::/n? It would help to state this.
>
>   

right, i have added earlier in the general part common to TCP, UDP and ICMP

     NAT64 function will only process incoming
     IPv6 packet that contain a destination address that contains 
Pref64::/n.
>       The NAT64 searches for a UDP BIB entry that matches the IPv6
>       source transport address.  If such entry does not exists, a new
>       entry is created.  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
>       IPv4 address.
>
> GT> The last sentence does not read well. It would help to be more
> exact in this and subsequent descriptions. For example: the new BIB
> entry has the form of  (Y*,y)<->(T,t), where Y* is set to the source
> IPv6 address of the packet, y is set to the source port number of the
> packet, T is one of the NAT64's IPv4 addresses used for translation
> and t is set to an unused port number on the selected IPv4 address T.
>   

I have rewritten this. I include all the text below. I have prefered to 
explicitly define the fields of the BIB and make refgerecne to that. I 
have used thisnotation for the session table

>       The NAT64 searches for the session table entry corresponding to
>       the incoming 5-tuple.
>
> GT> This search, I assume is only meaningful if there was already a
> BIB entry? If the BIB entry was just created based on the last
> paragraph, there is no point in searching the session table, right?
>   
right, not sure it worth adding another conditional if here for this, 
though (i mean, the condition is trivially met)

>       If no such entry is found, a new entry is
>       created.  The information included in the session table is as
>       follows: the IPv6 transport source and destination addresses
>       contained in the received IPv6 packet, the IPv4 transport source
>       address is extracted from the corresponding UDP BIB entry and the
>       IPv4 transport destination address contains the same port as the
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 16]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>       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.
>
> GT> Again, reading this makes my head hurt. I think this could be much
> clearer if you use the (X',x),(Y',y) <--> (T,t),(Z,z) and say how
> these values are set based on the incoming packet.
>
>   
done that, or at least i have tried
see below
>       The NAT64 sets or resets the timer in the session table entry to
>       maximum session lifetime.  By default, the maximum session
>       lifetime is 5 minutes, but for specific destination ports in the
>       Well-Known port range (0..1023), the NAT64 MAY use a smaller
>       maximum lifetime.
>
> GT> It would be nice to indicate why a smaller mac lifetime is suggested here.
>
>   

right,

i have added,

Note: The reason why the lifetime for the sessions involving
                        Well-Known ports can be shorter than the 
recommended
                        default value is to allow greater reutilization 
of the
                        pool of transport addresses of the NAT64 for 
bindings
                        involving the Well-Known ports, since it is less 
likely that
                        the application using these ports will use the 
NAT traversal
                        techniques that rely on having a binding alive 
to enable incoming
                        communications.</t>

>   The packet is translated and forwarded as
>       described in the following sections.
>
>    An IPv4 incoming packet is processed as follows:
>
>       The NAT64 searches for a UDP BIB entry that matches the IPv4
>       destination transport address.
>
> GT> More accurately: Given the BIB entries are of the form
> (Y*,y)<->(T,t), NAT64 attempts to match the destination IPv4 transport
> address to the (T,t) part of the BIB entires.
>   

i ahve rewritten the whole thing, hopefully is clearer noe
>      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,
>
> GT> You have to define what this means. if I understand correctly
> below you describes "Address and Port-Dependent Filtering" or is it
> "Address-Dependent Filtering"? it is hard to tell given that you try
> to match "addresses" with "transport addresses" which makes no sense.
>
>   
rephrased as:

               <t>If the NAT64
               applies Address-Dependent filters on its IPv4 interface, 
then the NAT64 checks to see if
               the incoming packet is allowed according to the
               address-dependent filtering rule.

> 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 transport address equal to the
>       destination IPv4 transport address in the incoming 5-tuple and
>       destination IPv4 address (in the session table entry) equal to the
>       source IPv4 address in the incoming 5-tuple.
>
> GT> This is really hard to parse.  If you use the (X',x),(Y',y) <-->
> (T,t),(Z,z) notation it all becomes much clearer. For example, here
> the NAT64 could implement "Address and Port-Dependent Filtering" by
> trying to match the destination IPv4 transport address in the packet
> with the (T,t) part, and the source IPv4 transport address of the
> packet with the (Z,z)  part, of the entries in the session table. Is
> this what you mean? If instead you do "Address-Dependent Filtering"
> you simply drop the t and z from the above.
>   
I have rewritttne this using this notation

> If such an entry is
>       found (there may be more than one), packet processing continues.
>
> GT> I do not get how there can be more than one of these.
>
>       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).
>
> GT> Now it gets really confusing. What follows is clearly not a
> continuation from the above. It looks like its a case where a session
> is allowed to be initiated from the IPv4 side; if that is the case
> then it should be clearly stated! Also does the following describe
> processing when NAT64 does NOT filter at all on IPv4? or when it does
> "Endpoint-Independent Filtering"? or " Address-Dependent Filtering"?
> It seems that the description below only assumes a matching BIB entry
> so my guess is that the following is based on "Endpoint-Independent
> Filtering"
>   

In order to link it with the previous paragraph, i have added

In case the packet is not discarded in the previous processing, then the 
NAT64 searches for the session table entry

>       The NAT64 searches for the session table entry corresponding to
>       the incoming 5-tuple.
>
> GT> Again you should use the  (X',x),(Y',y) <--> (T,t),(Z,z)  notation
> to make clear what "searching" means above, as well as to define how
> the new entry is "created" below.
>
>   
right, see below

>       If no such entry is found, a new entry is
>       created.  The UDP session table entry contains the transport
>       source and destination address contained in the IPv4 packet and
>       the source IPv6 transport address (in the IPv6 --> IPv4 direction)
>       contained in the existing UDP 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 NAT64 sets or resets the timer in the session table entry to
>       maximum session lifetime.  By default, the maximum session
>
>
>
> Bagnulo, et al.           Expires May 25, 2010                 [Page 17]
>
> Internet-Draft                    NAT64                    November 2009
>
>
>       lifetime is 5 minutes, but for specific destination ports in the
>       Well-Known port range (0..1023), the NAT64 MAY use a smaller
>       maximum lifetime.
>
>
> GT> OK...I am stopping here...lets see if any of the above makes sense
> to people and then I will continue.
>   

I have rewritten the UDP processing section as follwows:

In the BIB description i have written:

   A NAT64 has three Binding Information Bases (BIBs): one for TCP, one
   for UDP and one for ICMP Queries.  In the case of UDP and TCP BIBs,
   each BIB entry specifies a mapping between an IPv6 transport address
   and an IPv4 transport address:

      (X',x) <--> (T,t)

   where X' is some IPv6 address, T is an IPv4 address, and x and t are
   ports.  T will always be one of the IPv4 addresses assigned to the
   NAT64.  The BIB has then two columns, the BIB IPv6 transport address
   and the BIB IPv4 transport address.

In the Session table description is have written:

   For each Session Table Entry (STE), there are then five columns:

      The STE source IPv6 transport address, (X',x) in the example
      above,

      The STE destination IPv6 transport address, (Y',y) in the example
      above,

      The STE source IPv4 transport address, (T,t) in the example above,
      and,

      The STE destination IPv4 transport address, (Z,z) in the example
      above.

      The STE lifetime.

And then, the UDP processing is:
(i need to review the text to make sure that i didn't confuse any source 
with destination...)

3.2.1.  UDP Session Handling

   The state information stored for a UDP session in the UDP session
   table includes a timer that tracks the remaining lifetime of the UDP
   session.  The NAT64 decrements this timer at regular intervals.  When
   the timer expires, the UDP session is deleted.  If all the UDP
   sessions corresponding to a UDP BIB entry are deleted, then the UDP
   BIB entry is also deleted (only applies to the case of dynamically
   created entries).

   An IPv6 incoming packet with source transport address (X',x) and
   destination transport address (Y',y) is processed as follows:

      The NAT64 searches for a UDP BIB entry that contains an BIB IPv6
      transport address that matches the IPv6 source transport address
      (X',x).  If such entry does not exists, a new entry is created.
      As BIB IPv6 transport address, the source IPv6 transport address
      of the packet (X',x) is included and the BIB IPv4 transport
      address is set to (T,t) which is allocated using the rules defined
      in Section 3.2.3.  The result is a BIB entry as follows: (X',x)
      <--> (T,t).

      The NAT64 searches for the session table entry corresponding to
      the incoming 5-tuple.  If no such entry is found, a new entry is
      created.  The information included in the session table is as
      follows:

         The STE source IPv6 transport address is set to (X',x) the
         source IPv6 transport addresses contained in the received IPv6
         packet,

         The STE destination IPv6 transport address is set to (Y',y) the
         destination IPv6 transport addresses contained in the received
         IPv6 packet,

         The STE source IPv4 transport address is extracted from the
         corresponding UDP BIB entry i.e. is set to (T,t),

         The STE destination IPv4 transport is set to (Z(Y'),y), y being
         the same port as the STE destination IPv6 transport address and
         Z(Y') being algorithmically generated from the IPv6 destination
         address (i.e.  Y') using the reverse algorithm as specified in
         Section 3.2.5 .

      The result is a Session table entry as follows: (X',x),(Y',y) <-->
      (T,t),(Z(Y'),y)

      The NAT64 sets or resets the timer in the session table entry to
      maximum session lifetime.  By default, the maximum session
      lifetime is 5 minutes, but for specific destination ports in the
      Well-Known port range (0..1023), the NAT64 MAY use a smaller
      maximum lifetime.

         Note: The reason why the lifetime for the sessions involving
         Well-Known ports can be shorter than the recommended default
         value is to allow greater reutilization of the pool of
         transport addresses of the NAT64 for bindings involving the
         Well-Known ports, since it is less likely that the application
         using these ports will use the NAT traversal techniques that
         rely on having a binding alive to enable incoming
         communications.

      The packet is translated and forwarded as described in the
      following sections.

   An IPv4 incoming packet, 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 an BIB IPv4
      transport address matches (Y,y) i.e. the IPv4 destination
      transport address in the incoming IPv4 packet.  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 applies Address-Dependent 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 STE source IPv4
      transport address equal to (X,x) (i.e. the destination IPv4
      transport address in the incoming packet) and STE destination IPv4
      address equal to Y (i.e. the source IPv4 address in the incoming
      packet).  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).

      In case the packet is not discarded in the previous processing,
      then the NAT64 searches for the session table entry corresponding
      containing the STE source IPv4 transport address equal to (X,x)
      and the STE destination IPv4 transport address equal to (Y,y).  If
      no such entry is found, a new entry is created.  In case a new UDP
      session table entry is created, it contains the following
      information:

         The STE source IPv6 transport address is extracted from the
         corresponding UDP BIB entry

         The STE destination IPv6 transport address is set to (Z'(Y),y),
         y being the same port y than the destination IPv4 transport
         address and Z'(Y) being the IPv6 representation of Y, generated
         using the algorithm described in Section 3.2.5

         The STE source IPv4 transport address is set to (X,x) the
         destination IPv4 transport addresses contained in the received
         IPv4 packet,,

         The STE destination IPv4 transport is set to (Y,y), the source
         IPv4 transport addresses contained in the received IPv4 packet.

      The NAT64 sets or resets the timer in the session table entry to
      maximum session lifetime.  By default, the maximum session
      lifetime is 5 minutes, but for specific destination ports in the
      Well-Known port range (0..1023), the NAT64 MAY use a smaller
      maximum lifetime.

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 4 Dec 2009 08:31:25 +0000

Hi Marcelo,

Just for the record, I am satisfied with the way you dealt with most
of the comments below.

Thanks
George

On Thu, Dec 3, 2009 at 6:30 PM, marcelo bagnulo braun
<[email-masked]> wrote:
> right, it supports both endpoint independent filtering and address dependent
> filtering for both TCP and UDP. I will state that up front in the feature
> description
>
>
> behaviour of the nat64, so that people can have an initial approach to the
> mechanism
>    of NAT64.    This is achieved by describing the NAT64 behavior involving
> a simple
>   network topology. The goal of this description is to provide the reader
> with
>   section to describe all possible configurations nor to provide a normative
>   specification of the NAT64 behavior. The normative specification of NAT64
> Right, several people in the list have previously commented that it would be
> useful to have some operational guidelines of how to handle more complex
> scenarios, including multiple nat64 boxes multiple dns64 and so on. My
> understanding is that we decided that it would be good to do that, but do it
> in a separated document.
>
>>   Packets generated
> It is clearly stated in several places that the NAT64 is a mechanism that is
> executed in a device.
>
> When we use the expression NAT64 device or NAT64 box is basically because we
> are describing an aspect of the behaviour that is related to a box, for
> instance, it is clearer (to me at least) to send packet to a box than to
> send packets to a function.
>
> So, while i agree wihth you that is a bit of an abuse of language, i think
> it is useful to refer to the NAT64 box (as a short for the box that is
> executing the NAT64 function)
>
> If there is any particular case where the usage of the expression is really
> bothering you, we can discuss the specific case, but i would rather use it
> in some cases.
>
>
>    Such binding state is either statically configured in the NAT64 or it is
>    flow are translated. The result is that, in the general case, NAT64 only
> supports
> the reccomendations about how to assign the prefix and what to do with it
> are contained in
> In addition, i have rewritten the section to account for the comments you
> make below
>
> the reuslt is:
>
>      packet in through an interface if the appropriate permission exists. A
>       as specified in this document, supports both Endpoint-Independent
> filtering
>       <t>If a NAT64 performs Endpoint-Independent filtering of incoming IPv4
> packets,
>           then an incoming IPv4 packet is dropped unless the NAT64 has state
> for the
>       unless the NAT64 has state involving the destination transport address
> of the IPv4 incoming packet
>       and the particular source IP address of the incoming IPv4 packet.</t>
>
>
> It would make sense to add a definition of endpoint independent filtering
> and address dependent filtering i guess.
>        <t hangText="Endpoint-Independent Filtering:"> The NAT64 filters out
>        any transport address for which it has state.        In other words,
> having state for a given transport address is sufficient
>        destined for a transport address that it has state for if the NAT64
> has not
> This implementation of the BIBs ensures Endpoint-Independent mappings in the
> NAT64.
>>
>>   TCP and UDP have
> mmm, i think this is how the mechanism work, didn't wanted to abuse on the
> usage of the normative language, i think it should be either a SHOULD or a
> MUST, but i am not convinced we need to use normative language for this
>
>>   Manually-configured BIB
> In any case, i have added text stating that endpoint indpeepndet filtering
> is implemented using the bibs.
>
> The resulting text is:
>
>      <t>A NAT64 has three Binding Information Bases (BIBs): one for TCP, one
> for
>        </list>where X' is some IPv6 address, T is an IPv4 address, and x and
> t
>      are ports. T will always be one of the IPv4 addresses assigned to the
> NAT64.
>      distinct. This implementation of the BIBs ensures Endpoint-Independent
> mappings in the NAT64.
>       (Address-Dependent filtering is implemented using the Session tables
> described below.)</t>
>
>
>>  BIBs implement
> Address dependent filtering, i ahve removed the ingress filtering cause is
> indeed misleading and stated that this is for address dependent filtering.
>
> mmm, i would preffer keep this both in the bib description and the session
> table description
>      <t>The NAT64 will receive packet through its interfaces. These packets
> can be either IPv6
>       packets or IPv4 packets and they may carry TCP traffic, UDP traffic or
> ICMP. The processing
>       of the packets will be described next. In the case that the processing
> is common to all the aforementioned
>       types of packets, we will refer to the packet as the incoming packet
> in general. In case that the processing
>       is specific to IPv6 packets, we will refer to the incoming IPv6 packet
> and similarly to the IPv4 packets.</t>
>
> but the only difficulty in handling fragments is that fragments other than
> the first one do not contain the port information so we need to do extra
> work to determine the incoming tuple, so i still think it is a reasonable
> match to describe it here, since it is most of the work.
>
>    IPv6 packet that contain a destination address that contains Pref64::/n.
>>
> explicitly define the fields of the BIB and make refgerecne to that. I have
> used thisnotation for the session table
>
> right, not sure it worth adding another conditional if here for this, though
> (i mean, the condition is trivially met)
>
>                       Well-Known ports can be shorter than the recommended
>                       default value is to allow greater reutilization of the
>                       pool of transport addresses of the NAT64 for bindings
>                       the application using these ports will use the NAT
> traversal
>                       techniques that rely on having a binding alive to
> enable incoming
>                       communications.</t>
>
>              applies Address-Dependent filters on its IPv4 interface, then
> the NAT64 checks to see if