[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 rfc2694                                        
NAT Working Group                      P. Srisuresh, Lucent Technologies
INTERNET-DRAFT                             G. Tsirtsis,  BT Laboratories
Category: Informational                      P. Akkiraju,  Cisco Systems
Expire in six months                         A. Heffernan, Cisco Systems
                                                               July 1998


        DNS extensions to Network Address Translators (DNS_ALG)
                   <draft-ietf-nat-dns-alg-00.txt>

Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Abstract

   Domain Name Service(DNS) provides name to address mapping within
   a routing class (ex: IP). Network Address Translators (NATs)
   provide transparent routing between hosts in disparate routing
   realms of the same routing class. Typically, NATs exist at the
   border of a stub domain, hiding private addresses from external
   addresses. This document identifies the need for DNS extensions
   to NATs and outlines how a DNS Application Level Gateway (DNS_ALG)
   can meet the need. DNS_ALG modifies payload transparently to alter
   address mapping of hosts as DNS packets cross one routing realm
   into another. The document also illustrates the operation of
   DNS_ALG with specific examples.






Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 1]


Internet Draft            DNS extensions to NAT                July 1998


1. Introduction

   Network Address Translators (NATs) are often used when network's
   internal IP addresses cannot be used outside the network either
   for security reasons or because they are invalid for use outside
   the network.

   Ideally speaking, a host name uniquely identifies a host and its
   address is used to locate routes to the host. However, host name
   and address are often not distinguished and used interchangeably
   by applications. Applications embed IP address instead of host
   name in payload. Examples would be e-mails that specify their MX
   server address as sender ID instead of server name; HTML files
   that include IP address instead of names in URLs, etc. Use of IP
   address in place of host name in payload represents a problem as
   the packet traverses a NAT device because NATs alter network and
   transport headers to suit a routing realm, but not payload.

   DNS provides Name to address mapping. NATs translate private
   addresses into external addresses and vice versa. DNS extensions
   outlined in this document help translate Name to Private Address
   mapping in DNS payloads into Name to external address mapping
   and vice versa using the state information available with NATs.

   Network Address Port Translators (NAPTs) perform address and
   Transport level port translations (i.e, TCP, UDP ports and ICMP
   query IDs). DNS name mapping granularity, however, is limited to
   IP addresses and does not extend to transport level identifiers.
   As a result, the discussion in the remainder of the document will
   not be applicable to NAPTs, when referring NATs. Basic NAT,
   Bi-directional NAT and Twice NAT are covered by this document.

   Definitions for DNS and related terms may be found in [Ref 3] and
   [Ref 4]. Definitions for NAT and related terms may be found in
   [Ref 1].

2. Requirement for DNS extensions.

   There are many ways to ensure that a host name is mapped to an
   address relevant within a routing realm. In the following
   sections, we will identify where DNS extensions would be needed.

   Typically, organizations have two types of authoritative name
   servers. Internal authoritative name servers identify all (or
   majority of) corporate resources within the organization. Only a
   portion of these hosts are allowed to be accessed by the external
   world. The remaining hosts and their names are unique to the
   private network. Hosts visible to the external world and the



Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 2]


Internet Draft            DNS extensions to NAT                July 1998


   authoritative name server that maps their names to network
   addresses are often configured within a DMZ (De-Militarized Zone)
   in front of a firewall. We will refer the hosts and name servers
   within DMZ as DMZ hosts and DMZ name servers respectively. DMZ
   host names are end-to-end unique. The figure below illustrates
   configuration of a private network which includes a DMZ. Actual
   configurations may vary.

                                   \ | /
                           +-----------------------+
                           |Service Provider Router|
                           +-----------------------+
                            WAN  |
                                 |
               Stub A .........|\|....
                               |
                               |
                     +-----------------+
                     |Stub Router w/NAT|
                     +-----------------+
                         |
                         |   DMZ - Network
   ------------------------------------------------------------
      |         |              |            |             |
     +--+      +--+           +--+         +--+      +----------+
     |__|      |__|           |__|         |__|      | Firewall |
    /____\    /____\         /____\       /____\     +----------+
   DMZ-Host1  DMZ-Host2 ...  DMZ-Name     DMZ-Web       |
                             Server       Server etc.   |
                                                        |
     Internal hosts (Private IP network)                |
   ------------------------------------------------------------
       |             |                 |           |
      +--+         +--+               +--+       +--+
      |__|         |__|               |__|       |__|
     /____\       /____\             /____\     /____\
    Int-Host1    Int-Host2  .....   Int-Hostn   Int-Name Server

    Figure 1: DMZ network configuration of a private Network.


   Internal name servers are accessed by users within private network
   only. Internal DNS queries and responses do not cross the private
   routing boundary. DMZ name servers and DMZ hosts on the other hand
   are end-to-end unique and could be accessed by external as well as
   internal hosts. Throughout this document, our focus will be limited
   to DMZ hosts and DMZ name servers and will not include internal
   hosts and internal name servers, unless they happen to be same.



Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 3]


Internet Draft            DNS extensions to NAT                July 1998



2.1. DMZ hosts assigned static external addresses

   Take the case where DMZ hosts are assigned static external
   addresses. These hosts must be identified by their private
   addresses within private domain and by their public addresses
   in the external domain.

2.1.1. Private networks with no DMZ name servers

   Take the case where a private network has no DMZ name server
   for itself. If the private network is connected to a single service
   provider for external connectivity, the DMZ hosts may be listed
   by their external addresses in the authoritative name servers of
   the service provider itself.

   If the network is connected to multiple service providers, the
   DMZ host names may be listed by their external address(es) within
   the authoritative name servers of each of the service providers,
   especially if the private network is assigned different address
   prefixes by the service providers.

   In both cases, externally generated DNS lookups will not reach the
   private network.  A large number of NAT based private domains
   pursue this option to have their DMZ hosts listed by their
   external addresses on service provider's name servers.

