Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4031

Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)

Pages: 50
Informational
Part 3 of 3 – Pages 36 to 50
First   Prev   None

Top   ToC   RFC4031 - Page 36   prevText

7. Service Provider Management Requirements

A service provider MUST have a means to view the topology, operational state, order status, and other parameters associated with each customer's VPN. Furthermore, an SP MUST have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) to its customers. Currently, proprietary methods are often used to manage VPNs. The additional expense associated with operators using multiple proprietary management methods (e.g., command line interface (CLI) languages) to access such systems is undesirable. Therefore, devices SHOULD provide standards-based interfaces wherever feasible. The remainder of this section presents detailed SP management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories. Much of this text was adapted from ITU-T Y.1311.1.
Top   ToC   RFC4031 - Page 37

7.1. Fault Management

Support for fault management includes: - indication of customers impacted by failure, - fault detection (incidents reports, alarms and failure visualization), - fault localization (analysis of alarms reports and diagnostics), - incident recording or logs (creation and follow-through of trouble tickets), and - corrective actions (traffic, routing, and resource allocation). As PE-based VPNs rely on a common network infrastructure, the NMS MUST provide a means to inform the provider of the VPN customers impacted by a failure in the infrastructure. The NMS SHOULD provide pointers to the related customer configuration information to aid in fault isolation and determining corrective action. Detecting faults caused by configuration errors is desirable, because these may cause VPN service failure or may disrupt other requirements (e.g., traffic and routing isolation). This is a likely case of compromised security [VPNSEC]. Detection of such errors is inherently difficult because the problem involves more than one node and may reach across a global perspective. One approach could be a protocol that systematically checks whether all constraints and consistency checks hold among tunnel configuration parameters at the various end points. A capability to verify L3 reachability within a VPN MUST be provided for diagnostic purposes. A capability to verify the parameter configuration of a device supporting an L3VPN MUST be provided for diagnostic purposes.

7.2. Configuration Management

Overall, the NMS must support a configuration necessary to realize the desired L3-reachability of an L3VPN. Toward this end, an NMS MUST provide configuration management to provision at least the following L3VPN components: PE,CE, hierarchical tunnels, access connections, routing, and QoS, as detailed in this section. If shared access to the Internet is provided, then this option MUST also be configurable. As VPN configuration and topology are highly dependent on a customer's organization, provisioning systems MUST address a broad range of customer-specific requirements. The NMS MUST ensure that
Top   ToC   RFC4031 - Page 38
   these devices and protocols are provisioned consistently and
   correctly.

   Provisioning for adding or removing sites SHOULD be as localized and
   automated as possible.

   Configuration management for VPNs, according to service templates
   defined by the provider MUST be supported.  A service template
   contains fields that, when used, yield a definite service requirement
   or policy.  For example, a template for an IPSec tunnel would contain
   fields such as tunnel end points, authentication modes, encryption
   and authentication algorithms, pre-shared keys (if any), and traffic
   filters.  An SLA template would contain fields such as delay, jitter,
   and throughput and packet loss thresholds, as well as end points over
   which the SLA has to be satisfied.  In general, a customer's service
   order can be regarded as a set of instantiated service templates.
   This set can, in turn, be regarded as the logical service
   architecture of the customer's VPN.

   Service templates can also be used by the provider to define the
   service architecture of the provider's own network.  For example,
   OSPF templates could contain fields such as the subnets that form a
   particular area, the area identifier, and the area type.  BGP service
   template could contain fields that, when used, would yield a BGP
   policy, such as for expressing a preference about an exit router for
   a particular destination.

   The set of service templates SHOULD be comprehensive in that it can
   capture all service orders in some meaningful sense.

   The provider SHOULD provide means to translate service templates into
   device configurations so that associated services can be provisioned.

   Finally, the approach SHOULD provide means to check whether a service
   order is correctly provisioned.  This would represent one method of
   diagnosing configuration errors.  Configuration errors can arise due
   to a variety of reasons: manual configuration, intruder attacks, and
   conflicting service requirements.

7.2.1. Configuration Management for PE-Based VPNs

