[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bump in the Wire w/ attachment
Here is a follow up to my previous mail the with Bump in the Wire
draft as an attachment.
Paul Moster
INTERNET-DRAFT P. Moster
draft-ietf-biw-00.txt L. Chin
D. Green
Category Informational
Expires: April 2007 October 2006
Bump-in-the-Wire IPv4/IPv6 Translator
<draft-ietf-biw-00.txt>
Status of this Memo
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 August 28, 2005.
This document is a product of the IPv6 Operations WG. Comments should be
addressed to the authors, or the mailing list at v6ops@ops.ietf.org.
P. Moster, et al. [Page 1]
INTERNET-DRAFT Expires: April 2007 October 2006
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This draft describes a technique for making an IPv4-only host into an
IPv4/IPv6 host by inserting a translation device in front of its
connection to the network. The translation device makes a "bump" in
the "wire" connecting the IPv4-only host to the IPv4/IPv6 network,
and serves as an IPv4/IPv6 proxy for the IPv4-only host on the
network. This technique is appropriate for legacy IPv4 hosts and
applications where IPv6 capabilities are required, but it is too
costly to upgrade the host software.
P. Moster, et al. [Page 2]
INTERNET-DRAFT Expires: April 2007 October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Address and Protocol Translation . . . . . . . . . . . . . . . 5
3. IPv4 Pass-through. . . . . . . . . . . . . . . . . . . . . . . 7
4. DNS ALG. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Stateless Address Autoconfiguration. . . . . . . . . . . . . . 9
6. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Applicability and Limitations. . . . . . . . . . . . . . . . . 10
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 15
P. Moster, et al. [Page 3]
INTERNET-DRAFT Expires: April 2007 October 2006
1. Introduction
Reliable, small, low cost single board computers are available that
can run a full suite of networking software and maintain high packet
forwarding rates. This makes it practical to put address and
protocol translation devices at the edge of the network, between
individual hosts and the networks to which they connect. This draft
describes such a translator, one that makes an IPv4-only host appear
to a dual network as an IPv4/IPv6 host. We call this a "bump-in-the-
wire" (BIW) translator, conjuring up the image of small device that
forms a bump in "wire" connecting a host to a network. In practice,
a BIW translator could also connect a host to a network using a
wireless interface.
______________
| |---[IPv6-only Host]
| |
[IPv4-only Host]---[BIW Translator]---| Dual Network |---[IPv4/IPv6 Host]
| |
|______________|---[IPv4-only Host]
A BIW translator intercepts packets moving between its host-side and
the network-side interfaces, translating IPv4 to IPv6 and vice versa.
The translator uses the Stateless IP/ICMP Translation Algorithm
(SIIT) [RFC2765], with some minor modifications. The translator
filters all DNS queries and replies through an application layer
gateway (ALG). The translator participates in IPv6 Stateless Address
Autoconfiguration (SLAAC) [RFC2462], and can act as a DHCP server and
client. The detailed operation of each of these functions is
described in this draft.
A BIW translator serves as the IPv4-only host's proxy, and behaves
identically to IPv4-only host it replaces, with the exception of
added IPv6 capability. Conversely, a BIW translator hides the dual
IPv4/IPv6 network from the IPv4-only host, making it appear to the
host as an IPv4-only network. Inserting a BIW translator between an
IPv4-only host and a dual IPv4/IPv6 network does not require changes
to the configuration of the network or the hosts that reside on it.
The IPv4-only host typically requires minor configuration changes to
use the translator as its proxy.
A BIW translator allows the IPv4-only host to continue to use IPv4
for communications with other IPv4-only hosts on the the network.
Specifically, it does not make an IPv4-only host into an IPv6-only
host.
P. Moster, et al. Section 1. [Page 4]
INTERNET-DRAFT Expires: April 2007 October 2006
2. Address and Protocol Translation
SIIT describes how IPv6-only nodes use a translator to communicate
with IPv4-only nodes through a predominantly IPv4 network. For a BIW
translator, the focus shifts. A legacy IPv4-only node uses a BIW
translator to communicate with IPv4 and IPv6 nodes in a mixed
network.
SIIT makes use of IPv4-mapped and IPv4-translated IPv6 addresses.
These IPv6 addresses have an IPv4 address embedded within them, so
there is an algorithmic translation from an IPv4-mapped or
IPv4-translated IPv6 address to an IPv4 address, and vice versa.
However, this type of address translation is not appropriate for a
BIW translator. It is unlikely that all IPv6 hosts with which the
translator communicates will have IPv6 addresses that contain
embedded IPv4 addresses. Instead, their IPv6 addresses are more
likely to be configured with SLAAC, with prefixes chosen for
effective route aggregation. As a result, a BIW translator maps IPv4
addresses to IPv6 addresses, and vice versa, using an an ancillary
mapping table. Each entry in the mapping table associates an IPv4
address with an IPv6 address.
A BIW translator needs a large, private pool of IPv4 addresses. Most
of the IPv4 addresses in the IPv4/IPv6 address mapping table are
drawn from this pool. In a SIIT translator, IPv6-only nodes acquire
a temporary IPv4 address to communicate with IPv4-only nodes. For a
BIW translator, it's reasonable to assume that the IPv4-only host has
a permanent IPv4 address assigned to it, and that this address is
available to the translator. However, a BIW translator needs an IPv4
address for each IPv6 node that the IPv4-only node communicates with.
These addresses are generally drawn from the IPv4 address pool.
The IPv4 address pool is filled with private [RFC1918] addresses.
Addresses taken from the pool are only visible on the host side of
the translator, so they need not be globally unique. Each translator
can reuse the same pool of private IPv4 addresses. As such, BIW
translators do not compete for scarce IPv4 public addresses to fill
their pools.
The address mapping table requires an entry for the IPv4-only host
that maps its IPv4 address to an IPv6 address. The host's IPv4
address is typically drawn from the private address pool. The host's
IPv6 address may be configured either by the administrator or SLAAC,
and is assigned to the translator's network-side interface.
The translator adds entries to the mapping table in response to the
following events:
P. Moster, et al. Section 2. [Page 5]
INTERNET-DRAFT Expires: April 2007 October 2006
- The DNS ALG adds an entry when the name server replies to an AAAA-
type query with an IPv6 address that is not already in the table.
The DNS ALG gets an IPv4 address from the pool, binds it to the IPv6
address of the target, and adds it to the mapping table.
- When the translator receives an IPv6 packet from the network side,
it checks if the mapping table contains the IPv6 source address in
the packet header. If it does not, the translator gets an IPv4
address from the pool, binds it to the IPv6 source address, and adds
it to the mapping table.
The translator's administrator can add entries to the mapping table.
This is appropriate, for example, when the legacy IPv4-only host does
not use a DNS server, but instead maps host names to IPv4 addresses
through a local database.
Once a mapping table entry is created, it persists indefinitely. The
administrator may delete mapping table entries. However, the IPv6
address space is much larger than the IPv4 address space, and any
size IPv4 address pool is subject to exhaustion. When the translator
needs an IPv4 address to make a new mapping table entry and the
address pool is empty, the translator picks the least recently used a
mapping table entry and deletes it. The IPv4 address in the deleted
entry is reclaimed and used in the new entry. A mapping table entry
is said to be "used" when it is referenced during translation.
A BIW translator modifies the checksums in TCP and UDP headers. In a
SIIT translator, the IPv4-to-IPv6 address translation algorithm
insures that the IPv4 and IPv6 addresses have the same 1's complement
sum, so the checksums of the original and translated packets are the
same. The IPv4 and IPv6 addresses in the address mapping table entry
usually won't have the same sum, so the checksums will be different.
To modify the checksum, the translator computes a checksum of the
IPv4 source and destination addresses, and another checksum for the
corresponding IPv6 addresses. In the IPv4 to IPv6 direction, the
translator subtracts the IPv4 address checksum from the TCP or UDP
checksum, then adds the IPv6 address checksum. The order is reversed
in the IPv6 to IPv4 direction.
The translator performs address and protocol translation on the
"invoking packet" contained in an ICMP or ICMPv6 error message. This
include checksum modification, when the invoking packet includes and
TCP or UDP header.
P. Moster, et al. Section 2. [Page 6]
INTERNET-DRAFT Expires: April 2007 October 2006
3. IPv4 Pass-through
A BIW translator provides an IPv4 pass-through capability that allows
the IPv4-only host to communicate with other IPv4-only hosts in the
network. When the translator receives a packet from the host-side
interface, it checks if IPv4 destination address is bound to an IPv6
address. If it is, the packet is translated to IPv6. If the address
is not in the mapping table, but is part of the private IPv4 address
pool, the translator discards the packet and responds to the host
with an ICMP host unreachable error message. Otherwise, the
translator passes the packet through to the network-side interface
without protocol translation.
When the IPv4-only host is assigned a private address, IPv4 address
translation is needed to support pass-through. In a typical
configuration, the host's original global IPv4 address is assigned to
the translator's network-side interface, and the host is assigned an
address from the translator's private pool. For packets passing from
the host to the network, the translator changes the source address
from the private to the global address. For packets passing from
from the network to the host, the translator changes the destination
address from the global to the private address. The translator also
modifies the TCP and UDP checksums to adjust for the change in
addresses.
4. DNS ALG
A BIW translator has a DNS application layer gateway (ALG) that
intercepts queries from the IPv4-only host and replies from the
server. The DNS ALG makes changes to queries and replies and updates
the IPv4/IPv6 address mapping table. The DNS ALG only accepts
queries from the host-side interface and replies from the network-
side interface.
Address queries from the IPv4-only host may contain names that refer
to IPv4-only, IPv4/IPv6, or IPv6-only hosts. When the translator's
DNS ALG receives an A-type query (QTYPE=A in RFC1035 nomenclature)
from the host, it processes the query as follows:
- If the translator is connected to an IPv4-only network, it forwards
the query to the server unchanged.
- If the translator is connected to a dual IPv4/IPv6 network, it
sends two queries to the server, an A-type and an AAAA-type.
P. Moster, et al. Section 4. [Page 7]
INTERNET-DRAFT Expires: April 2007 October 2006
- If the translator is connected to an IPv6-only network, it changes
the A-type query to an AAAA-type query and sends it to the server.
- If the translator has no network-side connection, it replies to the
host with an error message.
The translator infers the IPv4 and IPv6 capabilities of the network
by the addresses assigned to its network-side interface using to the
following rules:
- If both IPv4 and IPv6 addresses are configured, the translator is
attached to an dual IPv4/IPv6 network.
- If only an IPv4 address is configured, the translator is attached
to an IPv4-only network.
- If only an IPv6 address is configured, the translator is attached
to an IPv6-only network.
- If no addresses are configured, the translator is not connected to
the network.
IPv4 and IPv6 addresses can be assigned to the translator's network-
side interface either by the administrator or through an automatic
configuration process like SLAAC or DHCP.
When the translator is connected to a dual IPv4/IPv6 network, the DNS
ALG may receive replies to both its A-type and AAAA-type queries.
When this happens, the translator discards one of the replies based
on a configuration switch. This switch has the effect of giving
preference to IPv4 or IPv6 for nodes that can communicate using
either protocol. When the DNS ALG receives an AAAA-type reply from
the server, and either no A-type reply is received, or the A-type
reply is discarded, the DNS ALG changes the reply type from AAAA to A
before sending it to the host.
The DNS ALG checks the Answer and Additional sections of all replies
for AAAA-type resource records (RRs) and converts them to A-type RRs.
The translator examines all replies since AAAA-type RRs could be
returned for in response to several query types. For each AAAA
record in the reply, the DNS ALG checks if the IPv6 address is in the
IPv4/IPv6 mapping table. If the IPv6 address is not in the table,
the DNS ALG gets an IPv4 address from the translator's pool and makes
a new entry. In either case, the DNS ALG replaces AAAA-type record
with an A-type record containing the IPv4 address. When all RRs in
the reply have been processed, the translator forwards the converted
reply to the host.
P. Moster, et al. Section 4. [Page 8]
INTERNET-DRAFT Expires: April 2007 October 2006
The DNS ALG also processes reverse lookup queries from the host.
When the DNS ALG receives a PTR-type query and the name ends in IN-
ADDR.ARPA, it checks if the IPv4 address is in the translator's
IPv4/IPv6 address mapping table. If it is, the DNS ALG changes the
name to the corresponding IPv6 address with the IP6.ARPA suffix and
forwards the request to the server. If the address is in the
translator's IPv4 address pool, but not the mapping table, the the
DNS ALG replies with a name error. Otherwise, the query is forwarded
to the server unchanged.
This process is reversed when the DNS ALG receives a reply to a PTR-
type query from the server. If the name ends in IP6.ARPA, IPv6
address will be in the translator's IPv4/IPv6 mapping table. The DNS
ALG changes the name to the corresponding IPv4 address and sends the
reply on to the host.
Since the name server may be an IPv4-only host, an IPv4/IPv6 host, or
an IPv6-only host, the DNS ALG can use either IPv4 or IPv6 to
communicate with the server. The DNS ALG uses only IPv4 to
communicate with the host.
5. Stateless Address Autoconfiguration
A BIW translator supports IPv6 Stateless Address Autoconfiguration
(SLAAC). A practical translator requires two IPv6 addresses: one
address represents the IPv4-only host, while the other represents the
translator itself. The latter address allows the translator to send
and receive packets that are used for administration and maintenance.
These packets aren't translated to IPv4, and are not forwarded to the
IPv4-only host.
To participate in SLAAC, the translator forms IPv6 link-local
addresses for both itself and the IPv4-only host. Each link-local
address requires a unique interface identifier. The translator
typically forms its own interface identifier from the MAC address of
the network-side interface. For the IPv4-only host, the translator
forms the interface identifier from the host's MAC address. While a
BIW translator could, in principle, use the MAC address of its host-
side interface to form the host's interface identifier, it's safer to
use the host's MAC address. This is because some single board
computers share a single MAC address between all network interfaces.
The method used to determine the host's MAC address depends on the
configuration. If the host is a DHCP client, the translator's DHCP
server knows the host's MAC address. If the host is not a DHCP
P. Moster, et al. Section 5. [Page 9]
INTERNET-DRAFT Expires: April 2007 October 2006
client, the translator actively probes the host using ARP to
determine its MAC address.
The translator forms global IPv6 addresses by combining interface
identifiers with prefixes contained in a router advertisement
message. When the host's IPv6 global address is formed, the
translator adds an entry to its IPv4/IPv6 address mapping table. The
entry consists of the host's IPv4 address and the global IPv6 address
formed through the SLAAC process. Note that the IPv4-only host's
link-local address is not added to the translator's IPv4/IPv6 address
mapping table. Packets sent to either of the link-local addresses
are never translated to IPv4 or sent to the IPv4-only host. Instead,
they are processed locally by the translator.
6. DHCP
When the IPv4-only host is a DHCP client, a BIW translator acts as a
DHCP server on the host-side interface and a DHCP client on the
network-side interface. As a DCHP server, the host configuration
parameters that the translator supplies to the host need not match
those that the translator obtains from the network. For example, the
translator typically supplies an IPv4 address from its private pool,
and a subnet mask that includes the entire pool. This has the effect
of putting all the IPv4 addresses in the pool, and the IPv6 hosts
they represent, on the same subnet as the IPv4-only host. The
translator also sets the host's default router and name server
addresses to IPv4 address of its host-side interface.
On the network-side, the translator obtains IPv4 host configuration
parameters from a DHCP server. The translator uses the parameters it
obtains from the the network to configure its network-side interface.
The translator uses the same parameters that the host would have used
were it directly connected to the network.
7. Applicability and Limitations
A BIW translator is appropriate for legacy IPv4-only systems, where
it's too costly or time consuming to upgrade the application and
operating system software to support IPv6. A BIW translator gives
these hosts access to advanced IPv6 features like autoconfiguration,
mobility and security. While these legacy systems will inevitably be
discarded or upgraded to support IPv6, a BIW translator extends their
lifetime and reduces dependence on maintaining IPv4 connectivity.
P. Moster, et al. Section 7. [Page 10]
INTERNET-DRAFT Expires: April 2007 October 2006
Bump-in-the-stack [RFC2767] and Bump-in-the-API [RFC3338] address the
problem of host applications that are not aware of IPv6, but which
need to communicate using IPv6. However, these techniques require
the development of new networking software for the host's operating
system. This may not be cost effective, particularly for older
operating systems that do not support IPv6. The software developed
to make a BIW translator can support any legacy operating system or
application. The BIW software need not be ported to each legacy
operating system that it supports, since it runs on its own single
board computer with its own modern operating system. As IPv6
protocols evolve and new protocols are developed, the BIW software
can be upgraded with no impact on the legacy operating system.
A BIW translator is similar to the Network Address Translator -
Protocol Translator (NAT-PT) described in [RFC2766]. The limitations
of NAT-PT have been thoroughly investigated. However, a translator
at the edge of the network, serving a single host, suffers from few
of the problems faced by one in the center of the network. For
example, a NAT-PT introduces network topology constraints and has
problems with scalability. It is also a single point of failure and
an inviting target for denial of service attacks. These are not
problems for a BIW translator.
A BIW translator has a DNS ALG that is similar to the one described
in NAT-PT. The DNS ALG is cited as the source of several problems
with NAT-PT. However, the DNS ALG in a BIW translator is less
troublesome, since it only handles queries generated by a single
IPv4-only host. The DNS ALG in a NAT-PT must handle all queries that
pass between the IPv4 and IPv6 domains.
A BIW translator is subject to the same basic limitations that all
address and protocol translators face. These have been described
thoroughly in several RFCs and are only summarized here.
- A BIW translator disrupts protocols that embed the IP address in
the packet payload, like FTP. A BIW translator requires a separate
ALG for each of these protocols.
- Information is lost when translating from IPv6 to IPv4. For
example, there is no flow label field in IPv4. This may not be a
significant problem, since the translator is co-located with the
IPv4-only host it serves. Packets translated from IPv6 to IPv4 only
traverse the private link between the translator and the legacy host.
For packets translated from IPv4 to IPv6, the translator can create
an appropriate flow label.
- Packets using IPsec AH (in transport and tunnel mode) and IPsec ESP
P. Moster, et al. Section 7. [Page 11]
INTERNET-DRAFT Expires: April 2007 October 2006
(in transport mode) can't be translated. However, for legacy
IPv4-only hosts that don't support IPsec, a BIW translator is a good
place to add it. The BIW translator would terminate security
associations.
- A BIW translator is vulnerable to a DoS attack on its address pool.
It is a less inviting target than a NAT-PT, or other central
resource, since the attack could only succeed in denying service to a
single host.
- IPv6 extension headers, like those used for IPv6 mobility support,
can't be translated to IPv4. As with IPsec, a BIW translator is a
good place to add mobility support to a legacy host that has none.
The authors have demonstrated a BIW translator that adds mobility to
a legacy IPv4-only host without mobility. It operates as either
mobile or correspondent node, and supports route optimization and
signaling security.
- The translator may break an IPv4/IPv6 address binding to reclaim an
IPv4 address. This can leave the IPv4-only host unable to
communicate with the IPv6-only host on the network side of the broken
binding. For example, the DNS resolver on the IPv4-only host may
cache a name-to-IPv4-address binding. If the translator breaks the
associated IPv4-to-IPv6 address binding, while the resolver binding
persists in host's cache, the translator will discard packets that
the host sends to the unbound IPv4 address. The binding would be
recreated by a DNS query from the IPv4-only host or the receipt of
packet from the IPv6-only host, but these events may not happen.
For a NAT-PT or NAPT-PT at the Internet edge of an enterprise
network, binding persistence is a major problem, since it shares a
limited pool of global IPv4 addresses among a large group of
IPv6-only hosts. To make the most use of the scarce global IPv4
addresses, the NAT-PT maintains the bindings only as long as they are
needed. Unfortunately, it's difficult for the NAT-PT to accurately
determine how long the bindings are needed.
For a BIW translator, the binding persistence problem is less acute.
A BIW translator maintains bindings indefinitely, breaking them only
when the IPv4 address pool is empty. Since the pool is composed of
private addresses, it can be large. While "garbage" bindings will
eventually accumulate in the address mapping table, they will be
reclaimed by the least recently used replacement policy.
- The current BIW translator implementation does not support
translation of multicast packets. The authors plan further research
in this area.
P. Moster, et al. Section 7. [Page 12]
INTERNET-DRAFT Expires: April 2007 October 2006
8. Acknowledgments
The authors wish to thank Larry Levine of the US Army CERDEC for his
support. Ed Jankiewicz of SRI led the early development effort.
9. Security Considerations
A BIW translator is vulnerable to denial-of-service attacks.
Specifically, the IPv4 address pool could be depleted by a malicious
sender of IPv6 packets. When the translator receives and IPv6 packet
from the network side, it checks if there is an IPv4 address bound to
the IPv6 source address in the packet header. If there not, the
translator gets a new IPv4 address from the pool and binds it to the
IPv6 source address. The malicious sender could deplete the pool by
sending a sequence of packets to the translator, each with a
difference source address. In practice, the IPv4 address pool is
segmented, with separate regions reserved for bindings created by the
administrator, the DNS ALG, and arriving packets. The attack would
only deplete this last segment of the pool, leaving IPv6 hosts unable
to initiate communications with the IPv4-only host served by the
translator. The IPv4-only host could still initiate communications
with IPv6 hosts.
P. Moster, et al. Section 9. [Page 13]
INTERNET-DRAFT Expires: April 2007 October 2006
10. References
10.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot,
"Address Allocation for Private Internets", RFC 1597,
March 1994.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
10.2. Informative References
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2767] Tsuchiya, K., Higuchi, H., and Y. Atarashi,
"Dual Stack Hosts using the "Bump-In-the-Stack" Technique
(BIS)", RFC 2767, February 2000.
[RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. Durand,
"Dual Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338,
October 2002.
P. Moster, et al. Section 10.2. [Page 14]
INTERNET-DRAFT Expires: April 2007 October 2006
11. Authors' Addresses
Paul Moster
Datatek Applications, Inc.
Somerset, NJ
Phone: 732 667 1080
EMail: pcmoster@datatekcorp.com
Lorraine Chin
Datatek Applications, Inc.
Somerset, NJ
Phone: 732 667 1080
EMail: lchin@datatekcorp.com
Dave Green
Command Information
Herndon, VA
EMail: green@commandinformation.com
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
P. Moster, et al. Section 11. [Page 15]
INTERNET-DRAFT Expires: April 2007 October 2006
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
P. Moster, et al. Section 11. [Page 16]