2.1.2. Private networks with DMZ name servers

   Take the case where a private network opts to keep an authoritative
   DMZ name server for the zone within the network itself. If the
   network is connected to a single service provider, DMZ name server
   be configured to obviate DNS payload interceptions as follows. The
   hosts in DMZ name server must be mapped to their statically assigned
   external addresses and the internal name server must be configured
   to bypass the DMZ name server for queries concerning external hosts.
   This scheme ensures that DMZ name servers are set for exclusive
   access to external hosts alone (not even to the DMZ hosts) and hence
   can be configured with external addresses only.

   The above scheme fails to scale when the private network is
   connected to multiple service providers, assigning different
   network addresses to the DMZ hosts. DNS extensions to NAT
   would prove useful here. It is conceivable, however, to
   have a separate pair of DMZ servers (primary and secondary)
   configured for each network address prefix assigned by a
   service provider for the organization.




Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 4]


Internet Draft            DNS extensions to NAT                July 1998


2.2. DMZ hosts assigned external addresses dynamically

   Take the case where DMZ hosts in a private network are assigned
   external addresses dynamically by NAT. While the addresses issued
   to these hosts are fixed within the private network, their
   externally known addresses are ephemeral, as determined by NAT.
   In such a scenario, it is mandatory for the private organization
   to have a DMZ name server in order to allow access to DMZ hosts
   by their name.

   The DMZ name server would be configured with private addresses
   for DMZ hosts. DNS Application Level Gateway (DNS_ALG) residing
   on NAT device will intercept the DNS packets directed to or from
   the DMZ name server(s) and perform transparent payload translations
   so that a DMZ host name has the right address mapping within
   each routing boundary (i.e., private or external).


3. Interactions between NAT and DNS_ALG

   This document operates on the paradigm that interconnecting routing
   realms may have overlapping address space. But, names of hosts
   within interconnected realms must be end-to-end unique in order for
   them to be accessed by all hosts. The following diagram illustrates
   how a DNS packet traversing a NAT device (with DNS_ALG) is subject
   to header and payload translations. NAT would translate the IP and
   TCP/UDP headers of the DNS packet and notify DNS-ALG to perform DNS
   payload changes. DNS-ALG would interact with NAT and use NAT state
   information to modify payload, as necessary.

                Original-IP
                 packet
                   ||
                   ||
                   vv
   +---------------------------------+    +-----------------------+
   |                                 |    |DNS Appl. Level Gateway|
   |Network Address Translation (NAT)|--->|     (DNS_ALG)         |
   |  -IP & Transport header mods    |<---|  -DNS payload mods    |
   |                                 |    |                       |
   +---------------------------------+    +-----------------------+
                   ||
                   ||
                   vv
              Translated-IP
                 packet

    Figure 2: NAT & DNS-ALG in the translation path of DNS packets



Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 5]


Internet Draft            DNS extensions to NAT                July 1998




3.1. Address assignment considerations for DNS-ALG

   We will make a distinction between address assignment and address
   binding in NATs. Address assignment is the instance in which an
   external address is reserved to be used in place of a private
   address or vice versa. Address Binding is the instance in which
   an external address is committed to be used in place of a private
   address or vice versa.  Address assignment and Address Binding are
   both between a private address and an external address. Address
   assignment is used by DNS_ALG to modify DNS payloads. Whereas,
   address binding is used by NAT to modify the IP and Transport
   headers of datagrams. Address binding implies address assignment.
   But, the reverse is not always true.

   For statically mapped addresses, address assignment is fixed at the
   instance of address mapping, independent of address binding and
   unbinding. For example, when 10.0.0.1 is statically mapped to
   198.76.29.1, address assignment between 10.0.0.1 and 198.76.29.1
   is fixed, independent of whether there exists a session between
   the private host and external hosts.

   For dynamically mapped addresses, address assignment often precedes
   address binding. Address assignment takes place when DMZ name server
   is queried for a name lookup. Name query is a likely pre-cursor to a
   real session between query originator and the queried host. Whereas,
   address binding occurs only upon seeing the first packet of a
   session between query initiator and queried host.

   An "Assignment-holdout time" may be defined for dynamic address
   assignments as the maximum period of time for which the assignment
   is held active before a bind occurs between the assigned addresses.
   With each use of address assignment by DNS_ALG to modify DNS
   payload, this assignment-holdout period is renewed afresh. Note,
   it is possible for an address binding to occur without address
   assignment ever having to precede it. When address binding occurs
   between a pair of addresses, address assignment between the two
   addresses is automatically assumed. Lastly, when address unbinding
   occurs, the address assignment must continue to be maintained for
   an additional assignment-holdout time period. At the expiry of
   assignment-holdout time, the external address is free to be
   reassigned to some other private address and vice versa. The
   assignment-holdout time preceding address binding and following
   address unbinding are required to ensure that end hosts will have
   at least that much time period in which to initiate a session
   following a name lookup query to DNS name server.




Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 6]


