Network Working Group                                   W. Mark Townsley
Internet-Draft                                             cisco Systems
<draft-townsley-l3vpn-l2tpv3-01.txt>                           Ted Seely
January 2004                                                      Sprint


         BGP/MPLS IP VPNs over Layer 2 Tunneling Protocol ver 3


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 (2004). All Rights Reserved.

Abstract

   The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a
   protocol for tunneling a variety of payload types over IP networks.
   This document describes a variation of "BGP/MPLS IP VPNs" in which
   the outermost MPLS label of a VPN packet is replaced with an L2TPv3
   encapsulation, enabling the VPN packets to be carried over an IP
   network.







Townsley                    Standards Track                     [Page 1]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


   Contents

   Status of this Memo..........................................    1

   1. Introduction..............................................    2
      1.1 Terminology...........................................    3
      1.2 Overview..............................................    3

   2. MPLS over L2TPv3 Encapsulation............................    3
      2.1 Encapsulation by Ingress PE...........................    5
      2.2 Decapsulation by Egress PE............................    5

   3. Assigning the Session ID and Cookie.......................    5
      3.1 Distribution of the Session ID and Cookie via BGP.....    6

   4. Implications on Packet Spoofing...........................    6

   5. Applicability.............................................    7

   6. Security Considerations...................................    8

   7. IANA Considerations.......................................    9

   8. Acknowledgments...........................................   10

   9. References................................................   10
      9.1 Normative References..................................   10
      9.2 Informative References................................   10

   10. Contacts.................................................   11

Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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 [RFC2119].


1. Introduction

   The "BGP/MPLS IP VPNs" base specification described in [RFC2547]
   defines a particular style of Layer 3 Virtual Private Network (L3VPN)
   using MPLS label switched paths between Provider Edge (PE) routers.
   This document describes an extension to the [RFC2547] specification
   by defining procedures for providing the same style of L3VPN using
   L2TPv3/IP [L2TPV3] tunnels (rather than MPLS LSPs) as the



Townsley                    Standards Track                     [Page 2]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


   encapsulation between PE routers.

1.1 Terminology

   Terminology used in this document is defined in [PPVPN-TERMS] and not
   reiterated here. Terms relevant to this document include:

      Customer Edge device (CE)
      Provider Edge (PE)
      Virtual Private Network (VPN)
      Layer 3 VPN (L3VPN)
      BGP/MPLS IP VPN
      VPN Routing and Forwarding (VRF)

1.2 Overview

   In a BGP/MPLS IP VPN, when a PE router receives a packet from a CE
   router, it looks up the packet's destination IP address in a VPN
   Routing and Forwarding (VRF) table.  As a result of this lookup, it
   obtains an MPLS label stack, a data link header, and an output
   interface.  The label stack is prepended to the packet, the data link
   header is prepended to that, and the resulting frame is queued for
   the output interface.

   The "bottom label" [RFC3032] on the MPLS label stack is always a
   label which will not be seen until the packet reaches its point of
   egress from the network. This label represents a particular route
   within the packet's VPN and will be referred to in this document as a
   "VPN label."  The purpose of the upper labels is to cause the packet
   to be delivered to the router which understands the VPN label. Thus,
   a BGP/MPLS IP VPN may be constructed among any set of PEs for which
   the VPN label is carried intact.

   This document describes methods for carrying a VPN label among PEs
   via the MPLS over L2TPv3 encapsulation as described in [MPLS-L2TPV3].
   This enables a BPG/MPLS IP VPN which traditionally required an MPLS-
   enabled core network to utilize an L2TPv3 encapsulation over an IP
   network instead. An applicability section describing L2TPv3 in
   context with MPLS, GRE, IP, and IPsec is presented as well.

2. MPLS over L2TPv3 Encapsulation

   MPLS over L2TPv3 as defined in [MPLS-L2TPv3] allows the tunneling of
   an MPLS label stack [RFC3032] over an IP network via L2TPv3.  A
   BGP/MPLS IP VPN over L2TPv3 utilizes a single VPN label (MPLS bottom
   label) which is carried over the L2TPv3 encapsulation.  This is
   depicted in Figure 2.1 and 2.2.