Requirements for configuration management unique to a PE-based VPN are as follows: o The NMS MUST support configuration of at least the following aspects of L3 PE routers: intranet and extranet membership, CE routing protocol for each access connection, routing metrics, and tunnels.
Top   ToC   RFC4031 - Page 39
   o  The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs,
      hierarchical tunnels, and access connections, as described in
      section 6.3.

   o  Tunnels MUST be configured between PE and P devices.  This
      requires coordination of identifiers of tunnels, hierarchical
      tunnels, VPNs, and any associated service information, for
      example, a QoS/SLA service.

   o  Routing protocols running between PE routers and CE devices MUST
      be configured per VPN.

   o  For multicast service, multicast routing protocols MUST also be
      configurable.

   o  Routing protocols running between PE routers and between PE and P
      routers MUST also be configured.

   o  The configuration of a PE-based L3VPN MUST be coordinated with the
      configuration of the underlying infrastructure, including Layer 1
      and 2 networks interconnecting components of an L3VPN.

7.2.2. Configuration Management for CE-Based VPN

Requirements for configuration management unique to a CE-based VPN are as follows: o Tunnels MUST be configured between CE devices. This requires coordination of identifiers of tunnels, VPNs, and any associated service information, for example, a QoS/SLA service. o Routing protocols running between PE routers and CE devices MUST be configured. For multicast service, multicast routing protocols MUST also be configurable.

7.2.3. Provisioning Routing

A means for a service provider to provision parameters for the IGP for an L3VPN MUST be provided. This includes link level metrics, capacity, QoS capability, and restoration parameters.

7.2.4. Provisioning Network Access

A service provider MUST have the means to provision network access between SP-managed PE and CE, as well as the case where the customer manages the CE.
Top   ToC   RFC4031 - Page 40

7.2.5. Provisioning Security Services

When a security service is requested, an SP MUST have the means to provision the entities and associated parameters involved with the service. For example, for IPsec service, tunnels, options, keys, and other parameters must be provisioned at either the CE or the PE. In the case of an intrusion detection service, the filtering and detection rules must be provisioned on a VPN basis.

7.2.6. Provisioning VPN Resource Parameters

A service provider MUST have a means to provision resources associated with VPN services dynamically. For example, in a PE-based service, the number and size of virtual switching and forwarding table instances must be provisionable. Dynamic VPN resource assignment is crucial for coping with the frequent change requests from customers (e.g., sites joining or leaving a VPN), as well as for achieving scalability. The PEs SHOULD be able to dynamically assign the VPN resources dynamically. This capability is especially important for dial and wireless VPN services. If an SP supports a "Dynamic Bandwidth management" service, then the provisioning system MUST be able to make requested changes within the ranges and bounds specified in the SLA. Examples of SLA parameters are response time and probability of being able to service such a request.

7.2.7. Provisioning Value-Added Service Access

An L3VPN service provides controlled access between a set of sites over a common backbone. However, many service providers also offer a range of value-added services. (for example, Internet access, firewall services, intrusion protection, IP telephony and IP Centrex, application hosting, and backup). It is outside of the scope of this document to define whether and how these different services interact with the VPN to solve issues such as addressing, integrity, and security. However, the VPN service MUST be able to provide access to these various types of value-added services. A VPN service SHOULD allow the SP to supply the customer with different kinds of standard IP services, such as DNS, NTP, and RADIUS, that are needed for ordinary network operation and management. The provider SHOULD be able to provide IP services to multiple VPN customers.
Top   ToC   RFC4031 - Page 41
   A firewall function MAY be required to restrict access to the L3VPN
   from the Internet [Y.1311].

   A managed firewall service MUST be carrier grade.  For redundancy and
   failure recovery, a means for firewall fail-over should be provided.
   Managed firewall services that may be provided include dropping
   specified protocol types, intrusion protection, and traffic-rate
   limiting against malicious attacks.

   Managed firewalls MUST be supported on a per-VPN basis, although
   multiple VPNs may be supported by the same physical device (e.g., in
   a PE-based solution).  Managed firewalls SHOULD be provided at the
   major access point(s) for the L3VPN.  Managed firewall services may
   be embedded in CE or PE device or implemented in standalone devices.

   The NMS SHOULD allow a customer to outsource the management of an IP
   networking service to the SP providing the VPN or to a third party.

   The NMS SHOULD support collection of information necessary for
   optimal allocation of IP services in response to customer orders.

   Reachability to and from the Internet to sites within a VPN MUST be
   configurable by an SP.  This could be controlled by configuring
   routing policy to control distribution of VPN routes advertised to
   the Internet.

7.2.8. Provisioning Hybrid VPN Services

Configuration of interworking or interconnection between L3VPN solutions SHOULD be also supported. Ensuring that security and end-to-end QoS issues are provided consistently SHOULD be addressed.