Internet Draft            DNS extensions to NAT                July 1998


   For example, say a private network with address prefix 10/8 is
   mapped to 198.76.29/24. When an external hosts makes a DNS query
   to host7, bearing address 10.0.0.7, the DMZ name server within
   private network responds with an A type RR for host7 as:

       host7  A  10.0.0.7

   DNS_ALG would intercept the response packet and if 10.0.0.7 is not
   assigned an external address already, it would request NAT to assign
   an external address and start assignment-holdout timer to age the
   assignment. Say, the assigned external address is 198.76.29.1.
   DNS-ALG would use this assignment to modify the RR in DNS response,
   replacing 10.0.0.7 with its assigned external address and reply with:

       host7  A  198.76.29.1

   When query initiator receives DNS response, only the assigned
   external address is seen. Within a short period (presumably before
   the assignment-holdout time expires), the query initiator would
   initiate a session with host7. When NAT notices the start of new
   session directed to 198.76.29.1, NAT would terminate
   assignment-holdout timer and bind 198.76.29.1 with its
   private address 10.0.0.7.

   To minimize denial of service attacks, where a malicious user
   keeps attempting name resolutions, without ever initiating a
   connection, NAT would have to monitor dynamic address assignments
   that have not materialized into bindings. There could be a limit
   on the number of dynamic address assignments (that have not
   transitioned into bindings) and attempts to generate newer
   assignments exceeding the limit could be simply rejected.
   There may be other heuristic solutions to counter this type
   of malicious attacks.

   We will consider bi-directional NAT to illustrate the use of
   address assignment by DNS_ALG in the following sub-sections, even
   though the concept is applicable to other flavors of NATs as well.

3.2. Incoming queries

   In  order  to initiate incoming sessions, an external host obtains
   the V4 address of the DMZ-host it is trying to connect to by making
   a  DNS request.  This  request  constitutes  prelude to the start of
   a potential new session.

   The external host resolver makes a name lookup  for the DMZ host
   through  its  DNS  server.  When the DNS server does not have a
   record of IPv4 address attached  to this  name,  the lookup query



Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 7]


Internet Draft            DNS extensions to NAT                July 1998


   is redirected at some point to the the Primary/Backup DNS server
   (i.e., in DMZ) of  the private stub domain.

   Enroute to DMZ name server, DNS_ALG would intercept the datagram
   and modify the query as follows.

         a) For Host name to Host address query requests:
            Make no change to the DNS payload.

         b) For Host address to Host name queries:
            Replace the external V4 address octets (in reverse  order)
            preceding the string "IN-ADDR.ARPA"  with the corresponding
            private V4 address, if such an address assignment exists
            already. However, if the assignment does not exist, the
            query is simply dropped and an ICMP error message is sent
            to query originator.

   In the opposite direction, as DNS response traverses from  the
   DNS  server in  private network, DNS_ALG would once again intercept
   the packet and modify as follows.

         a) For a host name to host address query requests, replace the
            private address sent by DMZ name server with a public
            address internally assigned by the NAT router. If a public
            address is not previously assigned to the host's private
            address, NAT would assign one at this time.

         b) For host address to host name queries, replace the private
            address octets preceding the string "IN-ADDR.ARPA" in
            response RRs with their external address assignments.
            There is a chance here that by the time the DMZ name server
            replies, the assignment-holdout timer in NAT for the address
            in question has expired. In such a case, NAT would drop the
            reply and send ICMP error message to query initiator.

   For static address assignments, the TTL value supplied in the
   original RR will be left unchanged. For dynamic address assignments,
   DNS_ALG would modify the TTL value on DNS resource records (RRs) to
   be 0, implying that the RRs should only be used for transaction in
   progress, and not be cached. In addition, NAT would be requested to
   initiate an assignment-holdout timer following the assignment.
   If no session is initiated to the private host within the time
   period, NAT would expire the assignment.

3.3. Outgoing Queries

   For Basic and bi-directional NATs, address assignment for outbound
   sessions coincides with address binding.  This is because, DNS_ALG



Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 8]


Internet Draft            DNS extensions to NAT                July 1998


   does not modify the DNS packets directed to or from external
   name servers (used during outbound sessions), unlike the inbound
   DNS sessions.

   Say, a private host needs to communicate with an external host.
   The  DNS query  goes  to  the internal name server (if there
   exists one) and from there to the appropriate authoritative/cache
   name server outside the private domain.  The  reply follows the
   same route but neither the query nor the response are subject to
   DNS_ALG translations.

   This however will not be the case with address isolated twice NAT
   private and external domains. In such a case, NAT would intercept
   all DNS packets and make address modifications to payload as
   discussed in the previous section. Private to external address
   assignments are made when responses are sent by private DNS
   servers and external to private address assignments are made when
   responses are sent by external DNS servers.


4. DNS payload modifications by DNS-ALG

   Typically, UDP is employed as the transport mechanism for DNS
   queries and responses and TCP for Zone refresh activities. In
   either case, name servers are accessed using a well-known DNS
   server port 53 (decimal) and all DNS payloads have the following
   format of data [Ref 4]. The header section is always present and
   includes fields specifying which of the remaining sections are
   present. The header identifies if the message is a query or a
   response. No changes are required to be made by NATs to the
   Header section. DNS_ALG would parse only the DNS payloads whose
   QCLASS is set to IN (IP class).


    +---------------------+
    |        Header       |
    +---------------------+
    |       Question      | the question for the name server
    +---------------------+
    |        Answer       | RRs answering the question
    +---------------------+
    |      Authority      | RRs pointing toward an authority
    +---------------------+
    |      Additional     | RRs holding additional information
    +---------------------+

4.1. Question section




Srisuresh, Tsirtsis, Akkiraju & Heffernan                       [Page 9]


Internet Draft            DNS extensions to NAT                July 1998


   The question section contains QDCOUNT (usually 1) entries, as
   specified in Header section, with each of the entries in the
   following format:

                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                     QNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QTYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     QCLASS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

