Internet DRAFT - draft-awad-nat-idnat
draft-awad-nat-idnat
Internet Draft Mohammad Awad
NAT Working Group ENPPI
Expires: October 13, 2005 April 11, 2005
More Fixed Identities for Private
Hosts behind NAT
IDNAT
<draft-awad-nat-idnat-00.txt>
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]