Townsley                    Standards Track                     [Page 3]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


                        +-+-+-+-+-+-+-+-+-+-+
                        |        IP         |
                        +-+-+-+-+-+-+-+-+-+-+
                        |      L2TPv3       |
                        +-+-+-+-+-+-+-+-+-+-+
                        |     VPN Label     |
                        +-+-+-+-+-+-+-+-+-+-+
                        |  VPN Payload (IP) |
                        +-+-+-+-+-+-+-+-+-+-+

         Figure 2.1 BGP/MPLS IP VPN over L2TPv3/IP

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Session ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Cookie (optional, maximum 64 bits)...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          (VPN) Label                  | Exp |S|       TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2.2 MPLS VPN Label over L2TPv3 encapsulation

   Session ID

      The L2TPv3 Session ID is a 32-bit identifier field locally
      selected as a lookup key for the context of an L2TP Session.  An
      L2TP Session contains necessary context for processing a received
      L2TP packet. For the application described in this document, this
      includes whether the Cookie is present, the value it was assigned,
      and that a MPLS VPN label follows.

   Cookie

      The L2TPv3 Cookie field contains a variable length (maximum 64
      bits) value assigned by a cryptographically random [RFC1750]
      algorithm.

   VPN Label

      An MPLS label used to identify a route for a BGP/MPLS IP VPN.

   Please refer to [MPLS-L2TPv3] for other MPLS over L2TPv3/IP
   encapsulation specifics.



Townsley                    Standards Track                     [Page 4]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


2.1 Encapsulation by Ingress PE

   When a PE receives a packet from a CE, it looks up the packet's IP
   destination address in the VRF corresponding to that CE. This enables
   it to find an IP route within the VPN. This route will have an
   associated MPLS label (the VPN label) and BGP Next Hop with
   reachability information for the Next Hop in the form of a set of
   L2TPv3 tunnel parameters (IP Address, Session ID and Cookie). The VPN
   label, L2TPv3, and IP encapsulation headers are prepended to the
   packet.  The IP source address field of the encapsulation header will
   be an address of the ingress PE itself. The IP destination address
   field of the encapsulation header will contain the value of the
   associated BGP Next Hop attribute; this will be an IP address of the
   egress PE.

   As defined in [L2TPv3], the Ingress PE MUST support the ability to
   encapsulate a 32 and 64 bit Cookie, or no Cookie at all. The Egress
   PE (section 2.2) is always in control of the size and value of the
   cookie to be encapsulated by the Ingress PE by virtue of it
   advertising its own tunnel reachability information (section 3). In
   order to achieve the anti-spoofing benefits of the Cookie as
   described in section 4, a 64-bit Cookie MUST always be used.

2.2 Decapsulation by Egress PE

   Upon receipt of the L2TPv3 packet addressed to a local IP address at
   the PE, a context lookup on the Session ID returns the Cookie for
   validation and the type of payload that follows. If the Cookie does
   not match, the packet MUST be dropped and a counter incremented in
   order to detect the occurrence of received cookie mismatches (this
   MAY be a global counter for the PE).  If the type of payload is MPLS,
   then the packet is delivered to the routing function for MPLS
   switching.

   The Egress PE is in control of the size and value of the Cookie it
   will permit packets to be received and processed with. As such, it is
   not a protocol violation to always advertise a 64-bit cookie, or no
   cookie at all. In order to achieve the anti-spoofing benefits of the
   Cookie as described in section 4, a 64-bit Cookie MUST be used and
   MUST be the default configuration. A zero or 32-bit Cookie MAY be
   used to reduce the size of the tunnel encapsulation if there are
   other forms of authentication embedded with the packet at another
   layer (e.g., IPsec authentication).

3. Assigning the Session ID and Cookie

   A minimum of one L2TPv3 Session ID must be allocated per PE. This
   Session ID may be any 32-bit value, and may be manually configured or