7.3. Accounting

Many service providers require collection of measurements regarding resource usage for accounting purposes. The NMS MAY need to correlate accounting information with performance and fault management information to produce billing that takes into account SLA provisions for periods of time when the SLS is not met. An L3VPN solution MUST describe how the following accounting functions can be provided: - Measurements of resource utilization. - collection of accounting information. - storage and administration of measurements.
Top   ToC   RFC4031 - Page 42
   Some providers may require near - real time reporting of measurement
   information and may offer this as part of a customer network
   management service.

   If an SP supports a "Dynamic Bandwidth management" service, then the
   dates, times, amounts, and interval required to perform requested
   bandwidth allocation change(s) MUST be traceable for monitoring and
   accounting purposes.

   Solutions should state compliance with accounting requirements, as
   described in section 1.7 of RFC 2975 [RFC2975].

7.4. Performance Management

Performance management MUST support functions involved with monitoring and collecting performance data for devices, facilities, and services, as well as determining conformance to SLS, such as QoS and availability measurements. Performance management SHOULD also support analysis of important aspects of an L3VPN, such as bandwidth utilization, response time, availability, QoS statistics, and trends based on collected data.

7.4.1. Performance Monitoring

The NMS MUST monitor device behavior to evaluate performance metrics associated with an SLA. Different measurement techniques may be necessary depending on the service for which an SLA is provided. Example services are QoS, security, multicast, and temporary access. These techniques MAY be either intrusive or non-intrusive depending on the parameters being monitored. The NMS MUST also monitor aspects of the VPN not directly associated with an SLA, such as resource utilization, state of devices, and transmission facilities, as well as control of monitoring resources such as probes and remote agents at network access points used by customers and mobile users.

7.4.2. SLA and QoS Management Features

The NMS SHOULD support SLAs between an SP and the various VPN customers according to the corresponding SLSes by measurement of the indicators defined within the context of the SLA, on a regular basis. The NMS SHOULD use the QoS parameter measurement definitions, techniques, and methods as defined by the IETF IP Performance Metrics (IPPM) working group for delay, loss, and delay variation.
Top   ToC   RFC4031 - Page 43
   The NMS SHOULD support allocation and measurement of end-to-end QoS
   requirements to QoS parameters for one or more VPN network(s).

   Devices supporting L3VPN SLAs SHOULD have real-time performance
   measurements that have indicators and threshold crossing alerts.
   Such thresholds should be configurable.

7.5. Security Management

The security management function of the NMS MUST include management features to guarantee the security of devices, access connections, and protocols within the L3VPN network(s), as well as the security of customer data and control as described in section 6.9.

7.5.1. Resource Access Control

Resource access control determines the privileges that a user has to access particular applications and VPN network resources. Without such control, only the security of the data and control traffic is protected, leaving the devices providing the L3VPN network unprotected. Access control capabilities protect these devices to ensure that users have access only to the resources and applications they are authorized to use. In particular, access to the routing and switching resources managed by the SP MUST be tightly controlled to prevent and/or effectively mitigate a malicious attack. More detailed requirements in this area are described in [VPNSEC].

7.5.2. Authentication

Authentication is the process of verifying that the sender is actually who he or she claims to be. The NMS MUST support standard methods for authenticating users attempting to access management services. Scalability is critical, as the number of nomadic/mobile clients is increasing rapidly. The authentication scheme implemented for such deployments MUST be manageable for large numbers of users and VPN access points. Strong authentication schemes SHALL be supported to ensure the security of both VPN access point-to-VPN access point (e.g., PE to PE in a PE-based case) and client-to-VPN access point (e.g., CE-to-PE in a PE-based case) communications. This is particularly important for preventing VPN access point spoofing, a situation where an attacker tries to convince a PE or CE that the attacker is the VPN access point. If an attacker can convince a PE or CE device of this,
Top   ToC   RFC4031 - Page 44
   then that device will send VPN traffic to the attacker (who could
   forward it to the true access point after compromising
   confidentiality or integrity).  In other words, a non-authenticated
   VPN AP can be spoofed with a man-in-the-middle attack, because the
   endpoints never verify each other.  A weakly authenticated VPN AP may
   be subject to such an attack.  Strongly authenticated VPN APs are not
   subject to such attacks, because the man-in-the-middle cannot be
   authenticated as the real AP due to the strong authentication
   algorithms.

7.6. Network Management Techniques

