Network Working Group M. Morelli
INTERNET-DRAFT Telecom Italia Lab
Expires: February 18, 2005 K. Nielsen
Ericsson
J. Palet
Consulintel
J. Soininen
Nokia
J. Wiljakka
Nokia
August 19, 2004
Goals for Zero-Configuration Tunneling
<draft-nielsen-v6ops-zeroconf-goals-00.txt>
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 (BCP 79).
By submitting this Internet-Draft, I accept the provisions of Section
[#3] of RFC 3667 (BCP 78).
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes the set of goals to be fulfilled by a Zero-
configuration tunneling protocol.
Zero-configuration tunneling here denotes a minimalistic IPv6-in-IPv4
automatic tunneling mechanism that could be used by a Service
Nielsen, et al. [Page 1]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
Provider to offer IPv6 connectivity to its customers in early phases
of IPv4 to IPv6 transition.
Table of Contents
1. Introduction.....................................................2
2. Terminology......................................................3
3. Scope............................................................4
4. Assumptions and Prerequisites....................................4
4.1. Applicability Assumptions...................................4
4.2. 3GPP Compliance Prerequisite................................5
5. Timing...........................................................5
6. Goals............................................................6
6.1. Simplicity..................................................6
6.2. Automated IPv6-in-IPv4 tunnel establishment.................6
6.3. Use native when available...................................6
6.4. Easy to deploy and Easy to Phase-out with no modifications on
existing equipment...............................................6
6.5. Tunnel Server End-point Discovery...........................7
6.6. Address Assignment..........................................7
6.7. Tunnel Link Sustainability..................................7
6.8. Tunnel End-point Reachability Detection.....................7
6.9. Private and public IPv4 addresses...........................7
6.10. Security...................................................8
7. Non Goals........................................................8
7.1. NAT and Firewall Traversal..................................8
7.2. IPv6 DNS....................................................8
7.3. Extensibility...............................................8
7.4. Registration burden.........................................9
8. Security Considerations..........................................9
8.1. Threats to existing network infrastructures.................9
8.2. Threats to nodes implementing Zero-configuration tunneling.10
8.2.1. Threats to end-hosts..................................10
8.2.2. Threats to tunnel servers.............................11
9. Acknowledgments.................................................11
10. Authors Contact Information....................................11
11. References.....................................................12
Appendix A Out of Scope............................................13
Appendix B Open Issues.............................................13
1. Introduction
The IETF v6ops Working Group has identified and analyzed deployment
scenarios for IPv4/IPv6 transition mechanisms in various stages of
IPv6 deployment and IPv6 and IPv4 coexistence.
This work has been carried out for a number of different network
environments each with their particular characteristics: Enterprise,
ISP, Unmanaged and 3GPP networks, see e.g., [2], [3] and [4].
Nielsen, et. al. [Page 2]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
The work has identified a need for automatic IPv6-in-IPv4 tunneling
mechanisms that provide bidirectional IPv6-in-IPv4 tunnel
connectivity between dual stack end-nodes located at an IPv4-only
access network and dual-stack tunnel servers located at IPv6-IPv4
network boundaries within the Service Providers network.
The term Zero-configuration tunneling is used in this document to
denote an IPv6-in-IPv4 tunneling mechanism that fulfills the goals as
put forward here.
A Zero-configuration tunneling mechanism provides a basic set of
tunneling features only, and intentionally so. The scope of zero-
configuration tunneling is not to provide emulation of the full suite
of native IPv6 connectivity functions; rather the focus is on
providing a minimal set of features required for automatic
establishment of IPv6 connectivity.
The starting point for the definition of the set of goals to be
fulfilled by a zero-configuration tunneling mechanism has been the
set of features required for the IPv6-in-IPv4 tunneling mechanism
envisaged to be needed during the early phases of IPv6 transition in
3GPP environments as described in [4].
The applicability of Zero-configuration tunneling may widen to other
transition scenarios.
For scenarios demanding advanced tunneling features, for example full
emulation of native (though tunneled) IPv6 connectivity, a more full-
fledged tunneling mechanism is envisaged to be deployed, see [5].
With respect to the latter, an analysis of appropriate mechanisms for
automatic discovery of the tunnel endpoint is being done in [6].
2. Terminology
Zero-configuration tunneling site:
A logical IPv4 network over which IPv6 connectivity is provided to
dual-stack nodes by means of zero-configuration tunneling.
Tunnel endpoint:
A dual-stack node performing IPv6-in-IPv4 tunnel
encapsulation/decapsulation in accordance with zero-configuration
tunneling.
Tunnel Server:
A dual-stack server node with native IPv6 connectivity and which
provides IPv6 connectivity to client nodes by performing IPv6-in-IPv4
tunnel encapsulation/decapsulation to/from client nodes in accordance
with zero-configuration tunneling.
A tunnel server is likely to be a dual-stack router.
Nielsen, et. al. [Page 3]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
3. Scope
The scope of Zero-configuration tunneling is restricted to the
absolute minimal set of functions required to provide automatic IPv6
connectivity establishment to dual stack nodes by means of IPv6-in-
IPv4 encapsulation, [1], to tunnel servers under the assumptions and
prerequisites described in Section 4.
The primary goal of Zero-configuration tunneling is to provide IPv6
connectivity to nodes on an individual basis. By this it is meant
that it is only an explicit goal to have a /128 address allocated for
connectivity on the tunnel link. As such optimal IPv6 connectivity
provisioning in Personal Area Network (PAN) scenarios are not
explicitly within the scope of Zero-configuration tunneling.
Direct tunneling is neither an explicit goal nor explicitly excluded
in Zero-configuration tunneling.
Zero-configuration tunneling does not attempt to provide emulation of
the full set of native IPv6 connectivity functions as defined by [7],
[8] (and [9]).
4. Assumptions and Prerequisites
4.1. Applicability Assumptions
Zero-Configuration Tunneling is a tunneling mechanism by the virtue
of which dual-stacks hosts, attached to IPv4-only networks links, can
use IPv6-in-IPv4 encapsulation ([1]) to tunnel servers for global
IPv6 connectivity.
The aim of the document is to define the set of goals to be fulfilled
by zero-configured tunneling when the following assumptions are made
on the deployment environment:
- IPv4 source addresses spoofing within the zero-configuration
tunneling site is prevented.
- The zero-configuration tunneling site is protected from proto-41
encapsulated packets arriving from external IPv4 networks.
- At least one authoritative DNS server is IPv4-enabled and at
least one recursive DNS server supports IPv4. Further IPv4 DNS
Server discovery is provided by already existing means/means
outside the scope of the tunnel protocol.
- There are no NATs in between the tunnel endpoints in the zero-
configuration tunneling site.
- The zero-configuration tunneling network is fully penetrable for
intra-site IPv6-in-IPv4 Protocol 41 traffic.
- The user is being authenticated to the network by means external
to the tunneling protocol and other than that no additional
authentication/registration mechanisms are required.
Nielsen, et. al. [Page 4]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
The above assumptions are believed to be readily applicable to the
3GPP tunneling transition scenario described in [4], section 3.1.
4.2. 3GPP Compliance Prerequisite
It is a prerequisite that zero-configuration tunneling should be
applicable in 3GPP wireless networks. When considering the
characteristics of 3GPP network links and mobile terminals / User
Equipment (UE), the following points need to be taken into account:
- Link bandwidth (tunnel overhead / usage cost)
- Link latency
- UE battery power and derived implications on memory and
processing power
It is thus an explicit requirement for zero-configuration tunneling
to comply well with the constrained conditions put on the above
parameters by the 3GPP environments. The latter which commonly is
recognized as translating into requirements for the protocol to
operate with a limited number of message exchanges, small packet
sizes and simple message processing.
Here we shall refer to a protocol as being lightweight when its
demands on message exchanges, packet sizes and message processing
complexity are sufficiently light for it to be readily applicable in
environments characterized by the constrained conditions of 3GPP
networks (as described above).
As a mean to ensure that the protocol be lightweight it is considered
preferable for the protocol to provide a simple set of functions
only, even if it provides only a basic IPv6 service compared to the
native one. (Although it is acknowledged that additional
functionality doesn't necessarily automatically add to the demands on
the afore mentioned parameters.)
5. Timing
For the purpose of 3GPP deployment it is a prerequisite that this
tunneling protocol is provided within a very restrictive timescale.
Zero-configuration tunneling is envisaged to be deployed in 3GPP
networks as an initial and temporary mechanism to provide limited
IPv6 connectivity services. Native IPv6 like connectivity is in 3GPP
environments envisaged to be feasible by virtue of true native IPv6
only.
Trial deployments, in which zero-configuration type of IPv6
connectivity is provided in 3GPP environments, are starting up using
experimental protocols at the time of writing this document.
Nielsen, et. al. [Page 5]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
6. Goals
The goals to be achieved by zero-configuration tunneling are detailed
in the following subsections.
6.1. Simplicity
By simplicity, we understand a tunnel protocol that is simple in the
sense that it allows for easy implementation in the targeted
environments. In particular it should provide a reasonable, limited
set of basic IPv6 connectivity features.
Further by simplicity we imply that the protocol must be lightweight.
6.2. Automated IPv6-in-IPv4 tunnel establishment
The IPv6-in-IPv4 tunnels and the IPv6 connectivity must be
established in an automated manner, i.e. without requiring manual
intervention at any of the tunnel end-points at tunnel establishment
time.
The mechanism must be fully dynamic in the sense that it must not
require IP address information such as the IPv4 address of a Tunnel
Server and/or the IPv6 address(es) to use for IPv6 connectivity to be
configured on the end-hosts beforehand.
6.3. Use native when available
The tunnel protocol should allow the usage of native IPv6
connectivity whenever such is available.
The protocol must in no way restrict the native IPv6 capabilities of
the client node.
IPv6 native connectivity must be preferred if available.
6.4. Easy to deploy and Easy to Phase-out with no modifications on
existing equipment
The tunnel protocol should be easy to deploy into the existing IPv4
and IPv6 network infrastructure.
The tunnel protocol should have no major impact on protocols and
infrastructure nodes deployed in existing infrastructures providing
IPv4 and native IPv6 connectivity.
The tunnel protocol should coexist and work seamlessly together with
any native IPv6 infrastructure that gradually may be implemented in
the network. The tunnel protocol should have no negative implications
on how such are implemented.
Nielsen, et. al. [Page 6]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
The tunnel protocol must be easy to take out of service once native
IPv6 is available.
6.5. Tunnel Server End-point Discovery
The tunnel protocol must provide a mechanism for automated end-point
discovery by the virtue of which end-hosts automatically and at run-
time can determine the IPv4 addresses of available Tunnel Servers.
The discovery mechanism should rely on services intrinsic, read
already universally deployed services, to the particular network
environment. It should not require the addition of additional IP
network infrastructure elements for this function only.
The analysis done in [6] may apply.
6.6. Address Assignment
The tunnel protocol must allow for the assignment of at least one
globally routable (/128) IPv6 unicast address to use for tunneled
IPv6 connectivity over the link provided by the zero-configuration
tunneling mechanism.
It is preferable that the address assignment provides a stable
address, that is, an address that can be used for IPv6 connectivity
for a certain amount of time rather than solely one address per
higher layer session initiation.
6.7. Tunnel Link Sustainability
The tunnel link established in between a host deploying zero-
configuration tunneling and an associated tunnel server should be
expected to remain in administrative active state for the duration of
the validity of the IPv6 address provided to the host.
The tunnel protocol must not mandate keep-alive messages to be
transmitted by the host simply in order to sustain tunnel link
connectivity.
6.8. Tunnel End-point Reachability Detection
The tunnel protocol must allow for means, comparative with the
neighbor (un-)reachability detection functions provided by IPv6 ND,
for one tunnel end-point to verify the reachability of other tunnel
end-points towards which it intends to send packets.
6.9. Private and public IPv4 addresses
The tunnel protocol must work over IPv4 sites deploying both private
and public IPv4 addresses.
Nielsen, et. al. [Page 7]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
Furthermore, the tunnel protocol should work with both dynamic and
static IPv4 address allocation.
Motivation: Private IPv4 addresses are widely used in current 3GPP
networks.
6.10. Security
The tunnel protocol should not impose any new vulnerability to the
existing network infrastructure.
The tunnel protocol should not impose any new vulnerability to the
nodes implementing the tunnel protocol than what is already present
in existing IPv6 networks, where multiple hosts are served by the
same router (possible multiple routers).
7. Non Goals
Non-goals of zero-configured tunneling are detailed in the following
subsections.
With the term Non-goals we refer to features that generally are
believed to be applicable to tunneling, but which are not among the
minimal set of required features of Zero-Configuration Tunneling. The
latter primarily because of the prerequisites for Zero-Configuration
Tunneling and/or because of the assumptions made on the applicability
environments for Zero-Configuration Tunneling, e.g., see Section 4.
7.1. NAT and Firewall Traversal
NAT and Firewall traversal is not required due to the assumptions on
the applicability environment.
Moreover to minimize the tunneling overhead applied to the packets as
well as in order to minimize the number of tunnel set-up signaling
messages exchanged on the wire, is preferable that the protocol does
not deploy the UDP encapsulation techniques, on which mechanisms able
to traverse NATs and Firewalls normally rely.
7.2. IPv6 DNS
By virtue of the assumptions on the applicability environments IPv4
transport and IPv4 DNS discovery mechanisms can be relied on for DNS
services.
Consequently the tunnel protocol does not need to provide the means
to the end-host to deploy IPv6 for DNS services.
7.3. Extensibility
Nielsen, et. al. [Page 8]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
As a minimal tunneling mechanism Zero-configuration tunneling targets
IPv6 connectivity provisioning only. The protocol need not be readily
extendable to outer encapsulation mechanisms, e.g., IPv4-in-IPv6.
7.4. Registration burden
Tunnel service registration is not required due to the assumptions on
the applicability environment.
In order to keep the simplicity and minimize the tunnel overhead it
is desirable that the tunnel protocol not in itself (e.g., in order
to meet the goals put forward in this document) mandates
authenticated registration of the user.
8. Security Considerations
The following considerations apply to the situation where Zero-
configuration tunneling is deployed in between tunnel servers and
end-hosts only. The implications of the usage of direct tunneling in
between end-hosts is not considered.
It is assumed that the following assumptions of Section 4 are valid
in the particular network environment:
- IPv4 source addresses spoofing within the zero-configuration
tunneling site is prevented.
- The zero-configuration tunneling site is protected from proto-41
encapsulated packets arriving from external IPv4 networks.
It is worthwhile to note that together these assumptions imply that
the IPv4 source of all proto-41 tunneled packets is legitimate.
8.1. Threats to existing network infrastructures
As stated in Section 6.10 the tunnel protocol should not impose any
new vulnerability to the existing network infrastructure.
The following have been identified as potential threats opened up for
by the deployment of zero-configuration tunneling:
- Network infrastructure nodes cannot in an attempt to protect the
end-hosts by default filter out intra-site (i.e. internally
sourced and destined) ipv6-in-ipv4 tunneled packets.
- As the tunnel service is un-authenticated (not registered) the
tunnel server may be usable to reflect tunneled packets into the
network, similar to the 6to4-reflection attacks identified in
Error! Reference source not found..
- The usage of zero-configuration tunneling may open up for
threats to other mechanisms in the network that rely on proto-41
encapsulation.
Nielsen, et. al. [Page 9]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
Detailed analysis of the validity of these threats will have to
depend on the particular zero-configuration solution. In general it
could be noted that attacks based on the above threats largely should
be preventable if the end-hosts in the network implement appropriate
drop policies, either simple drop all proto-41 policies or more
differentiated policies based, e.g., on source addresses.
8.2. Threats to nodes implementing Zero-configuration tunneling
As stated in Section 6.10 the tunnel protocol should not impose any
new vulnerability to the nodes implementing the tunnel protocol than
what is already present in existing IPv6 networks, where multiple
hosts are served by the same router (possible multiple routers).
Here it is implicitly implied that the tunnel server(s) take the role
of default routers and the end-nodes using zero-configuration
tunneling for IPv6 connectivity the role of hosts in multi-access
environments.
8.2.1. Threats to end-hosts
Given that all IPv4 sources of proto-41 tunneled packets can be
assumed to be legitimate, threats stemming from encapsulated packets
sourced by nodes (addresses) other than nodes (addresses) which the
end-hosts recognize as tunnel servers (identified by addresses) can,
if not already an intrinsic part of the zero-configuration protocol,
easily be mitigated by the implementation of appropriate
differentiated (source addresses) drop policies in the end-hosts,
i.e., accept only if source is tunnel server.
In current multi-access IPv6 networks hosts need to trust on the
benevolence of their default routers as well as hosts must trust that
anyone impersonating as a router is indeed one, see, e.g., the trust
models and threats described in [11].
Future multi-access IPv6 networks may rely on SEND mechanisms, i.e.,
mechanisms developed in the SEND WG in order to mitigate the threats
described in [11], to establish a trust relations ship in between
host and routers.
In order for an end-host deploying zero-configuration tunneling to
trust that packets it perceives as stemming from tunnel servers do
actually also stem form such as well as for the end-host to trust on
the benevolence of its tunnel servers it suffices that a sufficiently
trustworthy tunnel server end-point discovery mechanism, read
discovery of benevolent tunnel servers IPv4 address(es), is
implemented.
In open environments, such as, e.g., the 3GPP environment, it is
assumed a prerequisite that a trustworthy zero-configuration tunnel
server end-point discovery mechanism is implemented.
Nielsen, et. al. [Page 10]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
8.2.2. Threats to tunnel servers
No specific threats to the tunnel server have been identified.
9. Acknowledgments
Prior work by J. Mulahusic on the requirements for UE tunneling has
been considered in the initial stage of the work.
This work has benefited from input and comments provided by Fred
Templin in the initial phase of the work.
Corresponding work on assisted-tunneling, [5], has been an
inspiration for the zero-configuration tunneling work.
10. Authors Contact Information
Mario Morelli
Telecom Italia Lab.
Via Guglilmo Reiss Romoli, 274
I-10148 Turin,
Italy
Phone: +39 011 228 7790
Fax: +39 011 228 5069
Email: mario.morelli@tilab.com
Karen Egede Nielsen
Ericsson
Skanderborgvej 232
8260 Viby J
Denmark
Phone: + 45 89 38 51 00
Email: karen.e.nielsen@ericsson.com
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Alcobendas - Madrid
E-28108 - Spain
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
EMail: jordi.palet@consulintel.es
Nielsen, et. al. [Page 11]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
Juha Wiljakka
Nokia
Visiokatu 3
33720 TAMPERE
Finland
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
Jonne Soininen
Nokia
Linnoitustie 6
02600 ESPOO
Finland
Phone: +358 7180 08000
EMail: jonne.soininen@nokia.com
11. References
[1] Nordmark, E., Basic Transition Mechanisms for IPv6 Hosts and
Routers, draft-ietf-v6ops-mech-v2-04.txt (work in progress),
July 2004.
[2] Lind, M., Scenarios and Analysis for Introducing IPv6 into ISP
Networks, draft-ietf-v6ops-isp-scenarios-analysis-03.txt (work
in progress), June 2004.
[3] Huitema, C., Evaluation of Transition Mechanisms for Unmanaged
Networks, draft-ietf-v6ops-unmaneval-03.txt (work in progress),
June 2004.
[4] Wiljakka, J., Analysis on IPv6 Transition in 3GPP Networks,
draft-ietf-v6ops-3gpp-analysis-10.txt (work in progress), May
2004.
[5] Durand, A., Requirements for assisted tunneling, draft-ietf-
v6ops-assisted-tunneling-requirements-00.txt (work in progress),
June 2004.
[6] Palet, J., Analysis of IPv6 Tunnel End-point Discovery
Mechanisms, draft-palet-v6ops-tun-auto-disc-01.txt (work in
progress), June 2004.
[7] Wasserman, M., Recommendations for IPv6 in 3GPP standards, RFC
3314.
[8] Loughney, J., IPv6 Node Requirements, draft-ietf-ipv6-node-
requirements-10.txt (work in progress), August 2004.
[9] IAB, IESG, IAB/IESG Recommendations on IPv6 Address Allocations
to Sites, RFC 3177.
[10] Savola, P., Security Considerations for 6to4, draft-ietf-v6ops-
6to4-security-04.txt (work in progress), July 2004.
[11] Nikander, P., IPv6 Neighbor Discovery (ND) Trust Models and
Threats, RFC 3756.
Nielsen, et. al. [Page 12]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
Appendix A Out of Scope
[Editor's Note: This appendix can be removed in a future revision of
this document]
The following issues have been considered as being out of scope of
this work.
DNS:
DNS registration of the IPv6 addresses allocated to dual stack nodes
while deploying Zero-configuration tunneling for IPv6 connectivity.
Mobile IPv6:
Support of Mobile IPv6 usage over the tunnel-link; here under
potential mechanisms required to support MIPv6 movement detection as
well as fast tunnel set-up for Mobile IPv6 session survivability.
Appendix B Open Issues
[Editor's Note: This appendix can be removed in a future revision of
this document]
Allow NATs that support proto-41 forwarding:
Should the no NATs assumption be relaxed to allow only NATs which
support proto-41 forwarding ?
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 IETF's procedures with respect to rights in IETF Documents can
be found in RFC 3667 (BCP 78) and RFC 3668 (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.
Nielsen, et. al. [Page 13]
INTERNET-DRAFT Zeroconf Tunneling Goals August, 2004
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.
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.
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
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.
This Internet-Draft expires February 18, 2005.
Nielsen, et. al. [Page 14]