Townsley                    Standards Track                     [Page 5]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


   distributed via a signaling protocol. The Session ID need not be
   different for all PEs within a VPN, thus a single "global" value MAY
   be used.

   The L2TPv3 Cookie MUST be selected via a cryptographically random
   algorithm [RFC1750] and distributed (either by configuration or a
   signaling protocol) to all PEs. The default size for the Cookie MUST
   be 64 bits. A 32 or 0 (not present) bit Cookie MAY be used if another
   form of packet authentication is present at another layer (e.g. IPsec
   authentication).  Unlike the Session ID, the Cookie SHOULD be
   different at each PE within a VPN.

3.1 Distribution of the Session ID and Cookie via BGP

   The combination of the PE IP address, L2TPv3 Session ID, and Cookie
   embody the necessary reachability information for a PE to participate
   in an RFC 2547 Style VPN over L2TPv3. BGP may be extended as defined
   in [NALAWADE] to distribute the L2TPv3 reachability information for
   the PE. The VPN label is distributed in BGP via the VPN-IPv4 address
   family as is typical for a BGP/MPLS IP VPN.

   The set of L2TPv3 tunnel parameters (IP address, Session ID and
   Cookie) MUST be able to be updated for a given PE at any time without
   disruption of the VPN service. This allows for on-demand or periodic
   update of reachability information.

4. Implications on Packet Spoofing

   Without the L2TPv3 Cookie, protection against spoofed VPN packets
   carried over IP requires having all the boundary routers perform
   filtering; either filtering out packets from "outside" which are
   addressed to PE routers, or filtering out packets from "outside"
   which have source addresses that belong "inside" and filtering on
   each PE all packets which have source addresses that belong
   "outside".  The maintenance of these filter lists can be management-
   intensive, and the their use at all border routers can affect the
   performance seen by all traffic entering the SP's network.

   Unlike boundary filters, the L2TPv3 Session ID and Cookie are
   selected and distributed automatically among participating PEs,
   requiring virtually no additional operational impact and no impact on
   the performance of border routers whatsoever. While the L2TPv3 Cookie
   does not provide cryptographic security protection, it does provide
   effective protection against "blind" spoofed packet insertion attacks
   on an SP network in a very efficient manner.

   A "blind" insertion attack is defined as a packet spoofing attack
   where:



Townsley                    Standards Track                     [Page 6]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


      The attacker has the ability to insert spoofed IP packets into the
      service provider core, circumventing edge filters at one or more
      locations.

      The attacker knows the address of one or more PEs participating in
      the VPN service, and can send spoofed packets to these addresses
      at will.

      The attacker does NOT have the ability to instantaneously sniff,
      reroute, or otherwise obtain legitimate data in transit between
      participating PE routers for use in a coordinated spoofing attack.

   The blind insertion attack is indicative of an attacker who is able
   to operate without much sophistication, particularly if armed with an
   automated tool populated with a few unscrupulously obtained
   parameters such as the VPN PE IP address(es) and vulnerable core
   entry points.  This type of attacker may have very good success in
   randomly guessing a valid MPLS VPN label for insertion into a
   customer VPN. For example, if 4096 unique VPN labels are being
   advertised by a given PE, the probability approaches one that random
   guessing would yield a valid result for as few as 256 attempts
   (2^20/4096 = 256). The more VPN labels advertised, the more likely
   one might guess a valid label which would end up being routed to the
   customer VPN.

   A 64-bit Cookie within L2TPv3 is a very significant barrier against a
   packet spoofing attack. Consider a PE which has been assigned two
   valid random cookies. All L2TPv3 traffic entering this PE must be
   stamped with the proper value in order to be accepted. Thus, the
   probability that a random guess would yield the correct value is
   2/2^64. Assuming the ability to guess at a rate of 10 Mpps, the
   probability approaches one that a correct value would be selected
   after 2^64 / 10*10^6 /2 seconds, or more than 29,000 years (note that
   the same calculation with a 32 bit Cookie yields 3 minutes 35
   seconds, thus a 64 bit key is recommended).  Further, if it is
   expected that the Cookie has become compromised, it may be re-
   advertised without affecting outstanding VPN labels or CE
   connectivity to the VPN.