Each L3VPN solution approach MUST specify the management information bases (MIB) modules for the network elements involved in L3VPN services. This is an essential requirement in network provisioning. The approach SHOULD identify any information not contained in a standard MIB related to FCAPS that is necessary to meet a generic requirement. An IP VPN (Policy) Information model, when available, SHOULD reuse the policy information models being developed in parallel for specific IP network capabilities [IM-REQ]. This includes the QoS Policy Information Model [QPIM] and the IPSEC Configuration Policy Model [IPSECIM]. The IP VPN Information model SHOULD provide the OSS with adequate "hooks" to correlate service level specifications with traffic data collected from network elements. The use of policies includes rules that control corrective actions taken by OSS components responsible for monitoring the network and ensuring that it meets service requirements. Additional requirements on VPN information models are given in reference [IM-PPVPN]. In particular, an information model MUST allow an SP to change VPN network dimensions with minimal influence on provisioning issues. The adopted model SHOULD be applicable to both small/medium size and large-scale L3VPN scenarios. Some service providers MAY require systems that visually, audibly, or logically present FCAPS information to internal operators and/or customers.

8. Security Considerations

Security considerations occur at several levels and dimensions within L3VPNs, as detailed within this document. This section provides a summary with references to detailed supporting information [L3VPN-SEC] [VPNSEC].
Top   ToC   RFC4031 - Page 45
   The requirements in this document separate traditional notions of
   security requirements, such as integrity, confidentiality, and
   authentication, from issues such as isolating (or separating) the
   exchange of VPN data and control traffic between specific sets of
   sites (as defined in sections 3.3 and 4.1).  Further detail on
   security requirements is given from the customer and service provider
   perspectives in sections 5.9 and 6.9, respectively.  Further detail
   on data and control traffic isolation requirements are given from the
   customer and service provider perspectives in sections 5.1 and 6.8,
   respectively.

   Furthermore, requirements regarding management of security from a
   service provider perspective are described in section 7.5.

9. Acknowledgements

The authors of this document would like to acknowledge the contributions from the people who launched the work on VPN requirements inside ITU-T SG13 and the authors of the original IP VPN requirements and framework document [RFC2764], as well as Tom Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le Garrec. The authors are also grateful to the helpful suggestions and direction provided by the technical advisors, Alex Zinin, Scott Bradner, Bert Wijnen, and Rob Coltun. Finally, the authors wish to acknowledge the insights and requirements gleaned from the many documents listed in the references section. Citations to these documents were made only where the authors believed that additional insight could be obtained from reading the source document.

10. References

10.1. Normative References