4.1.1. PTR type Queries

    DNS_ALG must identify all names, whose FQDNs (i.e., Fully Qualified
    Domain Names) fall within IN-ADDR.ARPA domain and replace the
    address octets (in reverse  order)  preceding the string
    "IN-ADDR.ARPA"  with the corresponding assigned address octets
    in reverse order, only if the address assignment is active on
    the NAT router. If the address preceding the string
    "IN-ADDR.ARPA" falls within the NAT address map, but is not
    assigned an address, DNS_ALG would simply drop the packet and send
    an ICMP error message to sender.

    Note that the above form of host location to host name type
    queries will likely yield different results at different times,
    depending upon the address assignment status within NAT router
    at a given time.

    For example, a resolver that wanted to find out the hostname
    corresponding to address 198.76.29.1 (externally)  would pursue a
    query of the form:
        QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA.

    DNS_ALG would intervene and if the address 198.76.29.1 is
    internally mapped to a private address of 10.0.0.1, modify the
    query as below and forward to DMZ name server within private
    network.

        QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA

    Presumably, the DMZ name server is the authoritative name server
    for 10.IN-ADDR.ARPA zone and will respond with an RR of the
    following form in answer section. DNS_ALG translations of the



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 10]


Internet Draft            DNS extensions to NAT                July 1998


    response RRs will be considered in a following section.

        1.0.0.10.IN-ADDR.ARPA  PTR  host1.fooboo_org.provider_domain

    Inverse translation is a fairly popular technique used by e-mail
    programs to trace e-mail originating hosts and prevent spam.
    ex: verify if the address from which the e-mail was sent does
    indeed belong to the same domain name the sender claims as
    sender ID. There may be other applications.

    Query modifications of this nature will likely change the length
    of DNS payload. As a result, the corresponding IP and TCP/UDP
    header checksums must be updated. In case of TCP based queries,
    the sequence number deltas must be tracked by NAT so that the
    delta can be applied to subsequent sequence numbers in datagrams
    in the same direction and acknowledgement numbers in datagrams in
    the opposite direction. In case of UDP based queries, message
    sizes are restricted to 512 bytes (not counting the IP or UDP
    headers). Longer messages must be truncated and the TC bit should
    be set in the header.

    Lastly, any compressed domain names using pointers to represent
    common domain denominations must be updated to reflect new
    pointers with the right offset, if the original domain name had
    to be translated by NAT.

4.1.2. A, MX, NS and SOA type Queries

    For these queries, DNS_ALG would not modify any of the fields in
    the query section, not even the name field.

4.1.3. AXFR type Queries

    AXFR is a special zone transfer type query. Zone transfers from
    private routing realm must be avoided for address assignments
    that are not static. Typically, TCP is used for AXFR requests.

    When changes are made to a zone, they must be distributed to all
    name servers.  The general model of automatic zone transfer or
    refreshing is that one of the name servers is the master or
    primary for the zone.  Changes are coordinated at the primary,
    typically by editing a master file for the zone.  After editing,
    the administrator signals the master server to load the new zone.
    The other non-master or secondary servers for the zone
    periodically check the SERIAL field of the SOA for the zone for
    changes (at some polling intervals) and obtain new zone copies
    when changes have been made.




Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 11]


Internet Draft            DNS extensions to NAT                July 1998


    Zone transfer is usually from primary to backup name servers. In
    the case of NAT supported private networks, both primary and
    backup servers will likely be in the same private domain.
    In such a case, zone transfer does not cross the realm and
    DNS_ALG support for zone transfer is not an issue. In the case a
    secondary name server is located outside the premisis of private
    network, zone transfers must not be permitted for non-static
    address assignments.

    During zone transfers, DNS_ALG must examine all A type records
    and replace the original address octets with their statically
    assigned address octets. DNS_ALG could also examine if there is
    an attempt to transfer records for hosts that are not assigned
    static addresses and drop those records alone or drop the whole
    transfer. This would minimize misconfiguration and human errors.


4.2. Resource records in all other sections

    The answer, authority, and additional sections all share the same
    format, with a variable number of resource records. The number of
    RRs specific to each of the sections may be found in the
    corresponding count fields in DNS header. Each resource record
    has the following format:



























Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 12]


Internet Draft            DNS extensions to NAT                July 1998


                                    1  1  1  1  1  1
      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                                               |
    /                                               /
    /                      NAME                     /
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TYPE                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     CLASS                     |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                      TTL                      |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                   RDLENGTH                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
    /                     RDATA                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   The TTL value supplied in the original RRs is left unchanged For
   static address assignments. For dynamic address assignments,
   DNS_ALG would modify the TTL to be 0, so the RRs are used just
   for the transaction in progress, and not cached.

4.2.1. PTR type RRs

   The considerations specified in the Question section
   is equally valid with names for PTR type RRs. Private address
   preceding the string "IN-ADDR.ARPA" (in reverse order of
   octets) must be replaced by its external address assignment
   (in reverse order), if a valid assignment exists. The
   remaining fields for this RR remain unchanged.

4.2.2. A type RRs

   The RDATA for A records  is a 4-byte IP address. DNS_ALG would
   simply replace the original address in RDATA with its externally
   assigned IP address, if NAT succeeded in finding an address
   assignment. Successful address translation should cause no
   changes to payload length. Only the transport header checksum
   would need updating. In case of failure to find an assignable
   address, DNS_ALG would have to either drop the record
   selectively or drop the whole packet.

4.2.3. CNAME, MX, NS and SOA type RRs




Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 13]


Internet Draft            DNS extensions to NAT                July 1998


   No changes required to be made by DNS_ALG for these RRs, as the
   RDATA does not contain any IP addresses. The host names within
   the RDATA remain unchanged between realms.