5. Applicability

   The methods defined [MPLS-IP-GRE-L3VPN], [MPLS-IPSEC] and this
   document all describe methods for carrying MPLS over an IP network in
   support of an RFC 2547 Style VPN. Situations where L2TPv3 may be
   preferable include:

      L2TPv3 can provide protection against VPN packet spoofing in a
      very lightweight manner. [MPLS-IPSEC] provides cryptographic



Townsley                    Standards Track                     [Page 7]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


      protection against this and other potential vulnerabilities, but
      at greater operational and packet processing overhead (it should
      be noted here that L2TPv3 may be protected by IPsec as well given
      that it is a general mechanism for securing IP traffic). [MPLS-
      IP-GRE-L3VPN] does not provide any protection for packet insertion
      attacks beyond reliance upon core network boundary filtering.

   (The following two applicability statements are adopted from [MPLS-
   IP-GRE])

      If two routers are "adjacent" over an L2TPv3 tunnel that exists
      for some reason outside the scope of this document, and those two
      routers need to send MPLS packets over that adjacency.

      Implementation considerations may dictate the use of MPLS-in-
      L2TPv3.  For example, some hardware device might only be able to
      handle L2TPv3 encapsulations in its fastpath.

   In summary, L2TPv3 can provide a balance between the limited security
   against IP spoofing attacks offered by [MPLS-IP-GRE-L3VPN] vs. the
   greater overhead required by an [MPLS-IPSEC].  Further, an BGP/MPLS
   IP VPN over L2TPv3 may be faster in some hardware, particularly if it
   is already optimized to classify incoming L2TPv3 packets carrying IP
   framed in a variety of ways. That is, IP encapsulated by HDLC or
   Frame Relay over L2TPv3 may be considered not that far removed from
   IP encapsulated by an MPLS label carried over L2TPv3.

6. Security Considerations

   BGP/MPLS IP VPN security is discussed in detail in [MPLS-VPN-SEC].
   The analysis shows that BGP/MPLS IP VPN networks can be considered as
   secure as a more traditional layer-2 VPN network such as Frame Relay.
   Many of the properties discussed in this document are equivalent when
   a VPN label is carried over L2TPv3 or MPLS, in particular topics such
   as "Address space, Routing and Traffic Separation."  The security
   provided by L2TPv3 acts as an additional layer of protection among
   the participating PEs themselves.

   There are subtle differences when discussing resistance to packet
   spoofing attacks on an IP network vs. an MPLS network, as the core
   transport for the VPN packets plays a large role. In order for a
   BGP/MPLS IP VPN to be secure over an MPLS infrastructure, it is
   assumed in [MPLS-VPN-SEC] that it is impossible to insert spoofed
   MPLS packets into an MPLS core network since labeled packets should
   never be accepted from a CE. As long as this principle holds (i.e.,
   there is no physical tap by a hacker on the core of the network),
   there is no possibility of spoofing since packets cannot enter the
   network from outside in the first place.



Townsley                    Standards Track                     [Page 8]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


   In practice, an IP core network may be more vulnerable to spoofing
   attacks than an isolated MPLS core network as the various L3 ACLs
   necessary to filter traffic at the edge of the network can be more
   cumbersome to setup and maintain than simply dropping any MPLS
   labeled packet. Use of the L2TPv3 Cookie (as described in Section 4)
   provides an extra layer of anti-spoofing protection as long as the
   hacker does not have the ability to capture, decode, and utilize
   traffic on the core network in a coordinated replay attack (i.e., as
   above, there is no physical tap by a hacker on the core of the
   network).

   Thus, given the assumptions for an MPLS core network that no labeled
   packets may enter the core from an untrusted source, and the
   assumption for an IP core network that an untrusted source cannot
   sniff packets in transit for use in a coordinated attack, the
   security of a BGP/MPLS VPN over L2TPv3 with an IP core is effectively
   equivalent to that of a BGP/MPLS IP VPN over an MPLS core.

   It is very important for the security of the anti-spoofing mechanism
   of L2TPv3 that the Cookie be selected in a truly random manner, and
   that a series of cookies not be predictable. It should be assumed
   that a hacker has access to similar hardware and software for
   examining a series of assigned Cookie values for a given
   implementation. The precise algorithm for Cookie selection is not
   defined in this document, though [RFC1750] provides guidelines that
   should be followed for the selection of an algorithm.

   The cryptographic protection of IPsec provides greater security than
   the methods described in this document or that of an MPLS core
   network as it does not rely on the assumption that a hacker does not
   have privileged access to traffic in the network core. If an IP or
   MPLS core network is subject to packet sniffing such that traffic in
   transit between PEs may be used in a coordinated spoofing attack
   across core network boundaries, then MPLS over IPsec is necessary to
   provide true security against these types of attacks. Since IPsec may
   be used to secure any type of host-to-host IP traffic, it can be used
   to secure MPLS/L2TPv3 traffic by setting up the proper IPsec policies
   to match L2TPv3 traffic between participating PEs or to secure MPLS
   over GRE or MPLS over IP as described in [MPLS-IPsec].


