Internet Engineering Task Force J. Palet
Internet-Draft M. Diaz
Expires: April 24, 2005 Consulintel
October 24, 2004
IPv6 Tunnel End-point Automatic Discovery Mechanism
draft-palet-v6ops-solution-tun-auto-disc-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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.
This Internet-Draft will expire on April 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Tunneling is commonly used by several IPv6 transition mechanisms. To
be able to automate setting up tunnels, one critical component is a
solution to automatically discover the tunnel end-point (TEP) for the
transition mechanism.
This memo proposes a solution for discovering the IPv6 TEP in a
simple an efficient way.
Palet & Diaz Expires April 24, 2005 [Page 1]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview and Rationale . . . . . . . . . . . . . . . . . . . . 4
3. Solution Implementation . . . . . . . . . . . . . . . . . . . 4
3.1 SRV RR . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 A/CNAME RR for Unicast . . . . . . . . . . . . . . . . . . 5
3.3 Shared Anycast . . . . . . . . . . . . . . . . . . . . . . 6
4. Solution Description . . . . . . . . . . . . . . . . . . . . . 6
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 ISP offering transition service(s) with SRV support on
its DNS server . . . . . . . . . . . . . . . . . . . . . . 8
5.2 ISP offering transition service(s) without SRV support
on its DNS server . . . . . . . . . . . . . . . . . . . . 9
5.3 ISP offering transition service(s) by means of third
parties . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 ISP offering transition service(s) only to own
customers . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5 ISP offering transition service(s) to external users . . . 10
5.6 ISP does not offer transition service at all . . . . . . . 10
5.7 Increased Scalability and Automation . . . . . . . . . . . 11
6. Alternative DHCP-based Solution . . . . . . . . . . . . . . . 11
7. Service Names for Transition Mechanisms . . . . . . . . . . . 12
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
12.2 Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Palet & Diaz Expires April 24, 2005 [Page 2]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
1. Introduction
During the IPv6 transition stage, it is foreseen that different
transition mechanisms are used. Most of them are tunnel-based and it
is critically important to ensure that the setup of the IPv6
connectivity is simple, so that it can be done also by non-technical
users, or even completely transparently, without the user recognizing
that IPv6 connectivity has been obtained.
A critical piece in the automated set-up is discovering the tunnel
end-point (TEP), also known as tunnel-server (TS), for the transition
mechanism that will be used by the client (or rather, their operating
system). Note that the tunnel end-point at the server side (TS)
typically also needs to have a mean to configure the client (tunnel)
end-point, but that is assumed to be transition mechanism specific,
and beyond the scope of this memo.
In this memo an elegant and simple solution for the TEP
auto-discovery is described, which fits in all the scenarios analyzed
in [1]. The solution offers the following features:
1. It is simple.
2. It can be easily deployed.
3. It is scalable.
4. It is topologically correct: Provides the nearest TEP to the user
in terms of IP hops.
5. Applies to all the existing transition mechanisms (and possibly
future ones), without any need for modifying them.
6. It is based on a combination of DNS and anycast (shared unicast
according to some terminology [2]) approach.
7. It offers certain degree of redundancy: It would work if either
the DNS or the anycast support fail.
8. It offers load balancing capability in order to share all the
known TEPs among all the clients willing to get IPv6 connectivity
through them.
9. It is fast and does not add significant overhead into the
transition mechanism setup process.
Palet & Diaz Expires April 24, 2005 [Page 3]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
2. Overview and Rationale
As pointed out at [1], the DNS is globally deployed and easy to use.
By means of prefixing the search path one can look up for a specific
service that is a specific TEP or transition mechanism server [3].
On the other hand, shared anycast is also a very useful approach
since it can globally identify a specific service (TEP or transition
mechanism). It is even easier and simpler than the DNS approach.
However anycast routes not always are well configured and stable, so
connection with the server belonging to an anycast group might not be
always possible, which means that is not necessarily the most
topologically correct. Moreover, consecutive datagrams sent from the
same host towards the same anycast address have no guarantee at all
that they are going to be delivered to the same anycast node.
For this reason, the anycast approach is only considered as a
complementary backup solution when prefixing the search path on DNS
has negative replies.
In addition, both approaches offer the possibility of pointing
directly to the TEP or alternatively to an intermediate node (i.e.
Tunnel Broker, TB) where to start the signaling handshake for setting
up the tunnel.
The idea that the auto-discovery solution exploits is that the client
willing to use a transition mechanism will first make one or several
DNS queries. The DNS will redirect to a TEP (or alternatively a TB
if more sophistication is required) located within the ISP or a third
party (other near ISP, roaming TEP service, etc.), if possible.
Alternatively, the DNS could also reply with an anycast address for
the searched TEP.
The solution consequently makes use of existing protocols, not
requiring modifications or any new protocol.
Details of how the DNS queries are made and how the prefix search
path is used are presented below.
3. Solution Implementation
The solution requires the implementation, at the ISP willing to offer
the service, of one or several new configurations of existing
services (namely DNS and anycast), as explained in the following
sub-sections.
Note that the solution will work with just of those configurations,
but all them together provide a more complete approach, which is
Palet & Diaz Expires April 24, 2005 [Page 4]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
better explained looking at the Case Studies section.
For the client is required that the three are actually implemented,
in the sequence below introduced, so the client will always succed,
regardless of what the ISP to which they are connected actually has
configured.
3.1 SRV RR
The DNS server of the ISP deploying a specific transition mechanism
should use SRV RR to announce the transition mechanism service.
According to [4] the SRV RR for a specific transition mechanism
should have the following format:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Please refer to [4] for a detailed explanation of each field in DNS
SRV RRs.
The service name for the auto-discovery purpose should be
standardized for each transition mechanism.
_transition-mechanism_srv._protocol.ispname.com
(assuming that the domain name of a ISP is ispname.com).
For example the records for 6in4, tsp, teredo, isatap and 6to4 would
result: _6in4_srv._ipv4.ispname.com, _tsp_srv._tcp.ispname.com,
_teredo_srv._udp.ispname.com, _isatap_srv._ipv4.ispname.com,
_6to4_srv._ipv4.ispname.com, etc.
Some illustrative examples of specific transition mechanisms
configured as SRV RRs in the DNS server are:
_6to4_srv._ipv4 SRV 0 1 10000 server1.ispname.com
_tsp_srv._tcp SRV 1 2 80 server2.ispname.com
_teredo_srv._udp SRV 2 1 3456 server3.ispname.com
3.2 A/CNAME RR for Unicast
A standardized A/CNAME RR for each supported transition mechanisms
within the domain of the ISP, using the same nomenclature as
introduced in the previous section, in the form:
_transition-mechanism_srv._protocol.ispname.com
Palet & Diaz Expires April 24, 2005 [Page 5]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
(assuming that the domain name of a ISP is ispname.com).
For example the records for 6in4, tsp, teredo, isatap and 6to4 would
result: _6in4_srv._ipv4.ispname.com, _tsp_srv._tcp.ispname.com,
_teredo_srv._udp.ispname.com, _isatap_srv._ipv4.ispname.com,
_6to4_srv._ipv4.ispname.com, etc.
Note: The use of the underscore character minimizes the probability
of conflict with DNS names already defined.
3.3 Shared Anycast
Each transition mechanism could have assigned and implemented a
shared anycast address, such as in the case of the 6to4 transition
mechanism [5].
The anycast prefix/address for each transition mechanism is listed
below (TBD by IANA):
Transition Mechanism Anycast Prefix/Adddress
TBD
4. Solution Description
The ideal situation is to implement all the points indicated in the
previous section. Under that scenario, the auto-discovery mechanism
would offer the best functionality and all the features described
above.
However, it is not mandatory that all them are fulfilled in order to
provide a functional auto-discovery mechanism, but at least one must
be implemented. In this way the auto-discovery mechanism will work
during all the deployment stages (auto-discovery not yet
standardized, auto-discovery already standardized but less deployed,
auto-discovery highly deployed). As many are implemented, more
functional the auto-discovery mechanism is.
When looking for a specific TEP within the ISP the user belongs to,
the first step is always the same because the user does not know (and
neither has to know) which is the transition mechanism deployment
status within its ISP, so the application/stack always query firstly
for a DNS SRV RR to its ISP DNS server.
To do that, the ISP's domain name is essential for prefixing the DNS
search path, so the client (or rather the operating system) firstly
learns the domain name of the ISP. There are several ways to do it,
but in general it will be learned by making NS RR queries to the DNS.
Palet & Diaz Expires April 24, 2005 [Page 6]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
The ISP's domain name will be the base string for the prefixing of
the DNS search path. Once the client has discovered it, a first
attempt to find the TEP of the specific transition mechanism is made
by building a SRV RR query (i.e. _tsp_srv._tcp.ispname.com) to the
DNS server belonging to the ISP.
Next it is shown an example of how the DNS SRV RRs would be used to
query the ISP DNS server. To discover the specific TEP within the
ISP domain (say, ispname.com), the client (rather the operating
system) makes a DNS query [6][7] for
QNAME=_teredo_srv._udp.ispname.com, QCLASS=IN, and QTYPE=SRV
If the DNS server matches the query, it returns the proper reply with
all the possible targets defined for that query, so the client will
receive a list of DNS SRV RRs in a DNS reply, which gives all the
teredo TEPs in the ISP domain ispname.com, such as:
;; Priority Weight Port Target
_teredo_srv._udp.ispname.com IN SRV 0 0 4500 tep1.ispname.com
_teredo_srv._udp.ispname.com IN SRV 0 1 4000 tep2.ispname.com
_teredo_srv._udp.ispname.com IN SRV 1 0 5000 host.other_ispname.com
_teredo_srv._udp.ispname.com IN SRV 2 0 5000 tepnode.other-domain.com
When there are more than one TEP, all of them could be assigned with
different priority and weight parameters in order to do load
balancing. Even some of them could be located outside the ISP. The
client will try all the obtained TEP according to the SRV RR
information (priority and weight) until it gets connected to one of
them. At this point the auto-discovery function ends.
If no DNS SRV RR reply is obtained (either because the DNS
administrator did not created DNS SRV RR entries for the requested
transition mechanism or either the DNS server or client resolver has
not SRV RR support), then an A/CNAME query is built by the client by
appending the standardized service name to the ISP domain name in
accordance with the what has been indicated at the "A/CNAME RR for
Anycast" section (i.e. _teredo_srv._udp.ispname.com).
Follows an example of how the DNS A/CNAME RRs would be used to query
the ISP DNS server. To discover the specific TEP within the ISP's
domain (say, ispname.com), the client (rather the operating system)
makes a DNS query [6][7] for QNAME=_teredo_srv._udp.ispname.com,
QCLASS=IN, and QTYPE=A or QTYPE=CNAME.
If there is a TEP deployed within the ISP (or a third party one),
then the DNS reply redirects the client to it and the auto-discovery
function ends in this point.
Palet & Diaz Expires April 24, 2005 [Page 7]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
Finally if there is not a valid A/CNAME RR matching the client query,
then the client will directly refer to the standardized "Shared
Anycast" address regarding the searched TEP. This allows the
provision of the service, for free, by third parties, when the own
ISP does not provide it (i.e. nomadic users), and doesn't require
any configuration in the ISP infrastructure. In this point the
auto-discovery function ends.
Although by using the standardized shared anycast address the client
always will contact to one TEP (assuming BGP routes are well
configured, it could be within the own-ISP infrastructure), the use
of the shared anycast address is preferred as the last option after
DNS SRV RR and DNS A/CNAME RR fails. This is because by means of DNS
RR, administrators will always configure nearest TEP hosts (within
the client ISP) for own-customers and load balancing can be better
done (in case of DNS SRV RR). Consequently, the shared anycast
option is used only as backup solution and also to provide service to
external users.
5. Case Studies
In order to clarify the behavior of this solution, some case studies
are presented below. It also shows how flexible is the solution and
how it can be used depending on the deployment stage at the ISP or
even its willingness to provide service only to own-customers or
external ones.
5.1 ISP offering transition service(s) with SRV support on its DNS
server
Many ISPs could offer IPv6 transition service(s) by deploying one or
several TEPs in its own infrastructure. It is also possible that
ISPs are interested to offer IPv6 transition mechanisms by means of
third party agreements or even through well known and convenient
nearby TEPs or which are free of charge.
In this case, the ISP could setup the DNS server with SRV RRs with
the "Target" parameter pointing be the TEPs deployed either inside
that ISP or the third party one. Several SRV RRs can be configured
for each specific transition mechanism service available.
If the ISP DNS server has SRV RRs matching the client query, then it
will reply with all the SRV records matching that query.
The "Priority" parameter of the SRV record could be used to
prioritize the own TEPs. If the higher priority TEP does not
respond, the client will attempt the next one, and so on.
Palet & Diaz Expires April 24, 2005 [Page 8]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
Some load balancing among TEPs is possible by using the "Weight"
field as suggested by [4].
The standardized shared anycast address for each specific mechanism
TEP could be added as target to the DNS SRV RR. In that case it
should have the lowest priority in order to redirect the client
always to local TEP as a first option.
5.2 ISP offering transition service(s) without SRV support on its DNS
server
Even if unusual is possible that the DNS servers doesn't support SRV
RR or that the ISP does not wish to configure SRV RR, for whatever
reason. Even do, the ISP may be interested in offering transition
services to its customers, and several TEPs, for different transition
mechanism will be deployed.
In this case the best solution for announcing local TEPs within the
ISP is by means of DNS A/CNAME RR. Clients will always try to get a
valid DNS SRV RR reply, but once it fails a valid DNS SRV A/CNAME
will be queried.
However, in this case the load-balancing feature is somehow limited,
based only on round-robin RR techniques, according to the
capabilities of the DNS server.
5.3 ISP offering transition service(s) by means of third parties
In initial early deployment stages, it is possible that ISPs can not
offer this service by themselves (either because business
considerations or because lack of resources, knowledge, etc.)..
However, they can agree with third parties for offering the service
to theirs customers. They can even facilitate their customers the
auto-discovery of free TEPs located in other domains.
In this case, they can proceed as already indicated in the previous
cases which mention how a third party TEP can be announced by the
DNS.
5.4 ISP offering transition service(s) only to own customers
The solution indicated in the previous cases is available to any
client that use the a DNS server which has been configured to
advertise the TEPs, even to external users (non-customers) using that
DNS server.
If an ISP wants to ensure that only own-customers automatically
discover the advertised TEPs, it could configure the DNS server(s) to
Palet & Diaz Expires April 24, 2005 [Page 9]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
send different replies (views), either DNS SRV or A/CNAME RRs, based
on the IP address of the incoming queries.
According to this, a SRV or A/CNAME RR query coming from a customer
(the IP will belong to the ISP allocations), could have a reply
containing the information regarding the requested TEPs deployed
within the ISP, the TEPs deployed by associated third parties, the
anycast address of the TEP or any combination of these options. On
the other hand, if the same query is coming from outside the ISP
network, then the DNS reply could only contain the TEPs deployed by
associated third parties or the anycast TEP or nothing.
Unlimited configurations are possible. This view functionality
strongly depends on the DNS server implementation that is being used
within the ISP.
Similarly the anycast advertising can be limited by proper
configuration of BGP, in order to avoid the TEPs being automatically
discovered by non-customers.
Avoiding the automatic discovery of the TEPs (by means of either DNS
or anycast) will actually not avoid them being used, but only its
auto-discovery, because they can be manually discovered/configured by
the users. But is also possible to limit the access to the TEPs by
means of filtering options, for example, to avoid any communication
being initiated to them by IP addresses not belonging to that ISP.
5.5 ISP offering transition service(s) to external users
If an ISP is willing to offer transition service(s) to external
customers, the best option for facilitating the auto-discovery of the
TEPs, is the configuration of the "Shared Anycast" as already
previously described, for each of the transition mechanism supported.
5.6 ISP does not offer transition service at all
In case an ISP does not deploy any transition mechanisms, and wish no
support their customers for using external services, they may
auto-discover available TEPs as indicated in the previous case.
In this case, the client willing to use a specific TEP firstly will
try to get a valid DNS SRV RR reply. However it will fail because
the ISP DNS server will not have any entry for it. Once it fails, a
DNS SRV A/CNAME will be also queried, which also will fail due to the
same reason. This is the expected behavior of the auto-discovery
mechanism and the reason for the Shared Anycast option. So, after
both types of DNS queries have failed, client will try the
standardized shared anycast address to get connected to the required
Palet & Diaz Expires April 24, 2005 [Page 10]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
TEP, which will be located out the ISP network.
The only requirement for this to actually work, is that the ISP
routes to the standardized shared anycast addresses have to be
allowed within the ISP, so the foreign TEPs are reachable. This is
currently a the normal situation, fulfilled by most of the ISPs, as
proven with the 6to4 anycast address [5].
5.7 Increased Scalability and Automation
In order to provide a more automated service, or even increased
scalability, a "Tunnel End-Broker" (TEB) service could be defined and
deployed.
The basic idea is to have a broker server (for instance
_teb_srv._ipv4.ispname.com) that will add more sophistication to the
system, but also increase the complexity of the implementation. In
this case, the transition mechanism will require a signaling higher
layer, that could also provide authenticated transition services and
enhanced roaming features.
In this scenario, the client will always try first _teb_srv._ipv4
(SRV, A/CNAME) or the corresponding anycast address, automatically
discover the adequate transition mechanism and the correct TEP, and
then pass the information to the transition mechanism itself to
establish the tunnel.
At this way, the auto-discovery may be complemented with the
auto-transition as described in [8].
6. Alternative DHCP-based Solution
Although the use of DHCP options to provide the TEP [9] has some
drawbacks, as analyzed in [1], it is proven that in some scenarios it
is useful, so it could be considered as a backup solution under
certain scenarios when communication with the specific TEP is not
possible due to whatever reason.
Scenarios where DHCP applies are typically within enterprise
networks, and users could use the information provided by the DHCP
server to contact a 6in4 TEP.
In this way, DHCP is an alternative basically when the enterprise
wish to ensure a managed transition related to the DHCP usage,
instead of the ISP provision, and has no control over DNS and/or BGP
configurations.
Palet & Diaz Expires April 24, 2005 [Page 11]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
7. Service Names for Transition Mechanisms
This section list the transition mechanisms and the service names to
be used:
Transition Mechanism Service Name
6in4 (RFCxxxx) 6in4
tsp (RFCxxxx) tsp
teredo (RFCxxxx) teredo
isatap (RFCxxxx) isatap
6to4 (RFCxxxx) 6to4
... ...
TBD.
8. Conclusions
In order to take advantage of the auto-discovery solution, the
configuration scripts of the transition mechanisms should use the DNS
RRs introduced in this document, always preferring SRV versus
A/CNAME. Anycast could be used as the last option.
DNS views and filtering can be configured by ISPs to avoid the
auto-discovery working for non-customers and to avoid the access to
the TEPs by clients using IP addresses not belonging to the ISP.
Those ISPs willing to provide service to external users, should
properly configure Shared Anycast.
Can/should we use this document also for auto-discovering IPv4 in
IPv6 tunnels ? TBD.
9. Security Considerations
TBD.
10. IANA Considerations
Can we assign an anycast address for each transition mechanism ? TBD.
11. Acknowledgements
The authors would like to acknowledge inputs from Alvaro Vives, Pekka
Savola, Antonio Skarmeta and the European Commission support in the
co-funding of the Euro6IX project, where this work is being
developed.
Palet & Diaz Expires April 24, 2005 [Page 12]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
12. References
12.1 Normative References
12.2 Informative References
[1] Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for
Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work
in progress), June 2004.
[2] Hagino, J. and K. Ettican, "An analysis of IPv6 anycast",
draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in progress),
June 2003.
[3] Faltstrom, P. and R. Austein, "Design Choices When Expanding
DNS", draft-iab-dns-choices-00 (work in progress), October 2004.
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[5] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001.
[6] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[7] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[8] Palet, J. and M. Diaz, "Evaluation of IPv6 Auto-Transition
Algorithm", draft-palet-v6ops-auto-trans-01 (work in progress),
July 2004.
[9] Kim, P. and S. Park, "DHCP Option for Configuring IPv6-in-IPv4
Tunnels", draft-daniel-dhc-ipv6in4-opt-05 (work in progress),
October 2004.
Palet & Diaz Expires April 24, 2005 [Page 13]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
Authors' Addresses
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
Miguel Angel Diaz Fernandez
Consulintel
San Jose Artesano, 1
Alcobendas - Madrid
E-28108 - Spain
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
EMail: miguelangel.diaz@consulintel.es
Palet & Diaz Expires April 24, 2005 [Page 14]
Internet-Draft IPv6 Tunnel End-point Auto-Discovery Mechanism October 2004
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
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.
Palet & Diaz Expires April 24, 2005 [Page 15]