5. Illustration of DNS_ALG in conjunction with Bi-directional NAT

   The following diagram illustrates the operation of DNS_ALG in a
   a bi-directional NAT router. We will illustrate by walking
   through how name lookup and reverse name lookup queries are
   processed.

                                             .
                         ________________    .     External.com
                        (                )   .
                       (                  )  .   +-------------+
            +--+      (      Internet      )-.---|Border Router|
            |__|------ (                  )  .   +-------------+
           /____\       (________________)   .          |
            Root                 |           .          |
         DNS Server              |           .     ---------------
                         +---------------+   .       |         |
                         |Provider Router|   .     +--+       +--+
                         +---------------+   .     |__|       |__|
                                 |           .    /____\     /____\
                                 |           .  DNS Server   Host X
       External domain           |           .  171.68.1.1  171.68.10.1
     ............................|...............................
       Private domain            |
                                 |        Private.com
                                 |
                +--------------------------------------+
                |Bi-Directional NAT router with DNS_ALG|
                |                                      |
                | Private addresses:  172.19/16        |
                | External addresses: 131.108.1/24     |
                +--------------------------------------+
                              |      |
                      ----------    ----------
                        |                  |    DNS Server
                       +--+               +--+  Authoritative
                       |__|               |__|  for private.com
                      /____\             /____\
                      Host A           DNS Server
                   172.19.1.10        172.19.2.1
                                      (Mapped to 131.108.1.8)

    Figure 3: DNS-ALG operation in Bi-Directional NAT setup



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 14]


Internet Draft            DNS extensions to NAT                July 1998




   The above diagram depicts a scenario where a company private.com
   using private address space 172.19/16 connects to the Internet
   using bi-directional NAT. DNS_ALG is embedded in the NAT device
   to make necessary DNS payload changes. NAT is configured to
   translate the private addresses space into an external address
   block of 131.108.1/24. NAT is also configured with a static
   translation for private.com's DNS server, so it can be referred
   in the external domain by a valid address.

   The company external.com is located in the external domain, using
   a registered address block of 171.68/16.  Also shown in the
   topology is a root DNS server.

   Following simplifications are made to the above configuration:

       * private.com is not multihomed and all traffic to the external
         space transits a single NAT.

       * The DNS server for private.com is authoritative for the
         private.com domain and points to the root server for all
         other DNS resolutions.  The same is true for the DNS server
         in external.com.

       * The internal name servers for private.com and external.com
         are same as their DMZ name servers. The DNS servers for these
         domains are configured with addresses private to the
         organization.

       * The name resolvers on host nodes do not have recursion
         available on them and desire recursive service from servers.
         All name servers are assumed to be able to provide
         recursive service.

5.1. Outgoing Name-lookup queries

   Say, Host A in private.com needs to perform a name lookup for
   host X in external.com to initiate a session with X.  This would
   proceed as follows.

   1. Host A sends a UDP based name lookup query (A record) for
      "X.External.Com" to its local DNS server.

   2. Local DNS server sends the query to the root server enroute
      NAT. NAT would change the IP and UDP headers to reflect DNS
      server's statically assigned external address.  DNS_ALG will
      make no changes to the payload.



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 15]


Internet Draft            DNS extensions to NAT                July 1998



   3. The root server, in turn, refers the local DNS server to query
      the DNS server for External.com. This referal transits the NAT
      enroute to the local DNS server.  NAT would  simply translate
      the IP and UDP headers of the incoming packet to reflect DNS
      server's private address. No changes to the payload by DNS_ALG.

   4. Private.com DNS server will now send the query to the DNS server
      for external.com, once again, enroute NAT. Just as with the query
      to root, The NAT router would change the IP and UDP headers to
      reflect the DNS server's statically assigned external address.
      And, DNS_ALG will make no changes to the payload.

   5. The DNS server for external.com replies with the IP address
      171.68.10.1.  This reply also transits the NAT. NAT would
      translate the IP and UDP headers of the incoming packet to
      reflect DNS server's private address. Once again, no changes
      to the payload by DNS_ALG.

   6. The DNS server in Private.com replies to host A.

   When Host A finds the address of Host X, A initiates a session with
   host X, using a destination IP address of 171.68.10.1. This datagram
   and any others that follow in this session will be translated as
   usual by NAT.

   Note, DNS_ALG does not change the payload for DNS packets in
   either direction.

5.2. Reverse name lookups originated from private domain

   This scenario builds on the previous case by having host A in
   Private.com perform a reverse name lookup on 171.68.10.1, which
   is host X's global address. Following is a sequence of events.

   1. Host A sends a UDP based inverse name lookup query (PTR record)
      for "1.10.68.171.IN-ADDR.ARPA." to its local DNS server.

   2. Local DNS server sends the query to the root server enroute
      NAT. As before, NAT would change the IP and UDP headers to
      reflect DNS server's statically assigned external address.
      DNS_ALG will make no changes to the payload.

   3. The root server, in turn, refers the local DNS server to query
      the DNS server for External.com. This referal transits the NAT
      enroute to the local DNS server.  NAT would  simply translate
      the IP and UDP headers of the incoming packet to reflect DNS
      server's private address. No changes to the payload by DNS_ALG.



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 16]


Internet Draft            DNS extensions to NAT                July 1998



   4. Private.com DNS server will now send the query to the DNS server
      for external.com, once again, enroute NAT. Just as with the query
      to root, The NAT router would change the IP and UDP headers to
      reflect the DNS server's statically assigned external address.
      And, DNS_ALG will make no changes to the payload.

   5. The DNS server for external.com replies with the host name
      of "X.External.Com.". This reply also transits the NAT. NAT would
      translate the IP and UDP headers of the incoming packet to
      reflect DNS server's private address. Once again, no changes
      to the payload by DNS_ALG.

   6. The DNS server in Private.com replies to host A.

   Note, DNS_ALG does not change the payload in either direction.

5.3. Incoming Name-lookup queries

   This time, host X in external.com wishes to initiate a session with
   host A in Private.com. Below are the sequence of events that take
   place.

   1. Host X sends a UDP based name lookup query  (A record) for
      "A.Private.com" to its local DNS server.

   2. Local DNS server in External.com sends the query to root server.

   3. The root server, in turn, refers the DNS server in External.com
      to query the DNS server for private.com,

   4. External.com DNS server will now send the query to the DNS server
      for Private.com. This query traverses the NAT router. NAT would
      change the IP and UDP headers of the packet to reflect the DNS
      server's private address. DNS_ALG will make no changes to the
      payload.

   5. The DNS server for Private.com replies with the IP address
      172.19.1.10 for host A.  This reply also transits the NAT. NAT
      would translate the IP and UDP headers of the outgoing packet
      from the DNS server.

      DNS_ALG will request NAT to assign an external address to
      Host A(172.19.1.10) and initiate Assignment-holdout timer. When
      NAT successfully assigns an external address (say, 131.108.1.12),
      DNS_ALG would modify the payload to replace A's private address
      with its external assigned address and set the Cache timeout to 0.




Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 17]