7. IANA Considerations

   This document creates a no new requirements on IANA namespaces
   [RFC2434].






Townsley                    Standards Track                     [Page 9]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


8. Acknowledgments

   Portions of text in this document was borrowed or adapted from
   [MPLS-IP-GRE-L3VPN]. Thanks to Dave Meyer and Michael Behringer for
   review, comments and suggestions.

9. References

9.1 Normative References

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

   [L2TPv3]      J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
                 Protocol (Version 3)", work in progress,
                 draft-ietf-l2tpext-l2tp-base-14.txt, June 2004.

   [MPLS-L2TPv3] M. Townsley, "Encapsulation of MPLS over Layer 2
                 Tunneling Protocol Version 3", draft-townsley-l2tpv3-mpls-02.txt
                 October 2004

9.2 Informative References

   [RFC1750]     D. Eastlake III, S. Crocker, J. Schiller, "Randomness
                 Recommendations for Security", RFC 1750, December 1994

   [RFC2547]     E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.

   [RFC3032]     R. Rosen, et. al., "MPLS Label Stack Encoding," RFC 3032,
                 January 2001.

   [NALAWADE]    G. Nalawade, R. Kapoor, D. Tappan, "IPv4-Tunnel SAFI",
                 work in progress, draft-nalawade-kapoor-tunnel-safi-01.txt,
                 October 2003.

   [MPLS-IPSEC]  E. Rosen, J. De Clercq, O/ Paridaens, Y. T'Joens,
                 C. Sargor, "Use of PE-PE IPsec in RFC2547 VPNs",
                 work in progress, draft-ietf-l3vpn-ipsec-2547-01.txt,
                 August 2003.

   [PPVPN-TERMS] L. Andersson, T. Madsen, "PPVPN terminology",
                 work in progress, draft-andersson-ppvpn-terminology-04.txt,
                 September 2003.

   [MPLS-IP-GRE] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating
                 MPLS in IP or Generic Routing Encapsulation (GRE)",
                 work in progress, draft-ietf-mpls-in-ip-or-gre-08.txt,
                 June 2004.



Townsley                    Standards Track                    [Page 10]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


   [MPLS-VPN-SEC] M. Behringer, "Analysis of the Security of BGP/MPLS IP VPNs,"
                  work in progress, draft-behringer-mpls-security-05.txt,
                  November 2003.

   [MPLS-IP-GRE-L3VPN] Y. Rekhter, E. Rosen, "Use of PE-PE GRE or IP in
                  RFC2547 VPNs", work in progress, draft-ietf-l3vpn-gre-ip-2547-00.txt
                  April 2003.

10. Contacts

   W. Mark Townsley
   cisco Systems
   7025 Kit Creek Road
   Research Triangle Park, NC 27709
   mark@townsley.net
   Ted Seely Sprint tseely@sprint.net



   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.

   Disclaimer of Validity

      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



Townsley                    Standards Track                    [Page 11]


INTERNET DRAFT        BGP/MPLS IP VPN over L2TPv3           October 2004


      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.

   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.

   Acknowledgment

      Funding for the RFC Editor function is currently provided by the
      Internet Society.




































Townsley                    Standards Track                    [Page 12]