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]