Internet Draft            DNS extensions to NAT                July 1998


   6. The server in External.com replies to host X

   When Host X finds the address of Host A, X initiates a session with
   A, using a destination IP address of 131.108.1.12. This datagram and
   any others that follow in this session will be translated as usual
   by the NAT.

   Note, DNS_ALG changes only the response packets from the DNS server
   for Private domain.

5.4. Reverse name lookups originated from external domain

   This scenario builds on the previous case (section 5.3) by having
   host X in External.com perform a reverse name lookup on 131.108.1.12,
   which is host A's assigned external address. The following sequence
   of events take place.

   1. Host X sends a UDP based inverse name lookup query (PTR record)
      for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.

   2. Local DNS server in External.com sends the query to the root
      server.

   3. The root server, in turn, refers the local DNS server to query
      the DNS server for Private.com.

   4. External.com DNS server will now send the query to the DNS server
      for Private.com. This query traverses the NAT router. NAT would
      change the IP and UDP headers to reflect the DNS server's private
      address.

      DNS_ALG will enquire NAT for the private address associated
      with the external address of 131.108.1.12 and modify the payload,
      replacing 131.108.1.12 with the private address of 172.19.1.10.

   5. The DNS server for Private.com replies with the host name
      of "A.Private.Com.". This reply also transits the NAT. NAT would
      translate the IP and UDP headers of the incoming packet to
      reflect DNS server's private address.

      Once again, DNS_ALG will enquire NAT for the assigned external
      address associated with the private address of 172.19.1.10 and
      modify the payload, replacing 172.19.1.10 with the assigned
      external address of 131.108.1.12.

   6. The DNS server in External.com replies to host X.

   Note, DNS_ALG changes the query as well as response packets from DNS



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 18]


Internet Draft            DNS extensions to NAT                July 1998


   server for Private domain.

6. Illustration of DNS_ALG in conjunction with Twice-NAT

   The following diagram illustrates the operation of DNS_ALG in a
   Twice NAT router. As before, we will illustrate by walking through
   how name lookup and reverse name lookup queries are processed.

                                             .
                         ________________    .     External.com
                        (                )   .
                       (                  )  .   +-------------+
            +--+      (      Internet      )-.---|Border Router|
            |__|------ (                  )  .   +-------------+
           /____\       (________________)   .          |
            Root                 |           .          |
         DNS Server              |           .     ---------------
                         +---------------+   .       |         |
                         |Provider Router|   .     +--+       +--+
                         +---------------+   .     |__|       |__|
                                 |           .    /____\     /____\
                                 |           .  DNS Server   Host X
       External domain           |           .  171.68.1.1  171.68.10.1
     ............................|...............................
       Private domain            |
                                 |        Private.com
                                 |
                +-------------------------------------------+
                | Twice-NAT router with DNS_ALG             |
                |                                           |
                | Private addresses:  171.68/16             |
                | Assigned External addresses: 131.108.1/24 |
                |                                           |
                | External addresses:  171.68/16            |
                | Assigned Private addresses: 10/8          |
                +-------------------------------------------+
                              |      |
                      ----------    ----------
                        |                  |    DNS Server
                       +--+               +--+  Authoritative
                       |__|               |__|  for private.com
                      /____\             /____\
                      Host A           DNS Server
                   171.68.1.10        171.68.2.1
                                      (Mapped to 131.108.1.8)

    Figure 4: DNS-ALG operation in Twice-NAT setup




Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 19]


Internet Draft            DNS extensions to NAT                July 1998


   In this scenario, hosts in private.com were not numbered from the
   RFC1918 reserved 172.19/16 space, but rather were numbered with the
   globally-routable 171.68/16 network, the same as external.com.  Not
   only does private.com need translation service for its own host
   addresses, but it also needs translation service if any of those
   hosts are to be able to exchange datagrams with hosts in
   external.com. Twice-NAT accommodates the transition by translating
   the overlapping address space used in external.com with a unique
   address block (10/8) from RFC1918 address space. Routes are set up
   within the private domain to direct datagrams destined for the
   address block 10/8 through Twice-NAT device to the external global
   network space.

   Simplifications and assumptions made in section 5.0 will be valid
   here as well.

6.1. Outgoing Name-lookup queries

   Say, Host A in private.com needs to perform a name lookup for
   host X in external.com (host X has a FQDN of X.external.com),
   to find its address.  This would would proceed as follows.

   1. Host A sends a UDP based name lookup query (A record) for
      "X.External.Com" to its local DNS server.

   2. Local DNS server sends the query to the root server enroute
      NAT. NAT would change the IP and UDP headers to reflect DNS
      server's statically assigned external address.  DNS_ALG will
      make no changes to the payload.

   3. The root server, in turn, refers the local DNS server to query
      the DNS server for External.com. This referal transits the NAT
      enroute to the local DNS server.  NAT would  simply translate
      the IP and UDP headers of the incoming packet to reflect DNS
      server's private address.

      DNS_ALG will request NAT for an assigned private address for
      the referral server and replace the external address with its
      assigned private address in the payload.

   4. Private.com DNS server will now send the query to the DNS server
      for external.com, using its assigned private address, via NAT.
      This time, NAT would change the IP and UDP headers to reflect the
      External addresses of the DNS servers. I.e., Private.com DNS
      server's IP address is changed to its assigned external address
      and External.Com DNS server's assigned Private address is
      changed to its external address.




Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 20]


