[BEHAVE] Review Part 1 of draft-ietf-behave-v6v4-xlate-stateful-03
George Tsirtsis <tsirtsis@googlemail.com> Tue, 24 November 2009 19:06 UTC
Return-Path: <tsirtsis@googlemail.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278B33A6907 for <behave@core3.amsl.com>; Tue, 24 Nov 2009 11:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.977
X-Spam-Level:
X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tobrZNd6X8Ed for <behave@core3.amsl.com>; Tue, 24 Nov 2009 11:06:10 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 719E43A6898 for <behave@ietf.org>; Tue, 24 Nov 2009 11:06:09 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id e12so1382573fga.13 for <behave@ietf.org>; Tue, 24 Nov 2009 11:06:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=wWp9Bq2sIeO8MWvYDKJ/PopL2KZnXLA1H9sVGqD4vfc=; b=sr4VIsK8LnsCjPUGIhmITyEhoKlPIplbYE5PyipnA4c8F78qz50cZh/uQfgMm00f98 mmmMTAtdZ1lRn/xqGTEirN4AHAb5zHYtuJ2myqd8tLMOLHCQiPDDWu6DTzd+celQY+7a 0HfH69Xudbbfp1RirIoVXsIFdFaaJaKgSLBV4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=t9dNrjO/j0XiejdoJVfVwAEMjL/P6ZsosG4sdA8HNYJKdOYi/8gCHHr0Dion1QT2Hv Ab08AlIxsK/1Ekdr3cV+en86NhROPKnmk+9rmCSL5vghFUDsNY4XexAXJ5vZAi6MmDsv 6tLbYK+G2buA1rpdc0R5JdHsTU/BH/tEcLJUk=
MIME-Version: 1.0
Received: by 10.239.145.15 with SMTP id q15mr737824hba.121.1259089561190; Tue, 24 Nov 2009 11:06:01 -0800 (PST)
Date: Tue, 24 Nov 2009 19:06:01 +0000
Message-ID: <d3886a520911241106o5a76b25axff048cd694ca61b0@mail.gmail.com>
From: George Tsirtsis <tsirtsis@googlemail.com>
To: behave@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: [BEHAVE] Review Part 1 of draft-ietf-behave-v6v4-xlate-stateful-03
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2009 19:06:14 -0000
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] Review Part 1 of draft-ietf-behave-v6v4-… George Tsirtsis
- Re: [BEHAVE] Review Part 1 of draft-ietf-behave-v… Dave Thaler
- Re: [BEHAVE] Review Part 1 of draft-ietf-behave-v… marcelo bagnulo braun
- Re: [BEHAVE] Review Part 1 of draft-ietf-behave-v… George Tsirtsis