Internet Draft Mohammad Awad NAT Working Group ENPPI Expires: October 13, 2005 April 11, 2005 More Fixed Identities for Private Hosts behind NAT IDNAT Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In many flavors of the nowadays address translators, real addresses are assigned to private hosts without preserving uniqueness; the same real address can be shared among multiple private hosts and the same private host can also obtain different addresses over the time as Mohammad Awad Expires: October 13, 2005 [page 1] INTERNET-DRAFT IDNAT April 11, 2005 well. As a result the addresses used for private hosts reflect some kind of ambiguity on those hosts. This proposal introduces the IDNAT model as a solution for that address ambiguity problem. This solution concentrates on defining another virtual identity to identify private hosts in replacement of the ambiguous assigned real IP address. Through agile practices this identity can be assigned to each of the private hosts, and the hosts themselves will be aware of their assigned Ids which are going to be quite unique throughout the private region as well as the entire Internet realm. Moreover, the new Id will play a centric role in the packets transmission so as to identify the private host outside the private region and hence defeating the undesired ambiguity. Mohammad Awad Expires: October 13, 2005 [page 2] INTERNET-DRAFT IDNAT April 11, 2005 Table of Contents 1. The Address Ambiguity Problem ................................4 2. Special Terms.................................................5 3. The IDNAT Model Overview......................................7 3.1. Limitations...............................................7 3.2. Identifying Private Hosts.................................8 3.3. Components of the Model...................................9 3.4. Supplementary Protocols..................................11 3.5. Traffic Flow.............................................12 4. Detailed Configurations and Settings.........................14 4.1. NHC IP Options...........................................14 4.2. The IDC Hosts Settings...................................15 4.2.1. Local Settings.......................................15 4.2.2. DNS Settings.........................................16 4.3. The IDC private host Settings............................16 4.3.1. Local Settings.......................................16 4.3.2. DNS Settings.........................................17 4.4. The IDNAT Box Settings...................................19 5. The Traffic Transmission in the IDNAT Model..................20 5.1. Outbound Traffic Trip....................................20 5.2. Inbound Traffic Trip.....................................21 6. The Supplementary Protocol Specifications....................23 6.1 The NPM Protocol..........................................23 6.1.1. The Service of the NPM Protocol......................23 6.1.2. NPM Messages.........................................23 6.1.3. NPM Message Encoding.................................24 6.1.4. The NPM Protocol Procedure...........................25 6.2. The RAC Protocol.........................................26 6.2.1. The Service of the RAC Protocol......................27 6.2.2. RAC Messages.........................................27 6.2.3. RAC Messages Format..................................29 6.2.4. The RAC Protocol Procedure...........................31 6.3. The Modified DNS Protocol................................32 6.3.1. The Behavior of the Modified DNS Operations..........33 7. Applications Behavior with the IDNAT Model...................34 7.1 Guidelines for IDC Applications...........................35 7.2 The IDC FTP Design........................................36 7.2.1. Modifying the Message Format to Support NHI..........36 7.2.2. Checking for IDNAT Compliance between Peers..........37 7.2.3. Modifying Internal Behavior of the FTP Application...38 8. Performance Considerations...................................38 9. IANA Considerations..........................................38 10. Security Considerations.....................................38 11. References..................................................38 11.1 Informative..............................................38 12. Author's Address............................................39 Mohammad Awad Expires: October 13, 2005 [page 3] INTERNET-DRAFT IDNAT April 11, 2005 1. The Address Ambiguity Problem Over a long period of time, there have been many contributions to ameliorate the performance of NAT and to get it fitting with as much applications as possible. NAT is showing now to be more application friendly than before. However, there are still some applications and Internet usages that can never cope with such middle boxes across the route. Network Address Translation as an operation is essential for NAT devices to perform. However Address Ambiguity is a resultant drawback of that operation. Address Ambiguity is defined for the purpose of this draft as the disability of the address to refer unambiguously to host. Real hosts have unambiguous addresses. The addressing scheme of IP version 4 guarantees that the single IP address refers to only a specific single host. But as known from the design characteristics of both types of the traditional NAT, private addresses in both do not use unambiguous addresses when using the Internet. With respect to basic NAT, the dynamic fashion NAT uses to bind the external pool addresses to private hosts, results in address ambiguity; that the same external address used by one private host in a specific time can be reused by another one later. Thus, along time, the single address is no longer referring to a specific host. Address Ambiguity shows also with the NAPT, but in different flavor. The common NAPT usually assigns only a fixed external address to a specific group of private hosts [4]. Any single host belonging to that group always uses that particular address when it uses the Internet. Although the resultant is that address assignment fashion is not dynamic, but sharing the same address between private hosts also produces Address Ambiguity. The single address is referring to a specific group of hosts not a specific single host. Both types of Traditional NAT result in Address Ambiguity and consequently in the undesired effects on Internet usage. According to the above demonstration, we can summarize the problem into concentrated statements; the translation process held inside the existing Traditional NATs results in Address Ambiguity, that private hosts loose one of most important identities for Internet usage, which are the unique devoted IP addresses. In the absence of such identity many Internet usages get in critical pitfalls while others can maneuver but possibly loosing some of their useful functionality. As we have defined the problem, now we are seeking the solution. According to that problem definition there are some requirements for such solution to be accepted. We are going to discuss those requirements in advance. 1- There should be some identity for each private host which is known by the host itself. 2- The identity must have the same stability measures of IP addresses. 3- This identity should be allowed to travel along with the outgoing packets initiated from the private host, in order to have other parties identify the sender. Mohammad Awad Expires: October 13, 2005 [page 4] INTERNET-DRAFT IDNAT April 11, 2005 4- The intervening NAT operations as well as any other possible middle box should not be effacing that identity; the design must guarantee that such identity always reaches the destination inside the traveling packets. 5- The other parties should be allowed to address the private host in terms of that identity. 6- The Network Address Translators should understand the entire design not to defeat it by unaware operations. 2. Special Terms Some of the hereunder terms have significant meaning only for the purpose of this document, that they might be referring differently elsewhere. A/TXT query Refers to the DNS query that request retrieval of both the A and TXT record types together for a specific domain name. ACD Address Composition/Decomposition Layer. This term refers to one of the modules that should exist in the Internet Host for it to become an IDcomp host ACDP Address Composition/Decomposition Layer for Private host. This term refers to one of the modules which should exist in the Internet Host for it to become an IDcomp private host Addressing Information Refers to the information via which host can be fully addressed through containing realm. One such instance is the IP address of the host. Another is the NHI Cascaded Private Network This term refers to the networks that have more than one NAT middle box between the hosts and the Internet. Conventional Translation Refers to the translation methods used in traditional NAT to translate packets either inbound or outbound. It includes the Basic NAT translation and the NAPT translation. DRE DNS Resolver Extension It is an additional module incorporated with the standard DNS resolver to have the resolver become an IDC one. Mohammad Awad Expires: October 13, 2005 [page 5] INTERNET-DRAFT IDNAT April 11, 2005 IDC Application Refers to the application which can use the functionalities of the IDNAT model. IDC resolver Refers to the DNS resolver module which is aware of the IDNAT model. This resolver is a software module that might be a part of an Internet host or either a DNS server. IDC Translation IDNAT compliant translation. Refers to the method the IDNAT box use in translating packets either outbound or inbound. IDNAT model Refers to the integrated solution; the Identifying Network Address Translation model IDCH The IDNAT compliant host. This term refers to Internet hosts which are basically compliant with the specification of [5], but in addition are aware of the IDNAT model IDCPH The IDNAT compliant private host. This term refers to the Internet hosts basically compliant with the specifications of [5]; they are also aware of the IDNAT model functionality and can work within a private network behind an IDNAT box. IDNAT box The middle box that perform the Network Address Translation process in compliance with the IDNAT model NHC (NHI Child) Refers to the second compartment of the NHI identifier NHI (NATed Host Identifier) Refers to the identifiers that fully identify private hosts in the IDNAT model. By definition the NHI is composed of two compartments; the NHP and NHC. NHP (NHI Parent) Refers to the first compartment of the NHI identifier NPM Refers to NHI to Private Address Mapping Protocol. This is a light weight protocol both the IDCPH and the IDNAT box can use to have the IDCPH acquire useful information about the location of the destination host before sending traffic Mohammad Awad Expires: October 13, 2005 [page 6] INTERNET-DRAFT IDNAT April 11, 2005 PTP Packet Translation Processor. Refers to one of the modules embedded inside the NAT box for it to become an IDNAT box. RAC Remote Address Classifier. Refers to one of the modules embedded inside the NAT box for it to become an IDNAT box. Single-box Private Network This term refers to the private networks that do not have more than one NAT middle box between the hosts and the Internet. No matter for a single-box Private Network to have more than one NAT in parallel. 3. The IDNAT Model Overview The IDNAT model is a proposed solution that fixes the address ambiguity problem. All the above requirements are almost realized in the model. This illustration is intended for verification, testing, and possible implementation and includes suggested algorithms suitable for operation. Specifically excluded is the detailed implementation tactics of the algorithms or operations; those are left out to implementation efforts. In particular, this section aims to provide an overview of the IDNAT model whereas the detailed design is going to be discussed in subsequent sections. However it is useful to explain in advance the terms that are going to be used frequently. Readers may need to refer to this section occasionally. 3.1. Limitations The design of the IDNAT model presented in this document is best fitting for the single-box private networks. Cascaded private networks cannot use the same design as it is. More development will be needed before they can use it. The skeleton of the design has been made flexible to allow such developments. So the term Private Network in the following presentation will be referring to the single-box private network if not otherwise mentioned. Mohammad Awad Expires: October 13, 2005 [page 7] INTERNET-DRAFT IDNAT April 11, 2005 3.2. Identifying Private Hosts The cornerstone of the IDNAT model is the Private Host identification. In order to fulfill the requirements above, the following scheme is the heart of the model. Also it is still compatible with the scheme proposed in [9]. Private hosts will be assigned unique identifiers referred to as the NATED Host Identifier (NHI). It is unique within the entire Internet realm, which means it is not allowed to have more than two private hosts (even inside different private networks) with the same NHI. This is realized in the IDNAT model by dividing the NHI into two compartments; one such is guaranteed unique in the scope of the Internet realm and the other is guaranteed unique in the scope of the same private network. Those are NHP and NHC sub-identifiers respectively. The uniqueness within the Internet is realized by having NHP refer to one of the external IP addresses assigned to the NAT. Also by having the other identifier, NHC refer to the private IP address of the host, we can guarantee it is always unique in the private network scope. A single central entity is required to keep a store of all the NHP and NHC inside the private network. Thus, the IDNAT box itself assumes that responsibility. Whenever a new private host joins the private network, the IDNAT box assigns it the appropriate NHP and the appropriate NHC, store that information and pass it back to the host to keep. The appropriate NHP assigned by the IDNAT box can be any of the external IP addresses assigned for that box. But later on, this one must always be used for translating packets belonging to that particular host; there must be a sort of temporary binding between the private IP address and the one assigned to NHP. This is the scheme of identifying the private host. The following demonstration will show how that scheme can be activated in order to include the NHI inside the traveling traffic. Mohammad Awad Expires: October 13, 2005 [page 8] INTERNET-DRAFT IDNAT April 11, 2005 +--------------------------------------------------------------------+ | | | | | | | PRIVATE HOST 1 +----------------------+ | | +------------------------+ | | | | | IP 10.2.2.30 | | | | | | | | | | | | | | | | | | | | | | | | NHP 60.3.3.1 | | | | | | NHC 10.2.2.30 | | NAT GATEWAY | | | +------------------------+ | | | | | | | | | | | | | | | | | | | | PRIVATE HOST 2 | | | | | | | | +------------------------+ | | | | | IP 10.2.2.30 | | | | | | | | | | | | | | | | | | | | | | | | NHP 60.3.3.1 | | | | | | NHC 10.2.2.30 | | | | | +------------------------+ | | | | +----------------------+ | | | | | | | +--------------------------------------------------------------------+ Figure 1: Private Hosts Identities 3.3. Components of the Model In order to have an IDNAT model working as specified here, a new flavor of the NAT box is to be implemented. This is what we will refer to as the IDNAT box. Its main function is similar to that in [9]. Also both of the hosts and the private hosts must be upgraded with particular configuration as per the specifications. In the following we will be referring to those upgraded hosts as IDcomp host and IDcomp private host. Mohammad Awad Expires: October 13, 2005 [page 9] INTERNET-DRAFT IDNAT April 11, 2005 Every IDcomp host should be configured as per the IDCH Configuration Set, and so should the IDcomp private host as per the IDCHP Configuration Set. In addition, the IDcomp host should be equipped with the ACD module, which is responsible for interacting with the IP module [5] in both cases of sending and receiving traffic. With respect to the IDcomp private host, a module referred to as ACDP assumes similar responsibilities. +----------------------------------------------------------------------+ | | | /-------\ | | | | | | /-----------------------------> DNS <----------------------------\ | | | MODIFIED DNS MESSAGES |SERVER | MODIFIED DNS MESSAGES | | | | | <---\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | \-------/ | | | | | |RAC | | | | | | | | | | | | | | | | | | | | | | | | /------------------\ /-------\ | /------------------\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RAC | | | | | | | | | +------++------+ | | <---| | +------++------+ | | | | | | | DNS || IP | | | | | | | IP || DNS | | | | | | | | RES || | | | | | | | || RES | | | | | | | | || | | |-------| | | | || | | | | | | | |------||------| | NPM | | | | |------||------| | | | | | | | || <----------> PTP | | | | || | | | | | \----->DRE || ACDP | | | | \-----> ACD || DRE <-----/ | | | | || | | | | | | || | | | | | +------++------+ | | | | +------++------+ | | | | | | | | | | | \------------------/ \-------/ \------------------/ | | IDC PRIVATE HOST IDNAT IDC HOST | | | +----------------------------------------------------------------------+ Figure 2: The IDNAT Model Mohammad Awad Expires: October 13, 2005 [page 10] INTERNET-DRAFT IDNAT April 11, 2005 The IDNAT box is a box able to operate traditionally, i.e. translate packets as per either the Traditional Basic NAT or the Traditional NAPT specifications [3], but in addition, should be equipped with new functionality and have additional special configurations. Particularly, two modules should be included in the IDNAT box; the PTP and the RAC, and it should be configured as per the IDNAT Configuration Set, described later. Both of the IDcomp hosts or the IDcomp private hosts should have DNS resolver modules included. That resolver module should be in compliance with [1], and additionally equipped with the DRE module in integration. Principally, the reason IDNAT model is invented is to provide the benefits of identification for the private hosts through communication. But only when all of the items in the communication paradigm are IDC items (hosts, the NAT box and the involved applications), this benefits can be realized. We refer to that mode as the IDNAT Advantageous Mode. Although, the IDNAT model is designed with caution not to result in communication failure in opposite cases. The passage of traffic is always guaranteed even if some of the involved items are not IDC. In such cases the benefits are not realized. This mode is referred to as IDNAT Workless Mode. 3.4. Supplementary Protocols For the IDNAT model to achieve its function, two supplementary protocols are sometimes necessary to run; the NPM protocol and the RAC protocol. The NPM protocol runs under the control of the ACDP module of the IDC private host where messages are exchanged with the PTP module at the IDNAT. It's aimed at providing the IDC private host with necessary information before it can send traffic to another private host. On the other hand, in the RAC protocol, messages are exchanged between the RAC module at the IDNAT box and Internet hosts and between the RAC module and the DNS as well. This protocol may be run as outbound traffics are being translated in the IDNAT box and it is aimed at disclosing whether the destination of the traffic is IDC or not. Moreover, the DRE modules bundled into within the DNS resolvers of both of IDC hosts and IDC private hosts are able to influence the normal behavior of the DNS, and this influenced behavior is referred to as Modified DNS Protocol. Mohammad Awad Expires: October 13, 2005 [page 11] INTERNET-DRAFT IDNAT April 11, 2005 3.5. Traffic Flow +-----------------------------------------------------------------+ | | | | | | | /------------\ /------------\ /------------\ | | | | | |Translated | | | | | | | Outboud | | | | | | Outbound | IDNAT BOX | Packet | | | | | PH -------------> -------------> H | | | | | Packet | | | | | | | | | | | | | | | | | | | | | | \------------/ \------------/ \------------/ | | | | | | | | | | /------------\ /------------\ /------------\ | | | |Translated| | | | | | | | Inbound | | Inboud | | | | | | Packet | IDNAT BOX | Packet | | | | | PH <-------------- <------------- H | | | | | | | | | | | | | | | | | | | | | | | | | | | \------------/ \------------/ \------------/ | | | | | | | +-----------------------------------------------------------------+ Figure 3: Traffic Transmission Assuming that the network in Figure 3 is one that can operate in the IDNAT Advantageous Mode, let us walk through an overview how the IDNAT model works. Mohammad Awad Expires: October 13, 2005 [page 12] INTERNET-DRAFT IDNAT April 11, 2005 Considering that H needs to send a generic traffic to PH, it firstly starts with a DNS request to inquire about the addressing information of PH of which it had already known the domain name. The normal DNS resolver issues an "A" query for that purpose. However the coexisting DRE module can modify the request in order to get additional information from the DNS server which can help to determine whether the target is an IDcomp private host as well as -in such a case- acquire the NHI identifier instead. Since PH is configured exactly as per the IDCPH Configuration Set, such information is available in the DNS authoritative zone. Hence, H will acquire the NHI of PH without any required awareness from the DNS server. The DRE can integrate with the normal DNS resolver in order to get the NHI, thus the user application can use it. Whenever H is ready to send the traffic, the ACD module can handle the NHI identifier which characterizes the destination address, divide it to the two compartments, NHP and NHC. The former is set into the destination address of the packets and the latter is passed along inside the IP header in a particular IP option. We refer to this action of the ACD, as initiating traffic in the IDNAT Advantageous Mode. At the IDNAT box, the PTP module can use only the passed NHC to distinguish which private host is intended with the traffic. Oppositely, if PH and NAT were not IDC nodes, then the received DNS response will not provide an NHI identifier. At maximum will provide the IP address of the NAT if such technique is used. In that case, the rest of the operations handled in H will force the IDNAT Workless Mode. Particularly the ACD module will not function and the traditional processing will take place. For the second case, when PH is trying to communicate with H. The DNS resolver in integration with the DRE module will handle the starting DNS request intended to inquire about the addressing information of H. But in this case, the result will be the normal IP address of H. The user application then can initiate the traffic which passes normally towards the IDNAT boundaries. There, the RAC module inside the IDNAT box can do a simple check to determine whether the traffic destination is an IDC host or not. In case it is, the RAC instructs the PTP to force the IDNAT Advantageous Mode. Particularly the IDNAT box will carry out an IDC translation process resulting in the translation of the source address of the packets into the NHP of PH and the insertion of the NHC inside a particular IP options within the packets. However if H was not an IDC host then RAC would sense and force the IDNAT Workless Mode whereby the PTP module translates the packet quite traditionally. For other cases, PH may intend to communicate with some other private host. This is disclosed when the starting DNS request results in the receiving of an NHI. Then the ACDP layer should intervene just before the traffic is sent out, in order to check whether this private host is inside the same private network. In such a case, the communication should be handled using the private addresses. But otherwise, the ACDP module will be behaving similar to the ACD in previous example. Mohammad Awad Expires: October 13, 2005 [page 13] INTERNET-DRAFT IDNAT April 11, 2005 4. Detailed Configurations and Settings This section provides -in details- the required configurations of the IDC nodes and operations of each module. 4.1. NHC IP Options Two IP options are invented for the purpose of carrying the NHC identifier between end nodes. Their structures are in compliance with the specifications of [5]. srcNHC and dstNHC are their names. Both of them have the NHC_struct data structure, but with slightly different values as per the following table. Option SrcNHC DstNHC Type 161 162 Length 6 6 Data Value of NHC Value of NHC In details, the designated values 161 and 162 mean the following: 1- The "copied flag" is set in both options. So they both should be copied during the fragmentation process. 2- Both options belong to class #1, which is reserved for future use by the specification of [5]. 3- The two options are distinguished by the option number; srcNHC has number 1 and dstNHC has number 2. Mohammad Awad Expires: October 13, 2005 [page 14] INTERNET-DRAFT IDNAT April 11, 2005 4.2. The IDC Hosts Settings +-------------------------------------------------------------+ | | | | | +----+----+----+----+ +----+----+----+----+ | | | | | | | | | | | | | | | | | | | | | | | | | | +----+----+----+----+ +----+----+----+----+ | | | | NHP_STRUCT NHC_STRUCT | | | | | | | | +----+----+----+----+----+----+----+----+ | | | | | | | | | | | | | | | | | | | | | | | | +----+----+----+----+----+----+----+----+ | | | | | | NHI_STRUCT | | | | | | | | | | | | | | +-+----+----+----+----+----+----+----+----+ | | | | | | | | | | | | | | | | | | | | | | | | | | +-+----+----+----+----+----+----+----+----+ | | | | FLAG IP_STRUCT | | | +-------------------------------------------------------------+ Figure 4: Data Structures 4.2.1. Local Settings One of the principle settings required in the IDC hosts is to allow the IP_struct described above to replace the normal IP structure. The Normal IP structure has multiple control fields besides four fixed octets that carry the value of the IP address. However the IP_struct of these specifications can carry either of two alternatives; the normal IP address or the NHI addressing information characterized by the NHI_struct. The NHI_struct is composed of two successive structures; NHP_struct and NHC_struct. They carry the values of NHP and NHC respectively. At the very left end of the IP_struct, there is a flag to determine whether the variable contains NHI_struct or a normal IP. Mohammad Awad Expires: October 13, 2005 [page 15] INTERNET-DRAFT IDNAT April 11, 2005 So, while the IDC host allow for the IP_struct, it can populate related variables with just IP values or NHI values. 4.2.2. DNS Settings The IDC host should have an additional special resource record in the DNS reverse domain IN-ADDR.ARPA. The name of this resource record is IDTXT record. It is a normal TXT record in full compliance with [2]. However, the part of RDATA contains a single string; IDC. Figure 5 illustrates the record. The function of this record is to show other entities that the host is an IDC host. +----------------------------------------------------------------+ | | | | | | | DOMAIN NAME CLASS TYPE RDATE | | +------------------+-----+-----+------------------+ | | | Domain name of | | | | | | | the private host| IN | TXT | IDC | | | | | | | | | | +------------------+-----+-----+------------------+ | | | | | | | +----------------------------------------------------------------+ Figure 5: The IDTXT DNS Resource Record 4.3. The IDC private host Settings 4.3.1. Local Settings The following variable are used in the settings of the IDC private hosts 1- The same setting of section 3.1.2 is also required with IDC private hosts 2- Special local variables should be configured with specific values inside the IDC private host. Those variables are as follows. Variable Data structure Value NHP NHP_struct The NHP as determined by the IDNAT box NHC NHC_struct The NHC as determined by the IDNAT box NHI IP_struct The NHI value IP IP_struct The original private IP NPM_server IP_struct The private address of the IDNAT box Mohammad Awad Expires: October 13, 2005 [page 16] INTERNET-DRAFT IDNAT April 11, 2005 3- Special additional system call called GET_SRCNHI should be made available in both the application/transport and the transport/IP interfaces. The following comparison defines the difference and usage of each of the new GET_SRCNHI and the traditional GET_SRCADDR. GET_SRCADDR: The Transport Layer on behalf of the Application layer issues that system call. The IP layer is the one required to reply. The system call takes two arguments the remote IP address and the type of service. The IP layer responds with the stored IP value. GET_SRCNHI: The Transport Layer on behalf of the Application layer issues that system call. The IP layer is the one required to reply. The system call takes two arguments the remote IP address and the type of service. The IP layer responds with the stored NHI value. 4.3.2. DNS Settings With respect to the DNS, special resource records belonging to the IDC private hosts should be stored. These records coexist with the rest of other records that might have been stored for private hosts. These new set of records are as follows: 1- One additional TXT record in the forward domain, referred to as NHITXT. The NHITXT record is a TXT resource record in full compliance with [2] but with an RDATA field of special meaning for the IDNAT model. Figure 6 shows the description. +----------------------------------------------------------------+ | | | | | | | DOMAIN NAME CLASS TYPE RDATE | | +------------------+-----+-----+------------------+ | | | Domain name of | | | | | | | the private host| IN | TXT | Value of the NHI | | | | | | | | | | +------------------+-----+-----+------------------+ | | | | | +----------------------------------------------------------------+ Figure 6: The NHITXT DNS Resource Record 2- As much additional records as necessary of different types of resource records in the reverse domain, IN-ADDR.ARPA. Mohammad Awad Expires: October 13, 2005 [page 17] INTERNET-DRAFT IDNAT April 11, 2005 In the reverse domain IN-ADDR.ARPA, domain names sometimes have specific records for specific purposes. For example, the PTR record in the IN-ADDR.ARPA is used to provide replies of the opposite requests, where resolvers are given the IP address and wish to know the corresponding domain name. Another example is the CERT record which can exist in the IN-ADDR.ARPA providing the IP-based digital certificates for particular IP addresses [6]. The special IDCPH settings impose that for every purpose there should be two records of the same type but with slightly different domain names. Figure 7 shows the required two records for the purpose of reverse queries. As shown, the difference is the domain name. One record includes the common domain name used in IN-ADDR.ARPA domains, while the other contains an IDNAT specific domain name notation. This notation follows the same logic of reversing the octets comprising the addressing information and attaching the resultant to the IN-ADDR.ARPA label. But with the NHI addressing information, the resultant no. of labels are eight even before attaching to IN-ADDR.ARPA. Although this is much longer than any other domain names in the reverse domains, but it still does not conflict with the standard regulations of domain names lengths as specified by [1]. +----------------------------------------------------------------+ | | | DOMAIN NAME CLASS TYPE RDATA | | +------------------+-----+-----+------------------+ | | | Reversed(IP).IN- | | | | | | | ADDR.ARPA | IN | PTR | Domain Name | | | | | | | | | | +------------------+-----+-----+------------------+ | | | | | | | | DOMAIN NAME CLASS TYPE RDATA | | +------------------+-----+-----+------------------+ | | | Reversed(NHI).IN-| | | | | | | ADDR.ARPA | IN | PTR | Domain Name | | | | | | | | | | +------------------+-----+-----+------------------+ | | | | | +----------------------------------------------------------------+ Figure 7: PTR DNS Resource Records for Private Hosts Mohammad Awad Expires: October 13, 2005 [page 18] INTERNET-DRAFT IDNAT April 11, 2005 4.4. The IDNAT Box Settings The IDNAT box can be any traditional NAT box -either Basic or NAPT, but with few additional settings. Before these settings could be explained, here are the data structures on which the settings are based. NHI_Table: Contains a number of tupples as much as the active concurrent sessions. In each tupple there are fields for the source address (4 octets), the source port (16 bits), mapped address (4 octets) and the mapped port (16 bits) RAC_Table: Contains a variable number of tupples. Each one contains two fields; the Destination Address and Type. The former can include an IP address value and the other can include one character either I or C. State_Table: Contains a number of tupples as much as the active concurrent sessions. In each tupple there are fields for the source address (4 octets), the source port (16 bits), mapped address (4 octets) and the mapped port (16 bits) With these three types of tables in mind, here below are the settings with which the IDNAT box should be configured. 1- The IDNAT box should be configured with the NHI_table described above. The purpose of this table is to store information about the private hosts. For each private host, the IDNAT keeps one record containing the private IP address and the assigned values of NHP and NHC. In case of dynamically changing private IP addresses, such as networks using DHCP, this information should be updated each time to reflect the change in the IP address values. 2- The IDNAT box should also be configured with the RAC_table, described above. The purpose is to store the type of real hosts; whether they are IDC hosts. The IDNAT box depends on this information in order to translate outbound packets. It should be allowed to fill in this table automatically by the RAC module as will be explained later. Implementations also are encouraged to allow another manual filling method, such as providing a special administrative tool for that purpose. The size of the RAC_table is dependant on the number of real hosts going to join into communication with the private hosts. So the size should be allowed to increase dynamically to a fairly large threshold. Mohammad Awad Expires: October 13, 2005 [page 19] INTERNET-DRAFT IDNAT April 11, 2005 Note The tactics used to assign NHP and NHC values for private hosts, fill in the NHI table and to pass them to private hosts are considered implementation specific, though they are explicitly left out throughout this document. 5. The Traffic Transmission in the IDNAT Model One of the main objectives of the IDNAT model is to involve the NHI of private hosts in the traffic transmission process so that the private hosts could be identified by their traffic. The following will illustrate how that objective is achieved. As shown in Figure 8, the two appearing hosts are IDC ones; PH is a private host and H is a real one. They are exchanging traffic with each other. Just for the time being, it is assumed that each of them knows the addressing information of the other party. PH knows the IP address of H and H knows the NHI of the private host PH and it knows that it has to address that private host via this type of addressing information. The subject of how H could acquire such addressing information about PH is going to be addressed in following sections, but this section is meant by spotting the light merely on the transmission round trip between the two hosts. The round trip of traffic includes the case of the traffic initiated at PH and transmitted along the way towards H and on the other hand the other traffic initiated at H and received at PH as well. We refer to the first case as the outbound traffic and to the second as the inbound traffic. Both of the two cases are going to be studied in separate with concentration on the new aspects related to the sending/receiving processes at hosts as well as the role of the intervening IDNAT box in the forward and the backward translation. 5.1. Outbound Traffic Trip +-----------------------------------------------------------------+ | | | /------------\ /------------\ /------------\ | | | | | |Translated | | | | | | | Outboud | | | | | | Outbound | IDNAT BOX | Packet | | | | | PH -------------> -------------> H | | | | | Packet | | | | | | | | | | | | | | | | | | | | | | \------------/ \------------/ \------------/ | | | +-----------------------------------------------------------------+ Figure 8: Outbound Translation Mohammad Awad Expires: October 13, 2005 [page 20] INTERNET-DRAFT IDNAT April 11, 2005 The first station is at PH where the traffic is being first composed as payload, assigned the headers and then transmitted outwards. Just in the process of assigning the headers. This part of the process however does not vary from the normal behavior of the conventional private hosts. Next, the traffic arrives at the IDNAT box in order to be translated into appropriate addresses fitting for the Internet. But, the process of translating such outbound traffic is slightly different from what the conventional NAT boxes behave in these cases. The module responsible for achieving the process inside the IDNAT box is basically the PTP module. The PTP module is meant by first observing the source address appearing within the arriving packet, then locating the corresponding values of NHP and NHC in the NHI_table. During the translation process the NHP value will be used to replace the source address of the packet while the NHC will be used to compose on IP option of the type srcNHC. Following, the packet is attached the srcNHC within the IP options field of the IP header and the packet is translated by the same tactic used in the conventional model. Then it is forwarded outwards and routed normally until reaching the destination. At H, the packet is firstly received, it then undergoes the initial necessary checksum verifications like the one done over the IP header and the transport header, and then the ACD module at H takes the control to do one important task over the packet which is combining the two parts of NHP and NHC existing within the IP header to compose the NHI address of the sender. Next, the ACD also has to change the source address appearing in the IP header from the NHP to the combined NHI value. All that work done by the ACD is done before any further processing of the packet can take place. Therefore, the following possible processing phases over the packet could see that the source address of the packet is just the NHI value. Recalling what has been stated before, that all the IDC hosts can deal with addresses in the NHI form, and then healthy processing could be expected after the ACD module completes its task and pass the control to next phases. 5.2. Inbound Traffic Trip The inbound traffic trip means traffic is initiated at H and transmitted to PH passing by the IDNAT box to perform the necessary inbound translation. Mohammad Awad Expires: October 13, 2005 [page 21] INTERNET-DRAFT IDNAT April 11, 2005 +-----------------------------------------------------------------+ | | | | | | | /------------\ /------------\ /------------\ | | | |Translated| | | | | | | | Inbound | | Inboud | | | | | | Packet | IDNAT BOX | Packet | | | | | PH <-------------- <------------- H | | | | | | | | | | | | | | | | | | | | | | | | | | | \------------/ \------------/ \------------/ | | | | | | | +-----------------------------------------------------------------+ Figure 9: Inbound Translation There inside H and as assumed in the starting of this section, the NHI address of PH is present at the sending application and is ready to be used in the sending operation. As usual, the operation starts by composing the payload and then preparing and attaching the headers. But the ACD module is responsible of conditioning the NHI value until it is inserted appropriately into the IP header. It decomposes the NHI into the comprising NHP and NHC values. It uses the NHC to form the dstNHC option and then inserts it inside the IP options field of the IP header of the ongoing packet. But NHP value is inserted as is in the destination address field. By this stage, the packet is ready to be forwarded out along the route. The IDNAT box then picks the packet since its destination address actually characterizes one of the addresses assigned to this IDNAT box. Inside the IDNAT box, the inbound translation process takes place. At this stage, the PTP module firstly needs to determine which among the private hosts is the one actually intended to receive this packet. Therefore, the values of NHP and NHC will be used in that determination. They are picked out of the IP header, the PTP looks up the corresponding record in the NHI_Table and hence the Private IP address could be determined. Following, the actual translation process starts. The PTP module replaces the NHP existing in the packets IP header by the private IP address out of the previous lookup and the packet can then be forwarded along on the private interface, thus it could reach the intended destination. At PH the packet is received just normally and that is all. Mohammad Awad Expires: October 13, 2005 [page 22] INTERNET-DRAFT IDNAT April 11, 2005 6. The Supplementary Protocol Specifications 6.1 The NPM Protocol As IDC private hosts get identified and further announced in terms of their NHI addressing information, this fact implies a single conflict that should have to be resolved. The NHI addressing information via which a particular IDC private host is addressable may arrive by any of the available means at some another private host in the same region and this second one may be attempting to use it to send some traffic to it. This situation if otherwise has not been corrected can lead to that the traffic gets out the private region, be translated once outbound and another time inbound, and then returned back again to the receiver private host. Since this includes useless double translation, therefore this situation should be handled; hence the NPM protocol is dedicated for achieving that goal. The NPM protocol exploits the fact that each of the NHI identifiers of private hosts of the same region along with their corresponding private IP values are stored there in the NHI table at the IDNAT box. Therefore, if the initiator IDC private host is permitted to perform a simple query in the NHI table, then the affiliation of the mysterious NHI address could soon be determined. 6.1.1. The Service of the NPM Protocol In the NPM protocol, messages are exchanged between the ADCP module in the IDC private host and the PTP module in the IDNAT box. The time when this exchange can take place is while outgoing traffic if the traffic is under processing to be sent to another private host via its NHI address whereas this target private host is still unknown whether it belongs to the same private network as the sender. The protocol is aimed at providing the sender private host with the private IP address of the destination in case the NHI in question was actually an insider one, or instead instructing the sender to go on using the NHI in hands otherwise. 6.1.2. NPM Messages Generally, two types of messages are there in the NPM protocol; requests and replies. Requests are those sent by the IDC host to the IDNAT box containing the NHI in question. But replies are what are sent in response from the IDNAT box back to the requestor. In itself, the reply can be either a positive reply in the case that the NHI actually corresponds to an insider private host, or a negative reply otherwise. Mohammad Awad Expires: October 13, 2005 [page 23] INTERNET-DRAFT IDNAT April 11, 2005 The NPM request message always contains one argument; this is the NHI of interest. The Positive reply contains two arguments; one being the requested NHI and the other being the corresponding private IP. On the other hand, the negative reply contains only the single NHI argument since there is no corresponding private IP for. To summarize, the set of message types in the NPM protocol along with their meaning and accompanied arguments are listed below. NPM Request: NPMQ(NHI) An NPM message sent from the IDC private host to the associated IDNAT box inquiring about a single NHI addressing information whether it is insider or not. This message takes only a single argument; the NHI of interest. NPM Positive Reply: NPMP(NHI,PIP) An NPM message returned back from the IDNAT box to the NPM requestor indicating that the NHI of interest is actually an insider one and further including the corresponding private IP address. Two arguments; the NHI and the corresponding private IP NPM Negative Reply: NPMN(NHI) An NPM message returned back from the IDNAT box to the NPM requestor, indicating that the NHI of interest is never an insider one. This message takes only a single argument; the NHI of interest. 6.1.3. NPM Message Encoding Regarding the encoding of messages, a single structure is defined with a set of parameters and indicators such that all types of NPM messages can fit within. As shown in Figure 10 and the listing thereafter, five separate fields compose the structure. According to the type of the occupying messages some can be filled and others can be empty. The main two fields are the NHI and the PIP. The Type field is for defining the message type. The ID is for correlating requests and responses such that this value should be the same in the request and the response messages belonging to the same transaction. Finally the Error field is preserved for the purpose of possible future development. Mohammad Awad Expires: October 13, 2005 [page 24] INTERNET-DRAFT IDNAT April 11, 2005 +----------------------------------------------------------------+ | | | --> <-- --> <-- | | 2 bits 1 Octet | | | | --+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | ||| | | | | | | | | | | | | | | | --+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | <---4 Octets---><---4 Octets---><---4 Octets----> | | | | Type ID NHI PIP Error | | | +----------------------------------------------------------------+ Figure 10: NPM Message Encoding For further illustration, the fields, their lengths and the purpose aimed by each are summarized in the following listing. Type (2 bits): Determines the type of the occupying message: 00: NPMQ 01: Unused 10: NPMP 11: NPMN ID (4 octets): Correlating requests and replies belonging to the same transaction. NHI (4 octets): Containing the NHI of interest. PIP (4 octets): Contain the Private IP matched. Error (1 octet): Reserved for future use. 6.1.4. The NPM Protocol Procedure The protocol is initiated inside the IDC private host. At first, the ACDP module sends an NPMQ along with the NHI under investigation to the IDNAT box. Next, the IDNAT box should respond looking up this NHI value in the NHI_table in order to determine whether or not it belongs to one of the private hosts in the same private network. If the NHI value could be found in the NHI_table, then that means it belongs to an insider private host. Mohammad Awad Expires: October 13, 2005 [page 25] INTERNET-DRAFT IDNAT April 11, 2005 In this case the PTP module would respond with the NPMR(NHI,PIP) message where the PIP is the value of the private IP address found corresponding to the given NHI. Otherwise, if the NHI value could not be located in the NHI_table, then it is known that it belongs to an outsider private host. In this case the PTP module would not respond by the NPMR, but instead with the NPMN(NHI) message. 6.2. The RAC Protocol Once the IDNAT model is implemented on the ground, it's not even accepted to have IDC host merely communicate with other IDC ones and be isolated from the non-IDC hosts. The model however, is designed with caution so that all IDC nodes -IDNAT boxes, IDC hosts or IDC private hosts- shall not fall into this situation. Since the IDC hosts are originally in full compliance with the Internet host specifications, they already encounter no problem to understand the received traffic initiated by any traditional host. In the same way, as they tend to send traffic, the traditional standard process undergoes unless the destination of the traffic is known to have an NHI address -i.e. known to be an IDC private host. However, there is one challenge confronting the IDNAT model in this context; that being the outbound translation process performed in the IDNAT box. In spite of that the IDNAT box is already capable of performing the both types of translation; the traditional and the IDC, but it still lacks the means by which it could decide whichever should be chosen. The reason is that the type of the destination - IDC or not- of the traffic is not spontaneously determined while the IDNAT box is processing the outbound translation. Indeed, the RAC protocol addresses this missing link. +------------------------------------------------------+ | | | +-----------+ +-----------+ | | | | | | | | | IDC | | IDNAT | | | | PRIVATE | | | | | | HOST | | | | | | |---- NPMQ(NHI) --->| | | | | | | | | | | |<--- NPMN(NHI) ----| | | | | | | | | | | |<-- NPMR(NHI,PIP) --| | | | | | | | | | +-----------+ +-----------+ | | | +------------------------------------------------------+ Figure 11: The NPM Protocol Procedure Mohammad Awad Expires: October 13, 2005 [page 26] INTERNET-DRAFT IDNAT April 11, 2005 6.2.1. The Service of the RAC Protocol In the RAC protocol, messages are exchanged between the RAC module at the IDNAT box and the destination host, and possibly between the RAC module and the DNS. The time when this protocol may run is actually when some outbound traffic is under translation in case that it is still unknown whether the destination is and IDC or not. It is aimed at providing the IDNAT RAC module with this missing information. 6.2.2. RAC Messages In total, the RAC protocol supports the following types of signals: 1- Communication messages. 2- Internal messages. 3- Timeout signals. RAC protocol includes two types of round trip transactions; one being the RAC ICMP Transaction and another being the RAC DNS Transaction. Further, each transaction supports a query and a response. Thus a total of four message types are there in the RAC protocol. The request of the RAC ICMP Transaction is referred to as RIQ and its response is referred to as RIR. On the other hand the request and the response of the RAC DNS Transaction are the RDQ and the RDR respectively. At the detailed level of messages composition, there are a number of arguments in each of those four messages, but with regard to the functionality of the RAC protocol, no special argument are there in the RIQ or in the RIR; just in the other couple there are some arguments of interest. The RDQ take one such argument that is the destination address of interest. But the RDR takes two; those being that destination address and the set of the TXT resource records it may have existing in the DNS. Besides the above communication messages, there are also three internal signals; RAC Begin, RAC End and RAC Help. Those internal messages coordinate the processing between the RAC module and the PTP module inside the IDNAT box. Lastly, the RAC protocol is also controlled by the use of two different time-out signals; TOI and TOD. To summarize, descriptions of the supported arguments as well as the notation of each of the above-mentioned type of signals are included in the listing hereunder. RAC ICMP Request: RIQ(DA) An ICMP query sent by the RAC module in the IDNAT box to the destination under investigation; this query is crafted such that upon the receiving of its response the class of the destination could be determined. This message can take only one argument; this is the destination under investigation, the one this ICMP request is actually sent to. Mohammad Awad Expires: October 13, 2005 [page 27] INTERNET-DRAFT IDNAT April 11, 2005 RAC ICMP Response: RIR(DA,dstNHC) An ICMP echo sent by the destination under investigation to the RAC module in response to the RIQ message. The receiving of this message can guide the RAC module to clearly determine the class of the sender This message can take from one to two arguments; the first is the destination under investigation which is the source address this ICMP reply is actually received from. The second is dstNHC option which the responder has included in the response. In cases when the responded does not include one, then the argument list will appear to be free from the second argument. RAC DNS Request: RDQ(DA) A reverse DNS query sent by the RAC module inquiring about TXT RRs the destination under investigation might have existing in the IN- ADDR.ARPA domain This message can take only one argument; the destination address under investigation RAC DNS Response: RDR(DA,IA) The normal DNS reply sent by the authoritative DNS server in response to the RDR message. This message can take from one to two arguments; the first is for the destination address under investigation and the second is the IDTXT record contained insider the RRset, if any exists. When the RDR contains no such IDTXT record then the second argument will be omitted from the argument list. RAC Begin: RB(DA) The internal message sent by the PTP module to the RAC module in the IDNAT box to direct the latter to start classifying a particular address. Only one argument can be taken; the destination address the PTP would need to classify RAC End: RE(DA,TYPE) The internal message sent by the RAC module back to the PTP to inform the latter that the address under investigation has already been classified. The message can take two arguments; the first is the address under investigation and the second one is the disclosed type - either IDC or not. RAC Help: RH(DA,TYPE) The internal message sent in particular times by the PTP module to the RAC module including information that would help the latter in its investigations for destination addresses. This message can take two arguments; the first is a particular destination address and the second is its type as known by the PTP TOI A particular timeout signal that fires at specific times within the RAC module to indicate a particular course of actions should be taken. Mohammad Awad Expires: October 13, 2005 [page 28] INTERNET-DRAFT IDNAT April 11, 2005 TOD Another timeout signal that also fires within the RAC module but so as to indicate another course of actions should be followed 6.2.3. RAC Messages Format RAC ICMP Transaction For the RAC ICMP Transaction, the RIQ is basically a normal ICMP query get composed in the RAC protocol. After initially being composed in the normal way, the RAC composes a special purpose srcNHC from a dummy NHC value and inserts it into the IP option part of the IP header of the ICMP packet. RAC DNS Transaction The messages comprising the RAC DNS Transaction are normal DNS messages in fully compliance with the specifications in [1]. The RDQ is DNS normal query containing the standard Query Header and Question parts that would express inquiring for all TXT RR belonging to the destination address under investigation. Thus the query header part includes an indication of being a query, indication of having the standard query OPCODE and an indication of having only one question. The question part includes the QNAME referring to the destination address under investigation but in the reversed form that the DNS reverse domain would accept. Furtherly, the QTYPE and QCLASS within the question part are always set to "TXT" and "IN" values respectively, to indicate that the current query inquires within the Internet class for any TXT record. Mohammad Awad Expires: October 13, 2005 [page 29] INTERNET-DRAFT IDNAT April 11, 2005 +-----------------------------------------------------------------+ | | | +------------------------+ +-------+ | | | | | | | | | IDNAT | | DNS | | | | | |SERVER | | | | +--------------------+ | 6 | | | | | | RAC | |<--------RIQ(DA,TXT)----| | | | | | | | | | | | | | | | 5 | | | | | | | |---------RDQ(DA)------->| | | | | | 4 7 | | | | | | | | +----+ +----+ | | | | | | | | |TOD | |TOI | | | | | | | | | +----+ +----+ | | | | | | | | | | +-------+ | | | | | | | | | +--------------------+ | +-------+ | | | /|\ | /|\ | 3 | | | | | | | | |<---------RIQ(DA)-------| HOST | | | | 1 | 9 | 8 | | | | | | | RB RE RH | | | | | | | | | | 3 | | | | | | | | |<-----RIQ(DA,DSTNHC)----| | | | | | \|/ | | | | | | | +--------------------+ | | | | | | | PTP | | 2 | | | | | | | |---------RIQ(DA)------->| | | | | +--------------------+ | | | | | | | | | | | +------------------------+ +-------+ | | | | | | | +-----------------------------------------------------------------+ Figure 12: The RAC Protocol Procedure While the RDQ message was a standard DNS query with special meaning contents, likewise, the RDR is just the reply provided by the authoritative DNS server in response to that RDQ. Therefore, the RDR is expected to contain three main parts; one for the header, another for the question that normally remain existing in DNS replies, and the third one is the answer part. Except for minor changes, the header of RDR contains almost all the values present in the RDQ. Only the Query indicator changes to the Response indicator and the AA bit is set to indicate an authoritative answer [1]. The question part remains exactly the same as for the corresponding RDQ. Mohammad Awad Expires: October 13, 2005 [page 30] INTERNET-DRAFT IDNAT April 11, 2005 It is however the answer part where the query results should be present. The query result is set of zero or more of TXT records belonging to the domain name corresponding to the address under investigation that had been produced by the query. The RDR should contain as much TXT records as the server could find. 6.2.4. The RAC Protocol Procedure As the original requestor of such information provided by the RAC protocol is actually the PTP module, therefore this one is who starts the protocol by sending at first the RB message along with the address to be investigated as an argument; see Figure 12. Next, the RAC module would start its own investigation process to find out whether or not this particular address is an IDC one. The two types of transactions, ICMP and DNS, are capable of doing this job. However, they are both out there because each of them is more preferable to the other in one perspective but meanwhile less preferable in another. While the RAC ICMP Transaction is less time consuming, it sometimes may fail due to the configuration of some destination hosts where they are set such that not to respond to ICMP requests. Due to this performance measure, the RAC module always starts with the RAC ICMP Transaction, then the RAC DNS Transaction the next trial if it should have to do another trial. But in order not to keep waiting for an infinite duration until the ICMP transaction to complete -which actually might never complete due to what discussed above-, the RAC just waits for a specified time controlled by the use of the timer, TOI. Once this time out fires, then this is an indication to start the DNS transaction provided that the ICMP response has not arrived yet. In the same way, also the DNS Transaction is controlled by another timer, the TOD for the same reason, such a timer that if it fires before the response arrives then the transaction terminates even if the conclusion is not ready yet. In such cases, the RAC will decide itself to consider that the unclassified destination is of the non-IDC type. This decision is actually taken because the traffic that would be crafted to fit for receiving by this guessed non-IDC host is ensured to be understood there even if the destination was actually an IDC, but the reverse case is not correct. The following points show the sequence of actions conducted by the RAC protocol: 1- The PTP module sends the RB(da) message to the RAC module. 2- The RAC module lookups the address within the RB message in the RAC_table. If it's found, the sequence will jump at once to point number 7, otherwise action will be taken in the following sequence. 3- The RAC module sends the RIQ(da) to the destination under investigation. Mohammad Awad Expires: October 13, 2005 [page 31] INTERNET-DRAFT IDNAT April 11, 2005 4- The destination responds by sending back the expected RIR(da,dstNHC) message in case of an IDC host or the RIR(da) message in case of a non-IDC host. 5- If otherwise no RIR is not received until the TOI fires, then the RAC module sends the RDQ(da) to the DNS 6- The DNS responds by sending the expected RDR(da,TXT) back to the RAC module. Then the RAC module can seek the required IDTXT record inside the received RRset. 7- Following the search in point number 5, the RAC will respond to the PTP by either the RE(da,IDC) if it had found the required IDTXT or by the RE(da,non-IDC) otherwise. Besides that message, also the information is written in the RAC_table for future references by the RAC module. 8- In any time since the action in point number two up to number six, the PTP module can be sending an RH(da,IDC) or an RH(da,non-IDC) messages. Upon such events, whatever the rest of actions in the RAC protocol will be overlooked and the sequence will at once jump to number 7. 6.3. The Modified DNS Protocol The IDC private hosts in the IDNAT model are actually published in the DNS in terms of their NHI addresses, instead of IP addresses. This is just the single way that ensures NHI addresses will be used in communication which is the starting step to achieve the objectives of the IDNAT model. However, the NHI addresses are not stored in the normal A resource records, they are rather stored in specific TXT records named NHITXT resource records, see section. This actually means that normal resolvers that used to get the addressing information about whatever hosts using "A" DNS queries will definitely fail to get the intended NHITXT records. Therefore, there is really the need to allow the resolvers to otherwise use another slightly modified technique so as to guarantee the receipt of the NHITXT in such cases. Also in the course of providing more appropriate DNS operations for the IDNAT model, there is the need to be willing to address DNS servers that are running on private hosts as well. This implies that as queries are hopping between parent DNS and child DNS it should always have to be considered that next child DNS servers possibly might be private hosts, thus they would themselves have NHI glue resource records in the parent zones. Hence it is required to have the DNS queries modified such that in each hop, they try to find NHITXT glue records for servers of the next hop actually as they would seek "A" glue records. The modified DNS protocol is the one that achieves the above goals. The DRE module incorporated within resolvers in the IDNAT model are the responsible entities to modify the behavior of their coexisting resolvers in order to achieve those given goals. Mohammad Awad Expires: October 13, 2005 [page 32] INTERNET-DRAFT IDNAT April 11, 2005 6.3.1. The Behavior of the Modified DNS Operations +---------------------------------------------------------------+ | | | | | +-----------+The normal DNS query inquiring+-----------+ | | | | about the addressing | | | | | | information | | | | | DNS | | | | | | | | DNS | | | | RESOLVER | QNAME=X QTYPE=A | | | | | |----------------------------->| SERVER | | | | | The A RR belonging to X | | | | | |<-----------------------------| | | | | | | | | | | | | | | | +-----------+ +-----------+ | | | | | | | | +-----------+ The modified DNS query for +-----------+ | | | | the addressing | | | | | | information | | | | | DNS | | DNS | | | | | QNAME=X QTYPE=A and TXT | | | | | RESOLVER |----------------------------->| SERVER | | | | | | | | | | | A and TXT RR belonging to X | | | | | |<-----------------------------| | | | | | | | | | | | | | | | +-----------+ +-----------+ | | | | | +---------------------------------------------------------------+ Figure 13: The Modified Behavior of the DNS Resolvers In order to achieve the above mentioned objectives, the following modifications on the normal behavior of DNS resolvers are to be applied by the influence the DRE imposes: 1- Queries that are explicitly formed to retrieve "A" resource records will otherwise be attached an additional DNS question with. This additional question is aimed at inquiring about any TXT records belonging to the same QNAME present inside the original question. 2- All queries that have an implicit request for the recursive mode will change to the iterative mode. In other words, the iterative mode will be the single one permitted to send queries. Mohammad Awad Expires: October 13, 2005 [page 33] INTERNET-DRAFT IDNAT April 11, 2005 3- Due to the restriction on the previous point and following the standards of the query processing stated in [1], it will happen that before the final result of query arrives at the resolver, many referrals of the referenced DNS servers along the DNS hierarchy will arrive at the resolver as well. Then, upon the receipt of each such referral, it is required that another query is to be sent to the particular DNS server providing the current referral. Such a query that would inquire about any TXT records belonging to the specific child DNS server to which the referral is actually referring. Actually in this way, it could be guaranteed that if this child DNS server is running on a private host, the parallel query will retrieve the NHITXT records stored out there at its parent DNS server. Following, when the reply of this parallel query arrives, it should be searched attempting to locate any NHITXT within. The presence of the NHITXT will mean that the child DNS server is actually on a private host, but the absence of it will mean it is on a real one. But during the time between when the parallel query was sent until its reply arrives and get processed, the original query was pending. So after the processing, it should be resumed such that in the case of an NHITXT was not found, it will resume normally, but otherwise the NHITXT will be fed into the next phase of resolving so as to address the next child DNS server. 7. Applications Behavior with the IDNAT Model On top of the IDNAT model, all applications can run without obstacles. Since the IDNAT model include backward compatibility for non-IDC hosts, and then it is always guaranteed that applications that do not understand the IDC model can still work over it. However, there are still some applications that need to be upgraded to another version compliant with IDC, not because it can not work as of the current version, but to gain the advantages of the model. Particularly, applications that are used to include addressing information within the payload are those of that category. For spotting the light on these needs, we will take a general example of a network application X running over two IDC machines; a real one and a private one. The application passes the addressing information of PH to H so that the latter can use it to access the former later on. As the objective of the IDNAT model is to force hosts to access private hosts using the NHI, so the first requirement in the case of application X is to include the NHI in the payload instead of the private IP address. Of course this necessitates that the message format gets another form to have the 8 octets of NHI identifier fit inside the room which was previously fitting for only 4 octets of IP. Mohammad Awad Expires: October 13, 2005 [page 34] INTERNET-DRAFT IDNAT April 11, 2005 Moreover, the instance of X at H will receive this NHI and later on may need to address the private host. Therefore, X has to be able to understand that this strange 8 octets formula refers to a type of addressing information. But as the underlying host is an IDC one, it just does not have to worry about doing anything else beyond passing this NHI to the transport layer indicating that it needs to address the destination machine via this particular address. The IDC host transport layer is well trained to perform jobs like that. 7.1 Guidelines for IDC Applications The following rules are the general guidelines of such upgrade. a. Only applications that carry IP address into the payload are those which need upgrade. b. In the upgraded version, the application should be able to do the following: b.1. The format of the message that particularly include the IP address should be changed to fit for the 12 octets instead; the first four are for the normal IP address while the second eight octets are to contain the NHI. The application has to be aware how to form this message and how to understand if as well. b.2. When the application intends to get the addressing information of the local host, it should try as the first course of actions, to use the GET_SRCNHI system call. Turning to use GET_SRCADDR should only be in the case where the former is not available. This case maps to the case where the underlying host is either a non-IDC private host or a non-private host at all. b.3. When the application receives a message into which there is an NHI value in the form described in item number "a", it should try as the first course of actions to address the specified peer via this value; the NHI. To do this it should request the transport layer to initiate the SEND function taking the NHI value as the argument. Following, the application should be standing by in a particular intermediate wait state to find out the result of that particular SEND function. If the result is positive, then the application can proceed to the next state. Otherwise, if the SEND command fails due to the fact that the transport layer cannot accept the NHI value argument, then the application should request another SEND function with the IP address in this turn, and proceed to the next state directly. c. The backward compatibility should be preserved, that the upgraded application should still maintain all the backward functionality. And at the beginning of communication between multiple peers, the upgraded peer should always make sure that other peers are also at an upgraded version. When this is not true, the upgraded peers should entirely switch to the backward functionality where all the considerations of the previous point are not activated. Mohammad Awad Expires: October 13, 2005 [page 35] INTERNET-DRAFT IDNAT April 11, 2005 These were the guidelines for upgrading applications so as to understand the IDNAT model. In following, we will present one example for this upgrade which addresses the FTP application. 7.2 The IDC FTP Design 7.2.1. Modifying the Message Format to Support NHI To comply to point number 5.1.2.1 of Guidelines for IDC Applications, we need to determine in advance the particular FTP commands that can include addressing information. By referring to [8] it could be found that the following is our objective: The "PORT" command The reply code of "PASV"; particularly the reply code 227. The normal format of both of them is four successive 8 bit octets followed by two 16 bit words comprise the parameter. Therefore, another format needs to be innovated. Fortunately, the subject of changing the format of the PORT and PASV reply code has been previously discussed in details years. Particularly the need for getting FTP fitting with a wide variety of protocol families rather than IP was the reason for this step. As this need arose, it quickly has developed into an RFC, [7]. Particularly that document presents other variations named LPORT and LPASV that are to replace the conventional ones. Therefore by using these modified commands or in other words, by being in compatibility with [7] the FTP application could have achieved 50% of the requirements of IDC application. The rest of requirements however will have to be designed in specific. The behavior of LPRT and LPSV are very similar to PORT and PASV, except for the arguments. The analogous reply code of 227 is 228 in the case of LPSV. FOOBAR allows the determination of a wide range of address families, not only the IP address version 4. Therefore, there are more than only two parameters to identify the address/port. In fact those parameters are also the arguments of the LPRT and the 228 reply codes [7]. In order to make use of the FOOBAR specifications in the IDC FTP, we can consider that the NHI pertains to one of the special address families and therefore a specific address family number has to be agreed upon for defining it. By referring to [7], we can see that any number in the range 16 to 255 can fit for this purpose, so it is appropriate to choose number 20. The NHI identifier itself will be occupying eight successive octets, so the host address length will always be the number eight. To summarize, the arguments of the LPRT and the reply code 228 for the IDC FTP application should be as per the following listing. Address Family: 20 Host Address Length: 8 Host Address: The value of the NHI Port Address Length: 2 Port Address: The value of the port number Mohammad Awad Expires: October 13, 2005 [page 36] INTERNET-DRAFT IDNAT April 11, 2005 7.2.2. Checking for IDNAT Compliance between Peers By this stage, we have arrived at determining the modified format of the messages that contain addressing information in the FTP application, this being achieving the requirement number 2a of the IDC requirements. In fact, FOOBAR functionality can be exploited to support the requirement number three too, which is checking the IDC compatibility before communication. As FOOBAR has invented this new command LPRT and LPSV, it has also defined the appropriate reply codes by which the server can respond so as to determine whether it understands the commands and supports the specified address family or not. Particularly when the server receives either LPRT or LPSV commands while it does not support them, it can respond with the negative completion reply code 500 or 501 to indicate so; [7]. But these reply codes that express the general "syntax error" status does not really satisfy all the requirements. Therefore, FOOBAR also has defined a particular negative completion reply code "521" for the case where the server does support the FOOBAR specifications but does not support the address family specified. The 521 reply code takes an argument which is the list of the address families that the server supports rather than the one specified in the command. With respect to the IDC FTP application, this variety of reply codes can be employed to satisfy the current requirement. Simply, the logic will be as follows. The user always is the party that initiates the negotiation of data connection parameters. So the user in the IDC application starts with sending the particular LPRT or the LPSV discussed here in this draft. If the server is running an IDC version too, it will respond with positive reply codes, which will mean to the user that the server is already an IDC version. Otherwise, the server can be running some version that does not support the FOOBAR at all; hence non IDC one. So in this case the server will reply with the syntax error (500 or 501) reply code. Also it is possible that the server might be running a particular version of FTP that supports FOOBAR in general but does not support IDNAT, so this is the case where the server will reply with the 521 negative reply codes refusing the address family number 20. In both of the latter two cases, the FTP client will be aware that the other party is not an IDC one, and that it should restart the negotiation with the normal PORT or PASV commands. To summarize, the server reply codes along with the corresponding client decisions are listed in the following listing. 1- If a positive completion reply code is received in response to LPRT or LPSV then the server is running an IDC version. 2- If the 500 reply code is received in response to LPRT or LPSV, then the server is running a non-IDC version. 3- If the 501 reply code I received in response to LPRT or LPSV, then the server is running a non-IDC version. 4- If the 521 reply code is received in response to LPRT or LPSV, then the server is running a non-IDC version. Mohammad Awad Expires: October 13, 2005 [page 37] INTERNET-DRAFT IDNAT April 11, 2005 7.2.3. Modifying Internal Behavior of the FTP Application The next part however is something not supported by FOOBAR. In this part we need to define some logic to realize the items no. b2 and b3 of the IDC requirements. Part 2b and 2c however do not require inventing new commands; they will be just modifications to the behavior of the server DTP, the server PI, the user DTP and the user PI to be committed to those requirements. See [8] for the definitions of those components. 8. Performance Considerations As shown throughout the proposal, the functionality is highly dependent on the two IP options described in section 4.1. The IP options are part of the specifications of the Internet Protocol. However, in the practical perspective many backbone routers do not adhere to the specification and abandon the IP options processing since such processing bring out dramatic delay in the overall throughput. But the IP options introduced herewith do not require any kind of processing, except for the copy-on- fragment which could be processed at the hardware speed. Therefore, in principle, those IP options could be conveyed by the high speed backbone routers without causing any additional delay. 9. IANA Considerations The part that may concern IANA in this proposal is the two new proposed IP options described in section 4.1. It is required that IANA registers those two options with their associated type, numbers and other flags in the IP Parameter section. 10. Security Considerations No special security considerations seem to arise from the limited functionalities defined in this document. 11. References 11.1. Informative [1] P. Mockapetris, " Domain Names - Concepts and Facilities ", The Internet Engineering Task Force, RFC 1034, Nov 1987. [2] R. Rosenbaum, "Using the Domain Name System to Store Arbitrary String Attributes", The Internet Engineering Task Force, RFC 1464, May 1993. Mohammad Awad Expires: October 13, 2005 [page 38] INTERNET-DRAFT IDNAT April 11, 2005 [3] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", The Internet Engineering Task Force, RFC 2663, Aug 1999. [4] P. Srisuresh, K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", The Internet Engineering Task Force, RFC 3022, Jan 2001. [5] The US Department of Defence, "Internet Protocol Specification", The Internet Engineering Task Force, RFC 791, Sep 1981. [6] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", The Internet Engineering Task Force, RFC 2459, Jan 1999. [7] D. Piscitello, "FTP Operation Over Big Address Records (FOOBAR)", The Internet Engineering Task Force, RFC 1639, Jun 1994. [8] J. Postel, J. Reynolds, "File Transfer Protocol (FTP)", The Internet Engineering Task Force, RFC 959, Oct 1985. [9] Yasser H. Dakroury, M. Awad, "Towards More Fixed Identity for Private Hosts behind NAT Routers", SPECTS'03 Proceedings, Montreal, 24-29 Jul 2003 . 12. Author's Address Mohammad A. Awad ENPPI 1A Ahmed Elzomor st. Nasr City, Cairo Egypt Email: mawad@enppi.com Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Mohammad Awad Expires: October 13, 2005 [page 39] INTERNET-DRAFT IDNAT April 11, 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mohammad Awad Expires: October 13, 2005 [page 40]