Internet Draft            DNS extensions to NAT                July 1998


      DNS_ALG will make no changes to the payload.

   5. The DNS server for external.com replies with the IP address
      171.68.10.1.  This reply also transits the NAT. NAT would
      once again translate the IP and UDP headers of the incoming
      to reflect the private addresses of the DNS servers.
      I.e., Private.com DNS server's IP address is changed to its
      private address and External.Com DNS server's external
      address is changed to its assigned Private address.

      DNS_ALG will request NAT to assign a private address to Host X
      (171.68.10.1) and initiate Assignment-holdout timer. When NAT
      successfully assigns an external address (say, 10.0.0.254),
      DNS_ALG would modify the payload to replace X's external address
      with its assigned private address and set the Cache timeout to 0.

   6. The DNS server in Private.com replies to host A.

   When Host A finds the address of Host X, A initiates a session with
   host X, using a destination IP address of 10.0.0.254. This datagram
   and any others that follow in this session will be translated as
   usual by Twice NAT.

   Note, the DNS_ALG has had to change payload in both directions.

6.2. Reverse name lookups originated from private domain

   This scenario builds on the previous case by having host A in
   Private.com perform a reverse name lookup on 10.0.0.254, which
   is host X's assigned private address. Following is a sequence
   of events.

   1. Host A sends a UDP based inverse name lookup query (PTR record)
      for "254.0.0.10.IN-ADDR.ARPA." to its local DNS server.

   2. Local DNS server sends the query to the root server enroute
      NAT. As before, NAT would change the IP and UDP headers to
      reflect DNS server's statically assigned external address.

      DNS_ALG will translate the private assigned address 10.0.0.254
      with its external address 171.68.10.1.

   3. The root server, in turn, refers the local DNS server to query
      the DNS server for External.com. This referal transits the NAT
      enroute to the local DNS server.  NAT would  simply translate
      the IP and UDP headers of the incoming packet to reflect DNS
      server's private address.




Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 21]


Internet Draft            DNS extensions to NAT                July 1998


      As with the original query, DNS_ALG will translate the private
      assigned address 10.0.0.254 with its external address
      171.68.10.1. In addition, DNS_ALG will replace the external
      address of the referal server (i.e., the DNS server for
      External.com) with its assigned private address in the payload.

   4. Private.com DNS server will now send the query to the DNS server
      for external.com, using its statically assigned private address,
      via NAT. This time, NAT would change the IP and UDP headers to
      reflect the External addresses of the DNS servers. I.e.,
      Private.com DNS server's IP address is changed to its assigned
      external address and External.Com DNS server's assigned Private
      address is changed to its external address.

      As with the original query, DNS_ALG will translate the private
      assigned address 10.0.0.254 with its external address
      171.68.10.1.

   5. The DNS server for external.com replies with the FQDN of
      "X.External.Com.".  This reply also transits the NAT. NAT would
      once again translate the IP and UDP headers of the incoming
      to reflect the private addresses of the DNS servers.
      I.e., Private.com DNS server's IP address is changed to its
      private address and External.Com DNS server's external
      address is changed to its assigned Private address.

      Once again, DNS_ALG will translate the query section, replacing
      the external address 171.68.10.1 with its assigned private
      address of 10.0.0.254

   6. The DNS server in Private.com replies to host A.

   Note, the DNS_ALG has had to change payload in both directions.

6.3. Incoming Name-lookup queries

   This time, host X in external.com wishes to initiate a session with
   host A in Private.com. Below are the sequence of events that take
   place.

   1. Host X sends a UDP based name lookup query  (A record) for
      "A.Private.com" to its local DNS server.

   2. Local DNS server in External.com sends the query to root server.

   3. The root server, in turn, refers the DNS server in External.com
      to query the DNS server for private.com,




Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 22]


Internet Draft            DNS extensions to NAT                July 1998


   4. External.com DNS server will now send the query to the DNS server
      for Private.com. This query traverses the NAT router. NAT would
      change the IP and UDP headers to reflect the private addresses of
      the DNS servers. I.e., Private.com DNS server's IP address is
      changed to its  private address and External.Com DNS server's
      external address is changed to assigned Private address.

      DNS_ALG will make no changes to the payload.

   5. The DNS server for Private.com replies with the IP address
      171.68.1.10 for host A.  This reply also transits the NAT. NAT
      would once again translate the IP and UDP headers of the incoming
      to reflect the external addresses of the DNS servers.  I.e.,
      Private.com DNS server's IP address is changed to its
      assigned external address and External.Com DNS server's
      assigned private address is changed to its external address.

      DNS_ALG will request NAT to assign an external address to Host A
      (171.68.1.10) and initiate Assignment-holdout timer. When NAT
      successfully assigns an external address (say, 131.108.1.12),
      DNS_ALG would modify the payload to replace A's private address
      with its external assigned address and set the Cache timeout to 0.

   6. The server in External.com replies to host X

   When Host X finds the address of Host A, X initiates a session with
   A, using a destination IP address of 131.108.1.12. This datagram and
   any others that follow in this session will be translated as usual
   by the NAT.

   Note, DNS_ALG changes only the response packets from the DNS server
   for Private domain.

6.4. Reverse name lookups originated from external domain

   This scenario builds on the previous case (section 6.3) by having
   host X in External.com perform a reverse name lookup on 131.108.1.12,
   which is host A's assigned external address. The following sequence
   of events take place.

   1. Host X sends a UDP based inverse name lookup query (PTR record)
      for "12.1.108.131.IN-ADDR.ARPA." to its local DNS server.

   2. Local DNS server in External.com sends the query to the root
      server.

   3. The root server, in turn, refers the local DNS server to query
      the DNS server for Private.com.



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 23]