[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
Top   ToC   RFC4031 - Page 46
   [RFC2211]     Wroclawski, J., "Specification of the Controlled-Load
                 Network Element Service", RFC 2211, September 1997.

   [RFC2212]     Shenker, S., Partridge, C., and R. Guerin,
                 "Specification of Guaranteed Quality of Service", RFC
                 2212, September 1997.

   [RFC2251]     Wahl, M., Howes, T., and S. Kille, "Lightweight
                 Directory Access Protocol (v3)", RFC 2251, December
                 1997.

   [RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                 Z., and W. Weiss, "An Architecture for Differentiated
                 Service", RFC 2475, December 1998.

   [RFC2597]     Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
                 "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC2661]     Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
                 G., and B. Palter, "Layer Two Tunneling Protocol
                 "L2TP"", RFC 2661, August 1999.

   [RFC2685]     Fox, B. and B. Gleeson, "Virtual Private Networks
                 Identifier", RFC 2685, September 1999.

   [RFC3246]     Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
                 Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
                 D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
                 Behavior)", RFC 3246, March 2002.

   [RFC3270]     Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                 Vaananen, P., Krishnan, R., Cheval, P., and J.
                 Heinanen, "Multi-Protocol Label Switching (MPLS)
                 Support of Differentiated Services", RFC 3270, May
                 2002.

   [RFC3809]     Nagarajan, A., "Generic Requirements for Provider
                 Provisioned Virtual Private Networks (PPVPN)", RFC
                 3809, June 2004.

10.2. Informative References

[2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", Work in Progress. [IM-PPVPN] Lago, P., et al., "An Information Model for Provider Provisioned Virtual Private Networks", Work in Progress.
Top   ToC   RFC4031 - Page 47
   [IM-REQ]      Iyer, M., et al., "Requirements for an IP VPN Policy
                 Information Model", Work in Progress.

   [IPSECIM]     Jason, J., "IPsec Configuration Policy Model", Work in
                 Progress.

   [CE-PPVPN]    De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, C.,
                 "An Architecture for Provider Provisioned CE-based
                 Virtual Private Networks using IPsec", Work in
                 Progress.

   [IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider Provisioned
                 VPNs", Work in Progress.

   [L2VPN]       Rosen, E., et al., "An Architecture for L2VPNs", Work
                 in Progress.

   [MPLSSEC]     Behringer, M., "Analysis of the Security of the MPLS
                 Architecture", Work in Progress.

   [PPVPN-TERM]  Andersson, L., Madsen, T., "PPVPN Terminology", Work in
                 Progress.

   [L3VPN-SEC]   Fang, L., et al., "Security Framework for Provider
                 Provisioned Virtual Private Networks", Work in
                 Progress.

   [L3VPN-FR]    Callon, R., Suzuki, M., et al. "A Framework for Layer 3
                 Provider Provisioned Virtual Private Networks", Work in
                 Progress.

   [PPVPN-VR]    Knight, P., Ould-Brahim, H., Gleeson, B., "Network
                 based IP VPN Architecture using Virtual Routers", Work
                 in Progress.

   [QPIM]        Snir, Ramberg, Strassner, Cohen and Moore, "Policy QoS
                 Information Model", Work in Progress.

   [RFC2385]     Heffernan, A., "Protection of BGP Sessions via the TCP
                 MD5 Signature Option", RFC 2385, August 1998.

   [RFC2764]     Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and
                 A. Malis, "A Framework for IP Based Virtual Private
                 Networks", RFC 2764, February 2000.

   [RFC2975]     Aboba, B., Arkko, J., and D. Harrington, "Introduction
                 to Accounting Management", RFC 2975, October 2000.
Top   ToC   RFC4031 - Page 48
   [RFC2983]     Black, D., "Differentiated Services and Tunnels", RFC
                 2983, October 2000.

   [RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
                 "Multiprotocol Label Switching Architecture", RFC 3031,
                 January 2001.

   [RFC3198]     Westerinen, A., Schnizlein, J., Strassner, J.,
                 Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
                 Carlson, M., Perry, J., and S. Waldbusser, "Terminology
                 for Policy-Based Management", RFC 3198, November 2001.

   [TE-INTERAS]  Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic
                 Engineering requirements", Work in Progress.

   [VPNDISC]     Squire, M. et al., "VPN Discovery Discussions and
                 Options", Work in Progress.

   [VPNIW]       Kurakami, H., et al., "Provider-Provisioned VPNs
                 Interworking", Work in Progress.

   [VPNSEC]      De Clercq, J., et al., "Considerations about possible
                 security extensions to BGP/MPLS VPN", Work in Progress.

   [VPNTUNNEL]   Worster, T., et al., "A PPVPN Layer Separation: VPN
                 Tunnels and Core Connectivity", Work in Progress.

   [VPN-CRIT]    Yu, J., Jou, L., Matthews, A ., Srinivasan, V.,
                 "Criteria for Evaluating VPN Implementation
                 Mechanisms", Work in Progress.

   [VPN-NEEDS]   Jacquenet, C., "Functional needs for the deployment of
                 an IP VPN service offering : a service provider
                 perspective", Work in Progress.

   [Y.1311.1]    Carugi, M. (editor), "Network Based IP VPN over MPLS
                 architecture", Y.1311.1 ITU-T Recommendation, July
                 2001.

   [Y.1311]      Knightson, K. (editor), "Network based VPNs  - Generic
                 Architecture and Service Requirements", Y.1311 ITU-T
                 Recommendation, March 2002.
Top   ToC   RFC4031 - Page 49

Authors' Addresses

Marco Carugi (co-editor) Nortel Networks Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE EMail: marco.carugi@nortel.com Dave McDysan (co-editor) MCI 22001 Loudoun County Parkway Ashburn, VA 20147, USA EMail: dave.mcdysan@mci.com Luyuan Fang AT&T 200 Laurel Ave - Room C2-3B35 Middletown, NJ 07748 USA EMail: Luyuanfang@att.com Ananth Nagarajan Juniper Networks EMail: ananth@juniper.net Junichi Sumimoto NTT Communications Corporation 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan EMail: j.sumimoto@ntt.com Rick Wilder Alcatel EMail: rick.wilder@alcatel.com
Top   ToC   RFC4031 - Page 50
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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.

Acknowledgement

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