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

[Dave Thaler <[e-mail]>]

Hi George,

I think the comments are very useful and would encourage you to
continue your review.

Thanks,
-Dave

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of George Tsirtsis
> Sent: Tuesday, November 24, 2009 11:06 AM
> To: [e-mail]
> Subject: [BEHAVE] Review Part 1 of draft-ietf-behave-v6v4-xlate-
> stateful-03
>
> 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.
> - 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.
>
> 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. In practice, however, it is not clear to what extend it does
> that. see below.
>
>    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
>
> 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. 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.
>
>    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.
>
> 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.
>
>
> 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"?
>
>    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.
>
>    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.
>
>
>    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"?
>
>    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.
>
> 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"
>
>    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"?
>
>    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.
>
>    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"?.
>
>    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
>
>    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.
>
>    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., 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.
>
>
>    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?
>
>  A session can be uniquely identified by either an
>    incoming tuple or an outgoing tuple.
>
> GT> what is "ingress" in this context?
>
>    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.
>
>    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.
>
>    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.
>
>
>    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.
>
>    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?
> 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.
>
>    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]?
>
> 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.
>
>    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.
>
>       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.
>
>       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?
>
>       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.
>
>       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.
>
>   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.
>
>      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.
>
> 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.
>
> 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"
>
>       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.
>
>       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.
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave