Internet Engineering Task Force CY Lee
INTERNET DRAFT J DeClercq
Expires June 2003
November 2002
CE Auto-Configuration
<draft-lee-ppvpn-ce-auto-config-02.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This draft describes the mechanisms required to automatically
configure a Customer Edge (CE) Equipment to support a VPN service
offered by the provider (aka as Provider Provisioned CE-based VPN).
1. Motivation
To offer provider provisioned CE-based VPN [CE-VPN] ( or CE-based
Virtual Private LAN [CE-VPL]), a provider has to configure on a CE,
tunnel(s) to remote CE(s) of a VPN. In this document, the term VPN
includes VPL and the term CE includes CLE (Customer Located
Equipment)
In CE-based VPNs, if a site of a VPN is added or removed, other CE(s)
belonging to the VPN must be reprovisioned with the new or updated
tunnel endpoint. It is desirable to have a CE to be automatically
updated with the change in tunnel endpoints and for the CE to self-
provision a new tunnel to a remote site. This auto-discovery or
update and self-provisioning features on CE shall be referred to as
CE auto-configuration.
PP CE-based VPNs which do not require the provider to manually
perform configuration on the CEs reduces the cost of offering VPN
service. If CEs of a VPN are fully-meshed, using CE auto-
configuration instead of manually provisioning CEs, reduces the
provisioning required from O(n^2) to O(n), where n is the number of
sites.
2. Overview
Figure 1 below is based on Figure 1 from [CE-VPN] and shows the
reference model for auto-configuration of CEs for PP CE-based
VPN.
Customer | Provider's network | Customer
Site | | site
| +-------------+ |
| |VPN | |
| |Configuration| |
| |server | |
| +-------------+ |
| |
| edge edge |
| router router|
Customer ---CE1 ----PE1----- Backbone -----PE2-----CE2---- Customer
X's network | | X's network
| |
| |
| |
Figure 1: Reference model for auto-configuration of CEs
A VPN Configuration server is a server which can update CEs of tunnel
endpoint information or/and where CE may request tunnel endpoints
information.
3. VPN service parameters
The parameters that can be auto-configured at a CE device to allow a
CE to self provision tunnels include:
i) the list of remote CE IP address(es)
ii) the VPN identification
iii) the transform sets defining the security protocols and
algorithms that shall be used by two CEs for encryption and
authentication (for IPSec).
The (pre-shared or CE's private) key for IPSec tunnels must be pre-
configured on the CE. Other VPN service related configuration which
do not change as sites are removed or added to a VPN may also be
configured a priori or remotely (and manually) configured if the
parameters do not change frequently. The intent here is to define a
minimal set of VPN service parameters that should be auto-configured.
Hence, this draft shall focus on the auto-configuration of tunnel(s)
to remote CE(s). If necessary, the transform sets for IPSec and other
service parameters shall be defined to be auto-configured in future.
The scope here are VPN service parameters, other service parameters
related to managed Internet service, firewall configuration are not
within the scope of this draft.
4. CE Auto-Configuration requirements
The CE auto-configuration solution should:
- minimize the number of parameters that must be pre-configured
- minimize the number of parameters that shall be auto-configured
- allow CE to automatically request tunnel endpoint information
- be able to automatically update CEs with new tunnel endpoint
information
- allow a CE to automatically provision the tunnels (discovered or
being updated earlier on) to other CEs
- allow a provider to provision tunnel information for a CE
independent of whether a CE is up and running. When a CE comes back
on line, the auto-update procedures must reliably obtain the latest
tunnel information
- allow authentication of the tunnel endpoint information
- a customer must not be allowed to tamper with any part of the CE's
configuration other than the part that the customer is allowed to
configure
- allow a provider to explicitly add or remove sites of a VPN e.g. a
tunnel setup or removal does not necessarily imply a site should be
added or removed from the VPN
The CE auto-configuration solution may:
- allow configuration of CEs in different AS (Autonomous Systems) or
network provider
- leverage providers' existing AAA infrastructure
- hide or encrypt the tunnel endpoint information
[Note: If a CE uses a private key/certificate pair tunnel
authentication, the remote end CE can use the corresponding public
key when authenticating the other end CE. In this case, the private
key may be configured on CEs a priori, and not sent as part of the
tunnel endpoint information.
Alternatively, if [PIC, XAUTH] is used, a CE may request credentials
from an Authentication Server instead, and there is no need to pre-
configure a CE with a private key, instead the CE ID and the password
may be pre-configured on the CE. "It is assumed then that the CE
possesses (e.g. by pre-configuration) the public key of the
Authentication Server, or it has the means to obtain and validate a
certificate for the Authentication Server (e.g., by pre-configuration
of a CA (Certificate Authority) public key)" In this case, the CE
credentials must be encrypted if sent as part of the tunnel endpoint
information. Otherwise an independent key distribution protocol may
be used to distribute keys, instead of sending the key as part of the
tunnel endpoint information.]
- automate IP address association with a CE of a VPN
[Note: a provider may have to be informed of a CE location offline
and has to manually associate an IP address (that the CE is reachable
from a provider's network) with a CE of a VPN. Hence it is useful to
allow a CE to authenticate itself to a VPN Configuration server and
then to "register" itself. This allows a VPN Configuration server to
associate the CE with its current IP address or alternatively, if
the CE is within the service provider's network, the VPN
Configuration server may be able to assign the IP address to the CE
(on the port facing a network provider), associate the CE with the
assigned IP address and at the same time provide the remote CE IP
addresses [See Appendix].
4.1 General Ideal Solution
Ideally on bootup, a CE should be able to automatically perform
procedures to gain network access if needed and obtain an IP address
to allow it to communicate with other CEs in the IP network, e.g. via
[DHCP] or for PPP links via IPCP. Subsequently the CE shall request
tunnel information from a VPN Configuration server.
CEs need only be pre-configured with :
a) a shared key or private key/certificate pair or a password, to
allow it to authenticate itself to the VPN Configuration server and
If a shared key is used, a CE may additionally be pre-configured with
a CE Identification (ID) in some service deployment scenarios, e.g.
where the service provider is not able to infer the "location" of the
CE or infer from the IP address of a CE which CE it is communicating
with.
b) a shared key or a CA's public key to allow it to authenticate the
VPN Configuration server
CEs may be pre-configured with the VPN Configuration server name if
the CE is not able to discover the VPN Configuration server or if the
server involved in the network access configuration process (e.g.
DHCP Server or NAS (Network Access Server), see [L2TP]) cannot be
leveraged as a VPN Configuration server. If the CE is pre-configured
with the VPN Configuration server name, the CE may find out the VPN
Configuration server IP address via e.g. the DNS.
A CE shall query or retrieve the tunnels information of a VPN it
belongs from the VPN Configuration server.
The VPN Configuration server shall authenticate the CE and provide
the tunnel endpoint information to the CE, encrypting any information
if necessary. [To leverage existing AAA infrastructure, the VPN
Configuration server may choose to authenticate the CE via e.g.
RADIUS and obtain the tunnel information from the RADIUS Server as
well. In this case, the VPN Configuration server is acting as a
RADIUS client, and shall send the CE Identification and password to
the RADIUS server See the Appendix for further discussion].
The CE shall authenticate the tunnel information provided by the VPN
Configuration server, before provisioning the tunnels.
5. Protocol choices and features
Some candidate protocols that could be used for CE auto-configuration
and the extensions that are required are identified here. A
combination of these approaches may also be considered.
5.1 SNMP
It is not recommended that an operator configure CEs directly via
SNMP, as it is not easy to setup up the tools to provide the
necessary timeliness and reliability.
A new auto-discovery framework is required on CEs and SNMP "manager"
code which allows a CE to "get" VPN service parameters (a defined IP
VPN MIB) from a VPN Configuration server is required to be
implemented on a CE. Normally a Network Element (NE) has an SNMP
"agent" which allows a Network Manager to "get" MIB objects from the
NE. If it is not feasbible for a CE to "get" VPN parameters, the VPN
Configuration server may have to send SNMP traps to the CE to trigger
the CE to do a "get" VPN parameters from the VPN Configuration
server.
An new auto update framework is required on a Network/VPN Service
Provisioning Manager. SNMPv3 may be used to automatically update CEs.
SNMPv1/v2 over IPSec may used to configure CE, but this cannot
prevent a customer from tampering with a CE.
5.2 LDAP/DNS
A CE could retrieve tunnel endpoint information (to add new tunnels)
from a (DNS or LDAP) server, and may be located in a different
provider's network. However, a provider is not able to inform a CE to
explicitly teardown a tunnel to a site unless the CE poll the DNS or
LDAP server for VPN update information or a message is sent from
another server using a different protocol to trigger the CE to pull
information from the DNS or LDAP server.
If another messaging/protocol is required to inform a CE to remove a
tunnel endpoint, that same protocol could be used to inform a CE to
add a tunnel endpoint, instead of LDAP/DNS, i.e. the use of LDAP/DNS
for CE auto-configuration would be redundant then.
This "receive-trigger-then-pull" paradigm is more complicated than
the "polling" paradigm, especially when protocols that do not have
the necessary reliability mechanisms built into them are used. Both
paradigms have some difficulties in figuring out whether the
absence of some previously present data is significant or not
(e.g., there may be a transient problem in the delivery mechanism),
when the protocol used does not have reliability mechanisms. It
should be noted that some of the mechanims considered in this draft
such as DHCP has reliability mechanisms and while the RADIUS
protocol itself does not provide reliability mechanisms, the
retransmission & reliability procedures are provided by
implementation.
5.3 IKE
When a CE attempts to setup tunnel to a remote CE (which may be
located in a different provider's network), the remote CE is
implicitly being informed of the tunnel endpoint. The remote CE may
still need to contact the VPN Configuration Server (using another
protocol) to download other tunnel endpoint information. This
implies a provider is not able to explicitly teardown a tunnel to a
site, unless a message is sent from a server using another protocol,
as in the LDAP/DNS approach (the "receive-trigger-then-pull"
paradigm).
5.4 COPS
COPS allows a CE to retrieve tunnel endpoint information as well as
to be updated of tunnel endpoint information from a PDP (a server).
CEs may be located in different providers' network and SSL/TLS may be
leveraged to provide secure commnunication between CEs and the VPN
Configuration Server.
The PDP (Policy Decision Point) must maintain a large number of TCP
sessions if there are a large number of CEs.
5.5 XML and HTTP/HTTPS
May require another auto-discovery and update protocol, on top of
http/https, unless the "gets/sets" are simple and the outcome of a
"get/set" is either a success or failure. May require an auto-
discovery and update framework on the CE and the VPN Configuration
Server.
5.6 DHCP
Auto-discovery and auto-update framework (with reliability
mechanisms) already exist on DHCP client and server. Automate CE
address association with CEs of a VPN and faciliate CE address
management and reuse. Applicable when CEs of a VPN are within a
provider network. Multiple DHCP servers may be used in a network and
these can be configured from one management station. Configuration
information is sent from the management station to multiple DHCP
servers. It is not clear at this point if the mechanisms to configure
multiple servers need to be standardized.
In the case where CEs span inter-domain networks and hence the
network access configuration process may not be leveraged, an
approach where a front-end Authentication Server [See PIC, XAUTH] is
used to authenticate CEs in another provider's network and request
VPN information from a back-end server (e.g. a RADIUS server or DHCP
Server), may be required. The CEs in another provider's domain
cannot be updated with new VPN information, unless the back-end
server is able to provide VPN information update to the front-end
Authentication Server, and the front-end Authentication Server is
able to inform CEs of the VPN information change. It should be noted
that authentication may not be required when the CEs are attached to
the service provider's network, because the service provider could
use ingress filtering to prevent VPN Provisioning Server or CE
masquerading. When the CEs are not attached to the service provider's
network, it is necessary then to authenticate the auto-provisioning.
This approach is discussed in the Appendix.
5.7 RADIUS
This allows a provider to leverage existing AAA framework for IP VPN.
Currently this approach does not allow a server to update CEs of VPN
information. This approach is discussed in the Appendix.
6. Management Boundary Issues
We do not see a motivation for a VPN provider using a CE-based VPN
approach to share management of a VPN with another VPN provider. A
VPN provider could provide a VPN service that spans inter-domain
boundaries as long as all the CEs are reachable inter-domain. Hence,
we do not see a need to address this type of inter-provider
management at this point in time.
In the case where the CE is provisioned by both the customer and
provider, let us consider this example. Consider a PC at home being
auto-configured (e.g. with an IP address, web server, DNS etc) by an
ISP. One could view this as crossing provisioning boundaries (the PC
owner & the ISP are allowed to provision the same box), but in this
case the provisioning by the ISP is made transparent by auto-
configuration. Auto-provisioning in this case is quite different from
conventional management (which may allow configuring of a more
general set of parameters, whereas in the former, only a well-defined
set of parameters are being configured by another party). This auto-
provisioning paradigm may be used in a similar manner to configure
VPNs.
In the case of where the CEs of a VPN are in one domain, a network
provider should perform ingress filtering to prevent VPN Provisioning
Server masquearading as described in the Appendix. In the case where
CEs may span inter-domain, it is necessary to authenticate the auto-
provisioning of a well-defined set of parameters as described in the
Appendix.
7. Conclusion
To facilitate CE auto-configuration, the following alternatives may
be considered:
a) specify the MIB required for CE auto-configuration. This MIB may
be part of the IP VPN MIB for CEs, which can be used to perform
remote manual provisioning of other parameters that do not require
auto-configuration, as well. Vendors may build proprietary auto-
configuration framework independently and configure the MIB objects
on CEs via SNMP.
b) specify the tunnel information to be carried in a suitable
protocol, which ideally should meet the requirements of CE auto-
configuration and allows existing network device configuration
framework to be leveraged for CE auto-configuration
7. Acknowledgments
The authors would like to thank Andrew Krywaniuk and Pierre Bolduc
for providing helpful technical information, Craig Sheppard, Phil
Nelson, Cliff Wang and Eric Rosen for CE configuration discussions.
We have also used some text suggested by Eric Rosen in this draft.
References
Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[CE-VPN] A Framework for Provider Provisioned CE-based Virtual
Private Networks http://search.ietf.org/internet-drafts/draft-ietf-
ppvpn-ce-based-01.txt
[CE-VPL] CE-based Virtual Private LAN
http://search.ietf.org/internet-drafts/draft-lee-ce-based-vpl-01.txt
[DHCP] Dynamic Host Configuration Protocol,
http://www.ietf.org/rfc/rfc2131.txt
[DHCP-AUTH] Authentication for DHCP Messages, ftp://ftp.isi.edu/in-
notes/rfc3118.txt
[PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[IPCP] G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1172, May 1992
[XAUTH] Beaulieu, Pereira, "Extended Authentication within IKE
(XAUTH)", draft-beaulieu-ike-xauth-02.txt, October 2001.
[PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE
Credential Provisioning Protocol", Internet draft (work in progress),
draft- ietf-ipsra-pic-05.txt, February 2002.
[DSL_autoconf] Technical Report TR-044, "Auto-Configuration for Basic
Internet (IP-based) Services", DSL Forum, November 2001
[HTTP-BCP] http://www.ietf.org/rfc/rfc3205.txt?number=3205
[PPVPN-REQ] http://search.ietf.org/internet-drafts/draft-ietf-
ppvpn-requirements-03.txt
Appendix
1. Overview of CE Auto-configuration solutions
A CE shall be automatically configured with an IP address to allow it
to communicate with the provider's network.
Different protocols (depending on the network access method and VPN
service deployment requirements) which allow CEs to discover and/or
be updated with VPN service information are described here.
Both the automatic configuration of IP address on the CE and
provisioning of services on the CE should be authenticated to prevent
malicious users from tampering with CE configuration.
2. Auto-configuration of IP address of CE
If a CE is located in the VPN service provider's network (also the
network provider in this case), a CE may use DHCP to automatically
obtain and configure its IP address (facing a provider's network).
Otherwise the CE IP address is assigned by the CE's network provider,
and VPN service provider must be informed of the CE IP address
offline, or when a CE contact the VPN Configuration Server as
described in later sections.
The CE shall obtain an IP address from a DHCP server using the
procedures defined in [DHCP]. The DHCP server and CE shall be
configured with a shared key a priori. The CE and the DHCP server
shall use the Delayed Authentication protocol defined in [DHCP-AUTH]
(instead of Configuration Token).
A CE should authenticate a DHCP server to ensure the DHCP server is
the provider's DHCP server and not a rogue server. A DHCP server
should authenticate the CE to ensure the CE is a legitimate DHCP
client.
No changes to [DHCP] and [DHCP-AUTH] are required during the auto-
configuration of IP address of CE as described above.
3. Auto-configuration of VPN service - leveraging DHCP
Once the CE has obtained an IP address, the CE shall send DHCPINFORM
directly to the DHCP server to solicit for other configuration
information. The DHCP server shall respond with a DHCPACK and the
following VPN related DHCP option(s).
If a VPN site is removed or added (or the CEs must be updated with
new VPN configuration information), the DHCP server may send DHCP
FORCERENEW to the CEs belonging to the VPN. The CEs shall send
DHCPINFORM as described in the previous paragraph to obtain new VPN
site information.
This section lists the new DHCP option(s) required.
3.1 Peer CE DHCP Option
The Peer CE option specifies the VPN ID (a unique number identifying
a VPN or VPL within a service provider's network) and a list of Peer
CE(s) which the client may connect to. The CE should setup a tunnel
to every Peer CE listed.
The code for this option is to be assigned by IANA. The minimum
length for this option is 4 octet, and the length MUST always be a
multiple of The VPN ID is 4 octet and the CE addresses are IPv4
addresses. The Reserved field is 1 octet - the 1 "O"peration bit to
indicate if these are additional CEs to be added or deleted, if the
"A" bit is set to 1 or to 0, respectively.
4.
Code Len CE Address 1 CE Address 2
+-----+-----+------+--------+-+-----+-----+-----+-----+-----+---
| TBD | n | VPNID|Reserved|O| a1 | a2 | a3 | a4 | a1 | a2 ...
+-----+-----+------+--------+-+-----+-----+-----+-----+-----+----
4. Auto-configuration of VPN service - leveraging PPP
If a CE is connected to a provider's network via PPP, the remote CE
addresses of a VPN may be configured via the IPCP Configuration
Options which allow negotiatiation of desirable Internet Protocol
parameters.
The most up-to-date values of the IPCP Option Type field are
specified in the most recent "Assigned Numbers" RFC [6]. A new TBD
IPCP option can be used to configure remote CE addresses of a VPN if
a CE is connected to the provider's network via PPP. However this
requires NAS (Network Access Servers) to support this new IPCP
option. A forward looking extension may be to define an opaque IPCP
option to allow some configuration options to be relayed to or from a
back-end server transparently.
4.1 VPN-IP-Addresses IPCP Option
This Configuration Option list the remote CE IP addresses of the VPN.
By default, no VPN IP address is assigned.
The IP-Address Configuration Option format is shown below. The
fields are transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPNID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE-IP-Address1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE-IP-Address2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...........
Type
TBD
Length
6 + n*IP address length, where n is the number of CEs
Reserved
The Reserved field is 1 octet: the 1 "O"peration bit to indicate
if these are additional CEs to be added or deleted, if the "A" bit is
set to 1 or to 0, respectively.
VPNID
the VPN Identification, allowing CEs to distinguish between the
different VPNs they may belong to
CE-IP-Address
The CE-IP-Address is the address of a remote CE.
Default
No CE-IP-Address is assigned.
5. Auto-configuration of VPN service - using a VPN Configuration server
approach
It should be noted, this approach is applicable to a customer
provisioned VPN as well, the provider in this case, is the VPN
administrator. The CE should be configured a priori with the name or
address of the VPN Configuration server. This MAY be accomplished by
pre-configuring a CE before it is being deployed or alternatively the
VPN Configuration server address MAY be obtained from a DHCP server
via a new DHCP option (if the CE is within the provider's network).
The CE must be pre-configured with the CE's private key and digital
certificate pair or the CE Identification and password (if [PIC,
XAUTH] is used), and the provider's Certificate Authority (CA) and
the CA's public key or the VPN Configuration Server's public key.
This allows a CE to authenticate the VPN Configuration Server and the
CE to be authenticated by the VPN Configuration Server (or relayed to
an authentication server via the VPN Configuration Server)
The CE should then be able to contact the VPN Configuration server.
VPN configuration parameters may be solicited from a VPN
Configuration server. If [PIC, XAUTH] is used to contact an
Authentication Server (aka the VPN Configuration Server in this
document), a new ISAKMP payload to carry a VPN Information request
can be defined to allow the CE to request VPN Information via the
Authentication Server. The VPN Information request should be sent
after the CE has been authenticated. The front-end Authentication
Server (aka VPN Configuration Server here) may request the VPN
Information from a back-end legacy server e.g. RADIUS. See [PIC] for
the rationale on using a front-end and back-end server.
5.1 Default VPN Configuration server DHCP Option (Optional)
This feature may be useful if a CE network access is managed by the
VPN service provider as well. The new DHCP option required is the
VPN Configuration server option.
The VPN Configuration server option specifies a list of servers
available to the client. VPN Configuration server should be listed
in order of preference.
The code for this option is TBD. The minimum length for this option
is 4 octets, and the length MUST always be a multiple of 4.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| TBD | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
6. Security Considerations for DHCP
The addition of DHCP option(s) for VPN auto-configuration does not
affect the security of DHCP. The security issues of DHCP are
described in [DHCP-AUTH] and as it pertains to the auto-configuration
of CEs, the security issues are described in this draft.
If an unauthorised CE configure its own IP address, the CE may not be
permitted to use any services unless the CE has been authenticated
for the particular service. For e.g. a device or the default filter
at the ingress to the network can be configured to discard all
traffic except DHCP messages from the client (port 67) unless the
client has been authenticated for services as described in Section 3.
In addition all DHCP messages on port 68 from the client should be
discarded (a network user should not be sending DHCP messages from a
DHCP server into the provider's network). This measure which is
applicable to Section 3, does not prevent a malicious user from
launching a DoS attack on DHCP servers in the provider's network.
[Note: If Layer 2 authentication is available, (e.g. 802.1x), it may
be used to provide authenticated access to the Layer 2 network. In
this case, unauthorised users are not allowed to send traffic].
To reduce DoS attacks, the DHCP server may choose to "quarantine" CEs
which have exceeded the pre-defined number of communication attempts
allowed with the DHCP server within a given period. Subsequent
messages from these CEs may be discarded. If these measures are
necessary, the text in DHCP-AUTH would need to be modified
accordingly.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Authors' Addresses
Cheng-Yin Lee Email: Cheng-Yin.Lee@alcatel.com
Jeremy deClercq Email: jeremy.de_clercq@alcatel.be