[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 draft-durand-softwire-dual-stack-lite

Internet Engineering Task Force                                 R. Droms
Internet-Draft                                                     Cisco
Intended status: Informational                               B. Haberman
Expires: August 21, 2008                               February 18, 2008


              Softwires Network Address Translation (SNAT)
                   draft-droms-softwires-snat-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   Service providers (ISPs) are interested in reducing the use of IPv4
   in their internal networks because of the anticipated exhaustion of
   the IPv4 address space.  Softwires Network Address Translation (SNAT)
   combines IPv4 NAT and IPv4-in-IPv6 softwires to carry IPv4 traffic
   through the ISP network that uses only IPv6 service.  Multiple
   subscribers are multiplexed through a single external global IPv4
   address, reducing the total number of IPv4 addresses in use by the
   ISP to support Internet traffic to those subscribers.



Droms & Haberman         Expires August 21, 2008                [Page 1]


Internet-Draft    Softwires Network Address Translation    February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Problem statement and requirements . . . . . . . . . . . . . .  4
   5.  SNAT Architecture  . . . . . . . . . . . . . . . . . . . . . .  4
   6.  Example message flow . . . . . . . . . . . . . . . . . . . . .  6
   7.  Translation details  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Supporting multiple subscribers through one IPv4 address . . . 11
   9.  Setting up state . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Tunnel Endpoint Discovery  . . . . . . . . . . . . . . . . . . 12
   11. Analysis and Future Work . . . . . . . . . . . . . . . . . . . 13
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 13
     14.2.  Informative References  . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15































Droms & Haberman         Expires August 21, 2008                [Page 2]


Internet-Draft    Softwires Network Address Translation    February 2008


1.  Introduction

   Service providers (ISPs) are interested in reducing the use of IPv4
   in their internal networks because of the anticipated exhaustion of
   the IPv4 address space.  Reducing the use of IPv4 addresses will
   allow the conservation of addresses assigned to the ISP for use in
   specific places where IPv4 is required.  One way of reducing the use
   of IPv4 addresses to deploy IPv6 in internal networks to reduce the
   use of IPv4 through the use of only IPv6-IPv6 traffic.

   Softwires Network Address Translation (SNAT) combines IPv4 NAT
   [RFC3022] and IPv4-in-IPv6 softwires [RFC4925] to carry IPv4 traffic
   through the ISP network while using only IPv6 traffic.  Multiple
   subscribers are multiplexed through a single IPv4 address, reducing
   the total number of IPv4 addressesn in use by the ISP to support
   Internet traffic to those subscribers.

   Elements of SNAT are inspired by the proposal from NTT to deploy dual
   IPv4 NAT and the proposal from Comcast to use IPv4-IPv6-IPv4
   translation.  SNAT retains the characteristics of IPv4-IPV4 NAT,
   rather than introducing IPv4-IPV6 translation, while saving IPv4
   addresses in the ISP core network.  This document has been submitted
   to foster discussion about these mechanisms for IPv4 address space
   conservation.

   SNAT requires one IPv4-in-IPv6 softwire per subscriber.  These
   softwires will require configuration and special effort for
   reliability, as well as resources for scaling at the ISP endpoint for
   potentially hundreds or thousands of softwires.  SNAT also requires
   additional functions in subscriber CPEs.


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  Terminology

   This document uses the following terms:

   HGW:  Home gateway; the gateway beteen the subscriber network and the
      ISP network






Droms & Haberman         Expires August 21, 2008                [Page 3]


Internet-Draft    Softwires Network Address Translation    February 2008


   SPSWE:  Service provider softwire endpoint; the endpoint of the
      softwires in the ISP network

   This document also uses softwires terminology described in RFC 4925
   [RFC4925].


4.  Problem statement and requirements

   The motivation for SNAT is to reduce the number of IPv4 addresses in
   use in an ISP network.  The reduction is achieved in two ways:

   o  Use NAT to multiplex subscribers through a single global IPv4
      address

   o  Use softwires to provide IPv4 service through an ISP core network
      that uses only IPv6 addresses

   The following requirements were considered in the design of SNAT:

   o  Provide IPv4 service to CPE through NAT similar to familiar NAT in
      use today

   o  Minimize the use of global IPv4 addresses for subscriber IPv4
      service

   o  Eliminate the use of IPv4 addresses (global or RFC 1918) within
      the ISP as much as possible

   o  No changes to subscriber CPEs (hosts attached to the subscribe
      network)


5.  SNAT Architecture

   As illustrated in Figure 1, SNAT consists of three components: the
   subscriber home gateway (HGW), the service provider softwire endpoint
   (SPSWE) and a softwire between the SI in the HGW and the SC in the
   SPSWE.  The HGW and SPSWE perform IPv4-IPv4 NAT translations that
   constitute a "distributed" NAT, as the translation uses 0.0.0.0 for
   translated addresses in the IPv4 datagrams carried in the softwire.
   IPv4-IPv4 translation is completed by utilizing the softwire endpoint
   as the IPv4 address identifier.








Droms & Haberman         Expires August 21, 2008                [Page 4]


Internet-Draft    Softwires Network Address Translation    February 2008


                   +-----------+
                   |    CPE    |
                   +-----+-----+
                         |10.0.0.1
                         |
                         |
                         |10.0.0.2
               +---------|---------+
               |       +-+-+       |
               |HGW    |NAT|       |
               |+--------+--------+|
               ||     SNAT SI     ||
               |+--------+--------+|
               +--------|||--------+
                        |||2001:0:0:1::1
                        |||
                        |||<-IPv4-in-IPv6 softwire
                        |||
                 -------|||-------
               /        |||        \
              |   ISP core network  |
               \        |||        /
                 -------|||-------
                        |||
                        |||2001:0:0:2::1
               +--------|||--------+
               |SPSWE   |||        |
               |+--------+--------+|
               ||     SNAT SC     ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                         |129.0.0.1
                         |
                 --------|--------
               /         |         \
              |       Internet      |
               \         |         /
                 --------|--------
                         |
                         |128.0.0.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                        Figure 1: SNAT Architecture




Droms & Haberman         Expires August 21, 2008                [Page 5]


Internet-Draft    Softwires Network Address Translation    February 2008


   The resulting solution accepts an IPv4 datagram that is translated
   into an IPv4-in-IPv6 softwire datagram for transmission across the
   softwire.  At the corresponding endpoint, the IPv4 datagram is
   decapsulated, and the translated IPv4 address is inserted based on a
   translation from the softwire.


6.  Example message flow

   In the example shown in Figure 2, the translation tables are
   configured in the HGW and SPTE to forward between IP/TCP (10.0.0.1/
   10000) and IP/TCP (129.0.0.1/5000).  That is, a datagram received by
   the HGW from the CPE at address 10.0.0.1, using TCP DST port 10000
   will be translated a datagram with IP SRC address 129.0.0.1 and TCP
   SRC port 5000 in the Internet.




































Droms & Haberman         Expires August 21, 2008                [Page 6]


Internet-Draft    Softwires Network Address Translation    February 2008


                   +-----------+
                   |    CPE    |
                   +-----+-----+
                      |  |10.0.0.1
      IPv4 datagram 1 |  |
                      |  |
                      v  |10.0.0.2
               +---------|---------+
               |       +-+-+       |
               |HGW    |NAT|       |
               |+--------+--------+|
               ||     SNAT SI     ||
               |+--------+--------+|
               +--------|||--------+
                      | |||2001:0:0:1::1
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6 softwire
                      | |||
                 -----|-|||-------
               /      | |||        \
              |   ISP core network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||2001:0:0:2::1
               +------|-|||--------+
               |SPSWE v |||        |
               |+--------+--------+|
               ||     SNAT SC     ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                      |  |129.0.0.1
      IPv4 datagram 3 |  |
                 -----|--|--------
               /      |  |         \
              |       Internet      |
               \      |  |         /
                 -----|--|--------
                      |  |
                      v  |128.0.0.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                        Figure 2: Outbound Datagram




Droms & Haberman         Expires August 21, 2008                [Page 7]


Internet-Draft    Softwires Network Address Translation    February 2008


            +-----------------+--------------+---------------+
            |        Datagram | Header field | Contents      |
            +-----------------+--------------+---------------+
            | IPv4 datagram 1 |     IPv4 Dst | 128.0.0.1     |
            |                 |     IPv4 Src | 10.0.0.1      |
            |                 |      TCP Dst | 80            |
            |                 |      TCP Src | 10000         |
            | --------------- | ------------ | ------------- |
            | IPv6 Datagram 2 |     IPv6 Dst | 2001:0:0:2::2 |
            |                 |     IPv6 Src | 2001:0:0:1::1 |
            |                 |     IPv4 Dst | 128.0.0.1     |
            |                 |       IP Src | 0.0.0.0       |
            |                 |      TCP Dst | 80            |
            |                 |      TCP Src | 2000          |
            | --------------- | ------------ | ------------- |
            | IPv4 datagram 2 |     IPv4 Dst | 128.0.0.1     |
            |                 |     IPv4 Src | 129.0.0.1     |
            |                 |      TCP Dst | 80            |
            |                 |      TCP Src | 5000          |
            +-----------------+--------------+---------------+

                         Datagram header contents

   The translation is split between the HGW and the SPSWE, and the
   datagram is carried in the IPv4-in-IPv6 softwire between the HGW and
   SPSWE.  When the original datagram is received by the HGW, the HGW
   consults its translation table and, based on the IP/TCP source
   address/port pair, translates the TCP DST port to 2000.  The HGW also
   sets the IP SRC address to 0.0.0.0, and hands the datagram to the SI
   for transmission to the SC in the SPSWE.

   When it receives the outbound datagram, the SC in the SPSWE hands the
   IPv4 datagram to the NAT, which determines from its translation table
   that the datagram received on Softwire_1 with TCP SRC port 2000
   should be translated to an IPv4 datagram with IP SRC address
   129.0.0.1 and TCP SRC port 5000.

   Figure 3 shows an inbound message received at the SPSWE.  When the
   SPSWE receives an IPv4 datagram, it looks up the IP/TCP DST in its
   translation table.  In the example in Figure 3, the SPSWE translates
   the TCP DST port to 2000, sets the IP DST address to 0.0.0.0 and
   hands the datagram to the SC for transmission over Softwire_1.  The
   SI in the HGW decapsulates IPv4 datagram from the inbound softwire
   datagram, and then the NAT in the HGW translates the datagram
   received from Softwire_1 and TCP DST port 2000 to an IPv4 datagram
   with TCP/TCP DST (10.0.0.1/10000).





Droms & Haberman         Expires August 21, 2008                [Page 8]


Internet-Draft    Softwires Network Address Translation    February 2008


                   +-----------+
                   |    CPE    |
                   +-----+-----+
                      ^  |10.0.0.1
      IPv4 datagram 3 |  |
                      |  |
                      |  |10.0.0.2
               +---------|---------+
               |       +-+-+       |
               |HGW    |NAT|       |
               |+--------+--------+|
               ||     SNAT SI     ||
               |+--------+--------+|
               +--------|||--------+
                      ^ |||2001:0:0:1::1
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6 softwire
                      | |||
                 -----|-|||-------
               /      | |||        \
              |   ISP core network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||2001:0:0:2::1
               +------|-|||--------+
               |SPSWE  | |||        |
               |+--------+--------+|
               ||     SNAT SC     ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                      ^  |129.0.0.1
      IPv4 datagram 1 |  |
                 -----|--|--------
               /      |  |         \
              |       Internet      |
               \      |  |         /
                 -----|--|--------
                      |  |
                      |  |128.0.0.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                              The postamble.




Droms & Haberman         Expires August 21, 2008                [Page 9]


Internet-Draft    Softwires Network Address Translation    February 2008


                        Figure 3: Inbound Datagram

            +-----------------+--------------+---------------+
            |        Datagram | Header field | Contents      |
            +-----------------+--------------+---------------+
            | IPv4 datagram 1 |     IPv4 Dst | 129.0.0.1     |
            |                 |     IPv4 Src | 128.0.0.1     |
            |                 |      TCP Dst | 5000          |
            |                 |      TCP Src | 80            |
            | --------------- | ------------ | ------------- |
            | IPv6 Datagram 2 |     IPv6 Dst | 2001:0:0:1::1 |
            |                 |     IPv6 Src | 2001:0:0:2::2 |
            |                 |     IPv4 Dst | 0.0.0.0       |
            |                 |       IP Src | 128.0.0.1     |
            |                 |      TCP Dst | 2000          |
            |                 |      TCP Src | 80            |
            | --------------- | ------------ | ------------- |
            | IPv4 datagram 2 |     IPv4 Dst | 10.0.0.1      |
            |                 |     IPv4 Src | 128.0.0.1     |
            |                 |      TCP Dst | 10000         |
            |                 |      TCP Src | 80            |
            +-----------------+--------------+---------------+

                         Datagram header contents


7.  Translation details

   The HGW and the SPSWE each has a NAT that translates between
   softwire/port pairs and IPv4-address/port pairs.  The same
   translation is applied to IPv4 datagrams received on the device's
   external interface and from the softwire endpointin the device.

   In Figure 2, the translator network interface in the SPSWE is on the
   Internet, and the softwire interface connects to the HGW.  The SPSWE
   translator is configured as follows:

   Network interface:  Translate IPv4 destination address and TCP
      destination port to the softwire identifier and TCP destination
      port

   Softwire interface:  Translate softwire identifier and TCP source
      port to IPv4 source address and TCP source port

   The HGW is configured similarly; note that because the HGW will
   typically be connected to a single softwire, the softwire endpoint
   translations will be trivial:




Droms & Haberman         Expires August 21, 2008               [Page 10]


Internet-Draft    Softwires Network Address Translation    February 2008


   Network interface:  Translate IPv4 source address and TCP source port
      to softwire identifier and TCP source port

   Softwire interface:  Translate softwire identifier and TCP
      destination port to IPv4 destination address and TCP destination
      port

   Here is how the translations in Figure 3 work:

   o  Example datagram is received on the SPSWE translator network
      interface.  The translator looks up the IPv4-address/port pair in
      its translator table, rewrites the IPv4 destination address to
      0.0.0.0 and the TCP source port to 2000, and hands the datagram to
      the SI.

   o  Translated datagram is received on the HGW SI and is handed to the
      NAT in the HGW.  The NAT function looks up the softwire/port pair,
      translates the IPv4 destination address to 10.0.0.1 and TCP
      destination port to 10000, and forwards the translated IPv4
      datagram to the CPE.

                        The translation tables are:

               +---------------------+--------------------+
               |       Softwire/Port | IPv4/Port          |
               +---------------------+--------------------+
               | Softwire_1/TCP 2000 | 10.0.0.1/TCP 10000 |
               +---------------------+--------------------+

                           HGW translation table

               +---------------------+--------------------+
               |       Softwire/Port | IPv4/Port          |
               +---------------------+--------------------+
               | Softwire_1/TCP 2000 | 129.0.0.1/TCP 5000 |
               +---------------------+--------------------+

                          SPSWE translation table


8.  Supporting multiple subscribers through one IPv4 address

   One key advantage of SNAT is the ability to provide Internet access
   for multiple subscribers through a single global IPv4 address.  The
   SPTE table can be configured to translate traffic from multiple
   customers through one global IPv4 address.  Even a small degree of
   multiplexing, as few as five subscribers through each global IPv4
   address, would give ISPs sufficient IPv4 address space to continue



Droms & Haberman         Expires August 21, 2008               [Page 11]


Internet-Draft    Softwires Network Address Translation    February 2008


   and grow operations until IPv6 is more fully deployed.


9.  Setting up state

   The translation tables in the HGW and SPSWE are set up dynamically by
   outbound traffic from a CPE.  When the HGW receives the initial
   datagram in a new flow, there will be no corresponding IPv4-address/
   port pair for that flow in the HGW translation table.  The HGW
   selects an unused outbound TCP port, adds the resulting mapping to
   the HGW translation table, performs the appropriate translation and
   encapsulation on the datagram and forwards it through the IPv4-in-
   IPv6 softwire to the SPSWE.

   Similarly, the SPSWE has no softwire/port pair for the datagram in
   its translation table.  The SPSWE selects an outbound IPv4-address/
   port pair and adds the resulting mapping to the SPSWE translation
   table.  The SPSWE then decapsulates the original datagram, translates
   the IPv4-address/port pair and forwards the datagram to its
   destination.

   The resulting table entries are now in place for translation of
   returning inbound traffic.

   The translation tables can also be configured manually, which would
   allow, for example, traffic to be forwarded to servers on subscriber
   networks.  However, because multiple subscribers may be supported
   through a single IPv4 address, only one of those subscribers would be
   able to have statically assigned external server address through the
   NAT/softwire.


10.  Tunnel Endpoint Discovery

   Given the size of many service provider networks, it is beneficial to
   allow multiple SPSWEs in the same network and a way to load balance
   the their use.  One way of providing this functionality is to allow
   the use of anycast for SPSWE discovery and tunnel set up.

   The approach used to discover and bind with a SPSWE is based on the
   Mobile IPv6 model defined in RFC 3775 [RFC3775].  The service
   provider allocates an anycast address to be associated with the SPSWE
   service.  This anycast address is then associated with a set of SPSWE
   devices as its Care-of Address.  Each SPSWE device maintains an IPv6
   unicast address as its Home Address.  When a HG first initializes, it
   does not have any encapsulation state.  It will know (either through
   static or dynamic configuration) of the SPSWE anycast address.  When
   SNAT service is needed, the HG initiates a connection to the SPSWE



Droms & Haberman         Expires August 21, 2008               [Page 12]


Internet-Draft    Softwires Network Address Translation    February 2008


   anycast address.  The Mobile IPv6 return routability procedure is
   used between the SPSWE and the HG to associate the encapsulation
   state with the SPSWE's unicast address rather than the anycast
   address.

   Tunnel endpoint discovery can be further enhanced through the use of
   the methods described in the expired draft
   draft-haberman-ipv6-anycast-rr-00.txt.


11.  Analysis and Future Work

   There are several opportunities for future work on SNAT:

   o  SNAT requires an IPv4-in-IPv6 softwire for each subscriber, and
      NAT for each flow from the subscriber.  What are the effects of
      scaling this architecture to milliions of subscribers?

   o  The distribution of NAT between the CPE and the SPSWE requires
      coordination of translation state between the two endpoints.  Is
      it feasible to set up, maintain and tear down the required state?

   o  Security issues have not been considered

   o  How can the configuration of the IPv4-in-IPv6 softwire be
      automated?

   o  What is the interaction between SNAT ant native IPv6 service to
      the subscriber?


12.  IANA Considerations

   This memo includes no request to IANA.


13.  Security Considerations

   Security considerations must be developed.


14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Droms & Haberman         Expires August 21, 2008               [Page 13]


Internet-Draft    Softwires Network Address Translation    February 2008


   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

14.2.  Informative References

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC4925]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
              Problem Statement", RFC 4925, July 2007.


Authors' Addresses

   Ralph Droms
   Cisco
   1414 Massachusetts Avenue
   Boxborough, MA  01714
   US

   Phone: +1 978.936.1674
   Email: rdroms@cisco.com


   Brian Haberman
   11100 Johns Hopkins Road
   Laurel, MD  20723-6099
   US

   Phone: +1 443 778 1319
   Email: brian@innovationslab.net



















Droms & Haberman         Expires August 21, 2008               [Page 14]


Internet-Draft    Softwires Network Address Translation    February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Droms & Haberman         Expires August 21, 2008               [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/