Internet Draft            DNS extensions to NAT                July 1998



   4. External.com DNS server will now send the query to the DNS server
      for Private.com. This query traverses the NAT router. NAT would
      change the IP and UDP headers to reflect the private addresses of
      the DNS servers. I.e., Private.com DNS server's IP address is
      changed to its  private address and External.Com DNS server's
      external address is changed to assigned Private address.

      DNS_ALG will enquire NAT for the private address associated
      with the external address of 131.108.1.12 and modify the payload,
      replacing 131.108.1.12 with the private address of 171.68.1.10.

   5. The DNS server for Private.com replies with the host name
      of "A.Private.Com.". This reply also transits the NAT. NAT would
      once again translate the IP and UDP headers of the incoming
      to reflect the external addresses of the DNS servers.  I.e.,
      Private.com DNS server's IP address is changed to its
      assigned external address and External.Com DNS server's
      assigned private address is changed to its external address.

      Once again, DNS_ALG will enquire NAT for the assigned external
      address associated with the private address of 172.19.1.10 and
      modify the payload, replacing 171.68.1.10 with the assigned
      external address of 131.108.1.12.

   6. The DNS server in External.com replies to host X.

   Note, DNS_ALG changes the query as well as response packets from DNS
   server for Private domain.

7. DNS-ALG limitations and Future Work

   NAT increases the probability of mis-addressing. For example,
   same local address may be bound to different public address at
   different times and vice versa. As a result, hosts that cache
   the name to address mapping for longer periods than the NAT
   router is configured to hold the map are likely to misaddress
   their sessions. Note, this is mainly an issue with bad host
   implementations and is not directly attributable to the
   mechanism described here.

   DNS_ALG cannot support secure DNS name servers in the private
   domain. I.e., an authoritative DNS name server in the DMZ cannot
   sign replies to queries that originate from the external world.
   Since the DNS server does not have a way to find where the queries
   come from (i.e., internal or external), it will most likely have
   to resort to the common denomination of today's "insecure" DNS.
   Secondly, an end-node that demands DNS replies to be signed will



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 24]


Internet Draft            DNS extensions to NAT                July 1998


   reject replies that have been tampered with by DNS_ALG. Both are
   serious limitations to DNS_ALG. Zone transfers between DNS-SEC
   servers  is also impacted the same way, if the transfer crosses
   routing realms.

   The good news, however, is that only end-nodes in DMZ pay the
   price for the above limitation in a traditional NAT (or, a
   bi-directional NAT), as external end-nodes may not access internal
   hosts due to DNS replies not being secure. However, for outgoing
   sessions (from private network) in a bi-directional NAT setup,
   the DNS queries can be signed and securely accepted by DMZ and
   other internal hosts since DNS_ALG does not intercept outgoing
   DNS queries and incoming replies. Lastly, zone transfers between
   DNS-SEC servers  within the same private network are not impacted.

   Clearly, if DNS-SEC were to become the norm in DNS servers and
   end-host resolvers, the scheme suggested in this document will
   not work.


8. Security considerations.

   DNS packets must not be encrypted in order for DNS_ALG to be able
   to perform payload modifications. Alternately, if packets must be
   encrypted in a routing realm, DNS_ALG will need to hold the
   secret key to decrypt payload before forwarding packets to a
   different realm. The preceding section, "DNS-ALG limitations and
   Future Work" has coverage on DNS_ALG security considerations.


REFERENCES

   [1] P. Srisuresh, M. Holdrege, "The IP  Network  Address
       Translator (NAT) terminology and considerations",
       <draft-ietf-nat-terminology-00.txt> - Work in progress,
       July 1998

   [2] K. Egevang, P. Francis, "The IP Network Address Translator
       (NAT)", RFC 1631.

   [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,
       Lear, E.  "Address Allocation for Private Internets",
       RFC 1918 or its successor.

   [4] P. Mockapetris, "Domain Names - Concepts and facilities",
       RFC 1034 or its successor.

   [5] P. Mockapetris, "Domain Names - Implementation and



Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 25]


Internet Draft            DNS extensions to NAT                July 1998


       Specification", RFC 1035 or its successor.

   [6] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 or
       its successor.

   [7] R. Braden, "Requirements for Internet Hosts -- Communication
       Layers", RFC 1122 or its successor.

   [8] R. Braden, "Requirements for Internet Hosts -- Application
       and Support", RFC 1123 or its successor.

   [9] F. Baker, "Requirements for IP Version 4 Routers",  RFC 1812
       or its successor.

   [10] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address
        Behaviour Today", RFC 2101 or its successor.

   [11] Donald E. Eastlake 3rd, "Domain Name System Security
        Extensions", <draft-ietf-dnssec-secext2-05.txt> - Work in
        progress, April 1998































Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 26]


Internet Draft            DNS extensions to NAT                July 1998


Authors' Addresses


   Pyda Srisuresh
   Lucent technologies
   Pleasanton, CA 94588-8519
   U.S.A.

   Phone: +1 (925) 737-2153
   Fax:   +1 (925) 737-2110
   e-mail: suresh@ra.lucent.com

   George Tsirtsis
   Internet Transport Group
   B29 Room 129
   BT Laboratories
   Martlesham Heath
   IPSWICH
   Suffolk IP5 3RE
   England

   Phone: +44 1473 640756
   Fax:   +44 1473 640709
   e-mail: george@gideon.bt.co.uk

   Praveen Akkiraju
   cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134  USA

   Phone:  +1 408 526-5066
   e-mail: spa@cisco.com

   Andy Heffernan
   cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134  USA

   Phone:  +1 408 526-8115
   e-mail: ahh@cisco.com











Srisuresh, Tsirtsis, Akkiraju & Heffernan                      [Page 27]