IPv6 Operations Working Group A. Matsumoto
Internet-Draft T. Fujisaki
Intended status: Informational NTT
Expires: November 2, 2007 R. Hiromi
K. Kanayama
Intec Netcore
May 2007
Solution approaches for address-selection problems
draft-arifumi-v6ops-addr-select-sol-00.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 November 2, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
In response to address selection problem statement and requirement
documents, this document describes approaches to solutions and
evaluates proposed solution mechanisms in line with requirements. It
also examines the applicability of each solution mechanism from the
viewpoint of practical application.
Matsumoto, et al. Expires November 2, 2007 [Page 1]
Internet-Draft Address-Selection Solutions May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Proactive approaches . . . . . . . . . . . . . . . . . . . 3
2.2. Reactive approaches . . . . . . . . . . . . . . . . . . . 4
3. Solution approaches . . . . . . . . . . . . . . . . . . . . . 4
3.1. Obtain all information prior to communication (Most
Proactive) . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Requirements correspondence analysis . . . . . . . . . 5
3.1.3. Other issues . . . . . . . . . . . . . . . . . . . . . 6
3.2. Routing system assistance for address selection
(Proactive) . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Requirements correspondence analysis . . . . . . . . . 6
3.2.3. Other issues . . . . . . . . . . . . . . . . . . . . . 7
3.3. Trial-and-error approach (Reactive) . . . . . . . . . . . 7
3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Requirement correspondence analysis . . . . . . . . . 8
3.3.3. Other issues . . . . . . . . . . . . . . . . . . . . . 9
3.4. All-by-oneself approach (Most Reactive) . . . . . . . . . 9
3.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Requirement correspondence analysis . . . . . . . . . 9
3.4.3. Other issues . . . . . . . . . . . . . . . . . . . . . 10
4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 11
4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 11
4.2. Deployment Difficulty . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Matsumoto, et al. Expires November 2, 2007 [Page 2]
Internet-Draft Address-Selection Solutions May 2007
1. Introduction
One physical network can have multiple logical networks. In that
case, an end-host has multiple IP addresses. (e.g, in the IPv4-IPv6
dual-stack environment, in a site that uses both ULA [RFC4193] and
global scope addresses or in a site connected to multiple upstream
IPv6 networks.) For such a host, RFC 3484 [RFC3484] defines default
address-selection rules for the source and destination addresses.
Today, the RFC 3484 mechanism is widely implemented in major OSs.
However, many people, including us, have found that in many sites the
default address-selection rules are not appropriate for the network
structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic
cases that resulted from incorrect address selection.
Though RFC 3484 made the address-selection behavior of a host
configurable, typical users cannot make use of that because of the
complexity of the mechanism and their lack of knowledge about their
network topologies. Therefore, an address-selection
autoconfiguration mechanism is necessary, especially for the
unmanaged hosts of typical users.
REQ [I-D.ietf-v6ops-addr-select-req] document enumerates requirements
for address-selection mechanisms that enable hosts to perform
appropriate address selection automatically.
In the IETF mailing lists and in the internet-draft archives, some
mechanisms for solving address-selection problems have already been
proposed. This document describes possible design approaches for
solving address selection problems. After that, we try to put
together an overview as well as an analysis of how well the method
corresponds with the requirements.
2. Solution Design
There are two types of approaches that can control the behavior of
hosts in terms of the selection of destination address and source
address. The first type is proactive, where the host is given the
necessary information to decide the destination and source addresses
before the beginning of transmission. The other type is reactive,
where the host decides appropriate destination address and source
addresses through trial and error.
2.1. Proactive approaches
There can be two types of proactive approaches. One gives hosts all
the information for selecting destination and address and source
Matsumoto, et al. Expires November 2, 2007 [Page 3]
Internet-Draft Address-Selection Solutions May 2007
addresses beforehand. Under some circumstances, a lot of information
could be stored in hosts.
The other type informs hosts about which prefixes should be used in
the source address for the different destinations every time before
starting each connection.
2.2. Reactive approaches
In these approaches, the host does not have initial information for
address selection. It will try using different pairs of destination
and source addresses until the connection is established. When an
outage occurs, the host must detect it and try again with a new pair
of destination address and source address. Some reactive solutions
may use some kind of control message that enables the gateway to
indicate the outage.
3. Solution approaches
This section describes the evaluation of the four approaches to
finding solutions. The evaluation value has a 3-point scale for each
of 8 requirements in the requirement document. The meaning of the
points is as follows.
1 : bad
2 : fair
3 : good
About "Effectiveness", the score is 1 if the approach solves no
problematic cases described in the problem statement document, 2 if
it can handle at least one, and 3 if it solves every case.
3.1. Obtain all information prior to communication (Most Proactive)
3.1.1. Overview
In this approach, a host obtains everything needed to select
addresses at once prior to communication. A host receives all policy
information from a server beforehand. It then sets up communication
whenever it wants to. DHCPv6 and RA fall into this category as known
protocols. There is a reference document
[I-D.fujisaki-dhc-addr-select-opt] in which DHCPv6 is used for this
purpose.
This approach can take advantage of the RFC 3484 Policy Table, which
is already widely deployed. By distributing policies for the Policy
Table, you can auto-configure a host's address selection policy.
Matsumoto, et al. Expires November 2, 2007 [Page 4]
Internet-Draft Address-Selection Solutions May 2007
3.1.2. Requirements correspondence analysis
1. Effectiveness: 3
It can support all cases by using the policy table.
2. Timing: 3
All information for communication is in a host in advance.
Communication starts at once when it is necessary and the
communication process refers to local policy information, so it
exhibits good usability. Moreover, this leads to fewer overheads
than per-connection mechanisms.
3. Dynamic update: 3
Though it depends on what protocol is used to distribute the
policies, some mechanisms support information updates from the
server. Moreover, it is difficult to support dynamic network
changes and real-time updates in some specific protocols.
4. Node-specific behavior: 3
For distribution to individual hosts in the same segment, DHCPv6
can be used.
5. Application-specific behavior: 2
The policy table itself doesn't support application-specific
address selection. It can be done using the address selection
API. [I-D.chakrabarti-ipv6-addrselect-api]
6. Multiple interfaces: 2
If all interfaces belong to the same administration domain, it is
possible for the address-selection information to be controlled by
administrators of that domain. However, if not, routing
information and address selection policies are not always
equivalent between domains, and it is not possible to handle them.
7. Central control: 3
It can support central control. A site administrator or a service
provider can determine users' policy tables.
8. Route selection: 2
Current solutions, such as DHCPv6 and RA, do not have a mechanism
for cooperation with routing protocols. This could be done with
other techniques such as "source address based routing" or
"Default Router Preferences and More-Specific Routes" RFC4191.
[RFC4191]
Matsumoto, et al. Expires November 2, 2007 [Page 5]
Internet-Draft Address-Selection Solutions May 2007
3.1.3. Other issues
- The traffic volume will be equal to the number of policies.
- Hosts and servers need to support this function.
3.2. Routing system assistance for address selection (Proactive)
3.2.1. Overview
Fred Baker proposed this approach. A host asks the DMZ routers or
the local router which is the best pair of source and destination
addresses when the host has a set of addresses A and the destination
host has a set of addresses B. Then, the host uses the policy
provided by the server/routing system as a guide in applying the
response. He also proposed a mechanism that utilizes the ICMP error
message to change the source address of the existing session. This
point resembles Section 3.3 3484update mechanism, so the following
evaluation is based on only the first part of his proposal.
3.2.2. Requirements correspondence analysis
1. Effectiveness: 3
A routing system knows about information about paths toward the
destination and information about which of their prefixes should
be used. Therefore, it is possible to select an appropriate pair
of source and destination addresses.
2. Timing: 3
A routing system always has up-to-date routing information, so it
will be possible to provide suitable information whenever requests
come. However, the amount of information that the system must
handle is huge, so there will be cases where it takes time to
answer the request because appropriate information must be
retrieved from a huge database.
If any server or routing trouble occurs, the requester cannot get
the answer, and address selection will fail. This point is the
same in all systems that depend on other servers.
3. Dynamic update: 3
A routing system always has up-to-date routing information, and it
will be possible to provide suitable information whenever requests
come.
4. Node-pecific behavior: 3
Matsumoto, et al. Expires November 2, 2007 [Page 6]
Internet-Draft Address-Selection Solutions May 2007
Node-specific information can be provided if a server recognizes
individual nodes.
5. Application-specific behavior: 2
A routing system does not care about applications. Using address
selection API allows nodes to behave in an application-specific
way.
6. Multiple Interfaces: 2
If all interfaces belong to the same administration domain, it is
possible for the address-selection information to be controlled by
administrators of that domain. However, if not, routing
information and address selection policies are not always
equivalent between domains, and it is not possible to handle them.
7. Central Control: 3
It is possible to provide address selection information from one
source. However, because routing information changes dynamically,
it is difficult to control it in the way that administrators want.
8. Route Selection: 3
It is possible to give next-hop selection advice to a host. As
routers have routing information, it would seem to be easier for
routers to implement this function.
3.2.3. Other issues
- A host must consult the routing system every time it starts a
connection if the host does not have address selection information
for the destination host or if the information lifetime has
expired. This could be a possible scalability problem.
- The existing host/router OS implementation must be changed a lot.
In the existing TCP/IP protocol stack implementation, destination
address selection is mainly the role of the application and not
that of the kernel unlike source address selection. Therefore,
implementing this model without affecting applications is not so
easy.
3.3. Trial-and-error approach (Reactive)
3.3.1. Overview
M. Bagnulo proposed a new address selection method in his draft.
When the host notices that a network failure has occurred or packets
have been dropped somewhere in the network by, for example, an
ingress filter, the host changes the source address of the connection
to another source address.
Matsumoto, et al. Expires November 2, 2007 [Page 7]
Internet-Draft Address-Selection Solutions May 2007
Hosts may use some kinds of error messages, e.g, ICMP error messages,
from a network to detect that sent packets did not reach the
destination quickly.
The host stores a cache of address selection information so that the
host can select an appropriate source address for new connections.
For source address selection by the application that initiated a
communication, this method provides an ordered list of source
addresses for the destination address to the application.
3.3.2. Requirement correspondence analysis
1. Effectiveness: 2
This solution is not effective for the problem about IPv4 or IPv6
prioritization described in the problem statement document.
2. Timing: 2
Hosts should try to use all the available source addresses to the
maximum to find an appropriate source address. If the host tries
the next source address after the previous trial using another
source address has failed, it may take a long time because this
trial-and-error process lasts until the connection succeeds. If
the host does not use an error message from a network to detect a
connection error, it takes longer to wait for a time-out.
3. Dynamic update: 3
If hosts detect a connection failure using some reliable
mechanism, such like TCP or ICMP error messages, a connection
failure caused by some changes in the network will be detected
immediately by the hosts.
4. Node-specific behavior: 2
This solution does not have a function for node-specific behavior.
However, it is not impossible to implement by setting a packet
filter for each node at the gateways through which the packets
from nodes pass.
5. Application-specific behavior: 2
This solution does not have a function for application-specific
behavior. However, the mechanism of this approach does not
exclude address selection by each application.
6. Multiple interfaces: 3
Matsumoto, et al. Expires November 2, 2007 [Page 8]
Internet-Draft Address-Selection Solutions May 2007
If the protocol-stack or an application supports interface
selection and it tries to establish a connection by changing
addresses and also interfaces, it can find a working combination
of addresses and interface.
7. Central control: 2
The only way that a central administrator has to control the node
behavior is switching a filter on/off on the network. Therefore,
advanced control such as traffic engineering and QoS is almost
impossible.
8. Route Selection: 2
This solution does not refer to next-hop selection for the
transmission of a packet. So, it should be used with some routing
function such as RFC 4191 on the nodes.
3.3.3. Other issues
- A host must learn address selection information for each
destination host. Therefore, the number of cache entries could be
very large.
- The existing host/router OS implementation must be changed a lot.
In particular, changing the source address of the existing
connection is not so easy and has a big impact on the existing
TCP/IP protocol stack implementation.
3.4. All-by-oneself approach (Most Reactive)
3.4.1. Overview
shim6 was designed for site-multihoming. This mechanism introduces a
new address selection method for session initiation and session
survivability; it is documented in two drafts:
[I-D.ietf-shim6-locator-pair-selection] and
[I-D.ietf-shim6-failure-detection].
The shim6 host detects connection failures and changes the
destination and source addresses during the session.
In this document, we focus on address selection issues in the
connection initiation phase of shim6 and not on any other functions,
such as session survivability.
3.4.2. Requirement correspondence analysis
1. Effectiveness: 2
Matsumoto, et al. Expires November 2, 2007 [Page 9]
Internet-Draft Address-Selection Solutions May 2007
This solution is not effective for the problem about IPv4 or IPv6
prioritization described in the problem statement document.
2. Timing: 2
Hosts should try to use all the available source addresses to the
maximum to find an appropriate source address. If the host tries
the next source address after the previous trial using another
source address has failed, it may take a long time because this
trial-and-error process lasts until the connection succeeds. If
the host does not use error messages from a network to detect a
connection error, it takes longer to wait for a time-out.
3. Dynamic update: 3
It can reflect dynamically changing network, as far as it always
tries all possible addresses and next-hops.
4. Node-specific behavior: 2
This solution does not have a function for node-specific behavior.
However, it is not impossible to implement by setting a packet
filter for each node on the gateways through which the packets
from nodes pass.
5. Application-specific behavior: 2
The use of shim6 API [I-D.ietf-shim6-multihome-shim-api] allows
applications to override address selection behavior.
6. Multiple interfaces: 3
If the protocol-stack supports interface selection and it tries to
establish a connection by changing addresses and also interfaces,
it can find a working combination of addresses and interface.
7. Central control: 2
The only way that a central administrator has to control the node
behavior is switching a filter on/off on the network. Therefore,
advanced control such as traffic engineering and QoS is almost
impossible.
8. Route Selection: 2
This solution does not refer to next-hop selection for the
transmission of a packet. Therefore, it should be used with some
routing function such as RFC 4191 on the nodes.
3.4.3. Other issues
- The shim6 host performs address selection that reflects network
failures that have occurred between the source and destination
host.
Matsumoto, et al. Expires November 2, 2007 [Page 10]
Internet-Draft Address-Selection Solutions May 2007
- End hosts themselves can avoid network failure. There is no need
to modify or reconfigure routers in the path.
- A host must learn address selection information for each
destination host. Therefore, the number of cache entries can be
very large.
- The existing host OS implementation must be changed significantly.
4. Applicability Comparison
In the previous section, every approach scored "fair" or better for
every requirement. This means that every approach can meet the
demands of address selection. However, if you actually want to
choose one mechanism to solve your address selection problem, it is
important to figure out which approach is best suited to your
situation. This section tries to evaluate the applicability of each
approach from several aspects.
4.1. Dynamic-static and managed-unmanaged
First, we use two axes to evaluate the applicability of the four
approaches. One axis shows whether or not the network structure
changes dynamically and the other axis shows whether the site is
managed or unmanaged. In a managed network, by our definition, a
network administrator manages his or her network, routers, and hosts.
For example, an enterprise network is managed, whereas a home network
and a SOHO network are unmanaged.
static dynamic
<-------------------------------------------->
unmanaged ^ +----------+ +---------------------------+
| | | +-+--------------+ shim6 |
| | | | | | |
| | +--+-+-+------------+ | |
| | | | | | | | |
| | | | | | | | |
| | | | | +------------+-+------------+
| | | | | 3484update| |
| | +--+-+--------------+ |
| | | | |
| | | | |
| | Policy | | RouterAssist |
| | Dist | | |
| | | | |
| +----------+ +----------------+
Matsumoto, et al. Expires November 2, 2007 [Page 11]
Internet-Draft Address-Selection Solutions May 2007
managed v
PolicyDist:
- In a dynamic site, the policy table must be updated accordingly
and traffic for policy table distribution increases.
3484update:
- This is a slightly manageable than shim6 in that 3484update does
not change the paths of established connections dynamically.
- In a very dynamic site, the use of an address selection
information cache does not have a good effect. This results in
connection failure and may degrade usability badly.
- Even in a very static site, a host may try inappropriate addresses
or next-hops and experience connection failures.
RouterAssist:
- A host must send at least as many queries as the number
destination hosts. Therefore, in a static site, this method is
not optimal.
- In a very dynamic site, address selection information cache is no
help. If the cache function is not used, then connection failures
do not occur.
shim6:
- In a static site, shim6 is not desirable because of its connection
sequence overhead and timeout-wait for path exploration.
- In a managed site, shim6 is not easy to manage in terms of node-
specific address selection control and central control.
4.2. Deployment Difficulty
less more
<------------------------------------------->
policy-dist 3484update shim6 Fred
PolicyDist:
- What must be implemented is a distribution mechanism. The
existing protocols, such as RA and DHCP, can be used for this
purpose.
3484update:
Matsumoto, et al. Expires November 2, 2007 [Page 12]
Internet-Draft Address-Selection Solutions May 2007
- The protocol stack or applications on a host must be modified.
Routers in a site must be configured to return error messages to
the sender of inappropriately addressed packets.
RouterAssist:
- The protocol stack and applications on a host must be modified.
Furthermore, routers must be modified.
shim6:
- The protocol stack must be modified. For this address selection
purpose, corresponding nodes need not support shim6. Basically,
there is no need to change the router implementation or
configuration.
5. Security Considerations
Incorrect address selection can lead to serious security problems,
such as session hijacking. However, we should note that address-
selection is ultimately decided by nodes and their users. There are
no means to enforce a specific address-selection behavior upon every
end-host from outside the host. Therefore, a network administrator
must take countermeasures against unexpected address selection.
6. IANA Considerations
This document has no actions for IANA.
7. Conclusions
In this document, we examined solutions to address selection problems
in the IPv6 multi-prefix environment. Although almost all solutions
examined in this document could be applied to any environment and
situation, a solution with a mechanism that is suitable for the
situation should be selected.
8. References
8.1. Normative References
[I-D.ietf-v6ops-addr-select-ps]
Matsumoto, A., "Problem Statement of Default Address
Selection in Multi-prefix Environment: Operational Issues
of RFC3484 Default Rules",
draft-ietf-v6ops-addr-select-ps-01 (work in progress),
Matsumoto, et al. Expires November 2, 2007 [Page 13]
Internet-Draft Address-Selection Solutions May 2007
April 2007.
[I-D.ietf-v6ops-addr-select-req]
Matsumoto, A., "Requirements for address selection
mechanisms", draft-ietf-v6ops-addr-select-req-02 (work in
progress), May 2007.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
8.2. Informative References
[I-D.chakrabarti-ipv6-addrselect-api]
Nordmark, E., "IPv6 Socket API for Address Selection",
draft-chakrabarti-ipv6-addrselect-api-06 (work in
progress), May 2007.
[I-D.fujisaki-dhc-addr-select-opt]
Fujisaki, T., "Distributing Default Address Selection
Policy using DHCPv6",
draft-fujisaki-dhc-addr-select-opt-03 (work in progress),
January 2007.
[I-D.ietf-shim6-failure-detection]
Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-07 (work in progress),
December 2006.
[I-D.ietf-shim6-locator-pair-selection]
Bagnulo, M., "Default Locator-pair selection algorithm for
the SHIM6 protocol",
draft-ietf-shim6-locator-pair-selection-01 (work in
progress), October 2006.
[I-D.ietf-shim6-multihome-shim-api]
Komu, M., "Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-02
(work in progress), March 2007.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
Matsumoto, et al. Expires November 2, 2007 [Page 14]
Internet-Draft Address-Selection Solutions May 2007
Authors' Addresses
Arifumi Matsumoto
NTT PF Lab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 3334
Email: arifumi@nttv6.net
Tomohiro Fujisaki
NTT PF Lab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7351
Email: fujisaki@syce.net
Ruri Hiromi
Intec Netcore, Inc.
Shinsuna 1-3-3
Koto-ku, Tokyo 136-0075
Japan
Phone: +81 3 5665 5069
Email: hiromi@inetcore.com
Ken-ichi Kanayama
Intec Netcore, Inc.
Shinsuna 1-3-3
Koto-ku, Tokyo 136-0075
Japan
Phone: +81 3 5665 5069
Email: kanayama@inetcore.com
Matsumoto, et al. Expires November 2, 2007 [Page 15]
Internet-Draft Address-Selection Solutions May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Matsumoto, et al. Expires November 2, 2007 [Page 16]