Internet DRAFT - draft-aso-monami6-multiple-forwarding
draft-aso-monami6-multiple-forwarding
IETF Monami6 Working Group K. Aso
Internet-Draft Matsushita Electric Industrial
Expires: December 28, 2006 Co., Ltd. (Panasonic)
B. Koh
Panasonic Singapore Labs
June 26, 2006
Multiple Forwarding Destinations Notification
draft-aso-monami6-multiple-forwarding-01
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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document considers a mobile terminal with multiple interfaces
which uses Mobile IPv6[1]. With multiple interfaces, the mobile
terminal may use them simultaneously for communication with a peer
device. Hence enabling the mobile terminal to achieve fault
tolerance, load balancing and so on. This document deals with the
mobile terminal with multiple interfaces, so it is possible that each
Aso & Koh Expires December 28, 2006 [Page 1]
Internet-Draft Multiple Forwarding Destinations June 2006
kind/type of interface may have its own characteristics or
differences.
In particular, we take a closer look at the path between mobile
terminal and its home agent. In the case when the mobile terminal
has multiple interfaces, there exists several paths to the home
agent. A general approach would be to first take a look at effective
use of the multiple interfaces from a pure Mobile IPv6 perspective.
As a matter of course, RFC3775 is used as the basic reference with
which we consider the multiple interfaced mobile terminal operating
in a Mobile IPv6 environment.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Limitations with Mobile IPv6 and Multiple CoAs
Registrations . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Impact of Multiple Interfaces on Mobile IPv6 . . . . . . . 3
4.1.1. Use of the interface as one forwarding destination . . 3
4.1.2. Need of multiple forwarding destinations . . . . . . . 4
4.2. Path between the mobile node and the correspondent node . 4
4.2.1. Another path to the CN . . . . . . . . . . . . . . . . 4
4.2.2. Meaning of the notified path to CN . . . . . . . . . . 5
5. Simultaneous Location Scenario . . . . . . . . . . . . . . . . 5
6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
7. Possible Operation for the mobile node with multiple
interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Network based solution . . . . . . . . . . . . . . . . . . 7
7.1.1. Advertising both home prefix and other prefix . . . . 8
7.2. Mobile Node based solution . . . . . . . . . . . . . . . . 9
7.3. Modified Binding Unique Identifier sub-option . . . . . . 11
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Aso & Koh Expires December 28, 2006 [Page 2]
Internet-Draft Multiple Forwarding Destinations June 2006
1. Introduction
Today's consumer electronics market has seen an explosion of devices
containing more than one type of wireless interface. As a greater
amount of functionality is packed into each user terminal, cell
phones with PDA-like capabilities are becoming more common. Users of
such multimode devices typically desire "always on" internet access
at the lowest possible cost, hence the proliferation of multimode
devices with diverse wireless interfaces such as WLAN and WPAN in
addition to the de facto cellular network connectivity.
By utilizing the more reliable cellular coverage for making voice
calls and WLAN or WPAN connectivity for other forms of digital data
communications, the user may more effectively leverage upon the
strengths of each technology. A foreseeable scenario involves the
user purchasing some entertainment content through the cellular
service operator. The user or the service operator may now choose to
receive or transmit the stream via a more economical wireless
interface. While enjoying the bought content, a voice call is put
through to the user's handset and the user effortlessly receives the
call, ends it and resumes his entertainment.
In this document, we analyze similar scenarios in greater detail and
discuss the required functionalities on the mobile terminal and
network in order to achieve it.
2. Terminology
General mobility terminology can be found in Mobile IPv6[1]
3. Scope
It is the intention of this draft to focus on the notification
mechanism for multiple interfaces.
4. Limitations with Mobile IPv6 and Multiple CoAs Registrations
4.1. Impact of Multiple Interfaces on Mobile IPv6
The following sections describe some considerations regarding
multiple interfaces which the mobile node using Mobile IPv6 has.
4.1.1. Use of the interface as one forwarding destination
Mobile IPv6 allows the mobile node to continue to communicate with a
Aso & Koh Expires December 28, 2006 [Page 3]
Internet-Draft Multiple Forwarding Destinations June 2006
correspondent node regardless of mobility. The tunnel between the
mobile node and its home agent connects the correspondent node to the
mobile node when the mobile node is away from home, providing session
continuity. However Mobile IPv6 assumes that the mobile node uses
only one interface at a point in time. If the mobile node has
multiple interfaces, it must choose one and notify the home agent of
its selected interface. The selected interface is used as the
forwarding destination by the home agent for packets addressed to
HoA. When the mobile node wants to select another interface, it must
notify the home agent of its new forwarding destination. Basically,
even if the mobile node has multiple interfaces which are usable, it
can use only one of them as the forwarding destination.
When a home agent serves as a mobile node's home agent, it intercepts
packets to the mobile node's HoA, searches the Binding Cache for the
HoA entry. It then tunnels the intercepted packets to the CoA found
in the binding cache entry. In this case, this CoA is the forwarding
destination. On the other hand, if the home agent does not serve as
the mobile node's home agent, it does not intercept packets to the
mobile node's HoA. Hence all packets to the mobile node's HoA are
received by the mobile node directly via the home network. In this
case, there is no forwarding destination in the home agent.
4.1.2. Need of multiple forwarding destinations
As stated in Section 4.1.1, the mobile node needs to send a binding
update to notify the home agent of the forwarding destination. So,
as described in MCoA[2], in order to enable the home agent to
initiate the change of the forwarding destination, the mobile node
should notify the home agent of possible alternatives for the
forwarding destination. According to MCoA[2], when the mobile node
is connected to both home and foreign networks, it can use only
either the interface attached to the home network or the interface
attached to the foreign network. It is important to allow the
selection of source or forwarding destination at either endpoint of a
path, regardless of the network the mobile node is connected to.
4.2. Path between the mobile node and the correspondent node
The following sections describe the mechanism for utilizing the
direct path between the mobile node and the correspondent node.
4.2.1. Another path to the CN
Looking at the communication between the mobile node and CN, the CN
knows only the peer node's address as an initial condition. The CN
is not aware that the peer node is a mobile node. If the mobile node
is at its home network, the packets sent by the CN are routed to the
Aso & Koh Expires December 28, 2006 [Page 4]
Internet-Draft Multiple Forwarding Destinations June 2006
mobile node directly. If the mobile node is away from home, they are
routed by the home agent to the mobile node.
Currently, Mobile IPv6 has available a mechanism to inform the CN
about the existence of another path and that is route optimization.
By using this mechanism, the CN could be made aware of another direct
path between itself and the peer node. In this case, there are now
two paths between the mobile node and the CN. When the CN sends the
packet, it may prefer the direct path because the direct path is
typically shorter than the other one.
4.2.2. Meaning of the notified path to CN
The path notified from the mobile node to CN has the meaning of
"optimized path" and Mobile IPv6 fundamentally already incorporates a
mechanism to inform a peer of the difference regarding multiple paths
to the same node. The existence of two different paths arises from
the mobility of the mobile node as well as the presence of a home
agent. Such a meaning is not provided between the home agent and the
mobile node.
5. Simultaneous Location Scenario
Consider the scenario when a user's mobile terminal is both cellular
and WLAN enabled. The cellular connection is provided by a cellular
operator. The WLAN connection is obtained via a wireless hotspot in
a restaurant. The user intends to utilize a video conferencing
application while simultaneously participating in an online game.
For reasons of cost versus quality of service, the user would like to
utilize his cellular connection for his video streams and the free
WLAN connection for his online game. For this purpose, he proceeds
to register the location address and set the appropriate policies on
his home agent in his house. The home agent is supposed to select
suitable interface to forward the specific flow based on such
policies set by the user.
At one point, when the user leaves the hotspot and goes into his
house, the WLAN interface connects to the WLAN network which is the
home network to which user's home agent is attached to. The network
configuration after this movement is called as "simultaneous
location". This indicates that mobile node is connecting to both
home network and foreign network simultaneously. In this case, WLAN
network is providing the mobile node with not only access service but
also mobility service. On the other hand, cellular network is
considered as the provider of access service in terms of mobility
service provided by user's WLAN network even though it has the home
agent. Of course, above WLAN network/home agent in user's house
Aso & Koh Expires December 28, 2006 [Page 5]
Internet-Draft Multiple Forwarding Destinations June 2006
could be replaced with the WLAN network/home agent provided by the
user's company, or the cellular network could provide the mobile node
with the home agent.
Figure 1 shows the cellular network operated by a cellular operator
and WLAN network operated in User's house/company which provides the
home agent. The WLAN interface(IF1) is connected to WLAN network and
cellular interface(IF2) is connected to the cellular network. As
described above, the mobile terminal is connected to both home and
foreign network via its two interfaces.
Cellular Network WLAN Network in User's house/company
(access service) (mobility service/
/~~~~~~~~~~~~~~~~\ access service)
| | /~~~~~~~~~~~~~~~~~\
| | | +----------+ |
| | | |home agent| |
| =============== | +----------+ |
| / | Path2 | / |
\_______ /______/ \_ /_____________/
/ /
Path2 \ / Path1
\ /
+---+ +---+
|IF2| |IF1|
+---------------+
|mobile terminal|
+---------------+
Figure 1: Network Configuration
There are two possible paths between the home agent and the mobile
terminal. The first is the direct path (Path1) from the home agent
via the mobile node's WLAN interface and the other is through the
foreign network via the mobile terminal's cellular interface (Path2).
According to current Mobile IPv6 protocol, when communicating with a
CN without using Route Optimization the mobile terminal and home
agent may choose to use either Path1 or Path2.
6. Problem Statement
In the above described scenario, the home agent is not able to
initiate a change of forwarding destination. Even if both interfaces
are available, the existence of a binding cache entry in the home
agent reflects only a part of several possible locations of the
Aso & Koh Expires December 28, 2006 [Page 6]
Internet-Draft Multiple Forwarding Destinations June 2006
mobile node. This seems to be the same problem as conventional
Mobile IPv6 without multiple CoAs registration and it creates
overheads due to the inefficient sending of messages and replies.
The policies set by the mobile node before the movement is no longer
available because the home agent does not know of the existence of
multiple paths between itself and the mobile node.
If the mobile node uses IF2, there must be a binding cache entry for
HoA and CoA at the home agent. In this case for packets sent from
the CN, the home agent must intercept the packets addressed to the
mobile node's HoA and tunnel them to the mobile node. For packets
sent from the mobile node, the mobile node must utilize the reverse
tunnel and send the packets to the home agent which then decapsulates
the tunneled packets and forwards the inner packets to the CN.
Thereby the mobile node can send and receive the packets utilizing
interface IF2. If the mobile node chooses to use IF1, there must not
be any binding cache entries at the home agent. In this case, the
mobile node does not need to use any reverse tunnel. It can use it's
own HoA normally to send packets and the home agent is not involved
in the packet transmission.
7. Possible Operation for the mobile node with multiple interfaces
This section introduces some possible operations to achieve
simultaneous use of multiple interfaces and describes the
consideration on actual operation. Their operations is based on use
of CoA in home link.
According to MCoA[2], the mobile node that is returning home has two
options. The first is the mobile node chooses to use the home
attached interface, the second is the mobile node selects the foreign
attached interface. This document proposes the third option which is
the mobile node chooses to utilize both the home attached and foreign
attached interfaces. Some possible operational details for this
option is described below.
7.1. Network based solution
This method makes the home link appear to be the foreign link for the
mobile node by advertising a prefix other than the home prefix.
Typically when the advertised prefix is different from the home
prefix, the mobile node considers the link to be a foreign link even
if the home agent is connected to the link. The process for the
mobile node when it connects to the home link in this operation is to
register a CoA at the home agent at all times without noticing that
it is attaching to the home link.
Aso & Koh Expires December 28, 2006 [Page 7]
Internet-Draft Multiple Forwarding Destinations June 2006
The mobile node with a single interface should use its own Home
Address in the home link. However, in this case, the MIPv6-only
mobile node can not perform the returning home procedure at all
times. The mobile node with multiple interfaces should be able to
select between registering the CoA and performing the returning home
procedure for effective usage of the home attached interface.
However, in this case, all the MCoA-capable mobile node can do is
register the CoA similar to the MIPv6-only mobile node. Even for the
mobile node with multiple interfaces utilizing only the home attached
interface, it has to register the CoA from the home link.
Figure 2 shows the network configuration on Foreign Link the Home
Agent connects. The Home Agent does not advertise the home prefix.
On the other hand, the Default Router is advertising prefix A in the
home link. So, this link is considered to be a foreign link by the
connecting mobile node. Both the MIPv6-only mobile node and MCoA-
capable mobile node creates a CoA using prefix A and registers it to
the home agent.
Internet Internet
| |
+----------+ +--------------+ +--------------+
|Home Agent| |Default Router| |Default Router|
+----------+ +--------------+ +--------------+
| |pA(advertising) |pB(advertising)
------------------------ -------------------
| | |
+--+ +---+ +---+
pA.CoAm|IF| pA.CoAc|IF1| |IF2|pB.CoAc
+--------+ +----------+
|MIPv6-MN| | MCoA-MN |
+--------+ +----------+
pH.HoAm pH.HoAc
[Binding Cache of Home Agent]
o pH.HoAm - pA.CoAm o pH.HoAc - pA.CoAc (BID1)
pH.HoAc - pB.CoAc (BID2)
home prefix : pH
prefix A : pA
prefix B : pB
Figure 2: Foreign Link the Home Agent connects
7.1.1. Advertising both home prefix and other prefix
As described above, when only prefix A is advertised in the home
Aso & Koh Expires December 28, 2006 [Page 8]
Internet-Draft Multiple Forwarding Destinations June 2006
link, the mobile node can not detect that it is attaching to the home
link. In order to allow the MIPv6-only mobile node to recognize the
home link, it needs the home prefix to be advertised in the link. In
this case, at least two prefixes are visible for mobile node in the
link and the mobile node can use them for detecting both home and
foreign links. A Router Advertisement message can contain several
prefix options so when several prefixes belong to the same router,
the router can use one Router Advertisement message to advertise them
at the same time. Of course, it can also use separate Router
Advertisement messages for advertising each prefix.
7.1.1.1. Separate Advertising
If the home agent advertises the Home Prefix and Other Prefix
separately, both the MIPv6-only mobile node and MCoA-capable mobile
node still connects to the home link as a foreign link if it receives
the Other Prefix before receiving the Home Prefix. In order for the
MIPv6-only mobile node to avoid detecting the Other Prefix, a simple
method may be to introduce a new dedicated option for carrying the
Other Prefix. However, this would not change the result of the MCoA-
capable mobile node recognizing that it is in the home link. This is
not the intention of using Foreign link with the Home Agent.
7.1.1.2. Simultaneous Advertising
In order for the MIPv6-only mobile node to avoid detecting the Other
Prefix before finding the Home Prefix, another simple method is to
advertise the Home Prefix and the Other Prefix together. In this
case the MIPv6-only mobile node may be able to avoid using the Other
Prefix. However, it also would not change the result of the MCoA-
capable mobile node recognizing that it is in the home link. So, it
is difficult to mislead the MCoA-capable mobile node into believing
it is in a foreign link while still allowing the MIPv6-only mobile
node to know that it is in the home link.
7.2. Mobile Node based solution
In section Section 7.1, the scenario for using Other Prefix in the
home link is described. This section describes the scenario for
using the Home Prefix. This method does not keep the mobile node
from noticing that it is attached to the home link. The MCoA-capable
mobile node should also be able to notice that it is attached to the
home link in order for it to be able to choose between registering a
CoA or performing the returning home procedure.
This method requires the mobile node to create a CoA(HomeCoA) from
the Home Prefix in the home link which is different from the HoA.
The mobile node then notifies the home agent of both its addresses.
Aso & Koh Expires December 28, 2006 [Page 9]
Internet-Draft Multiple Forwarding Destinations June 2006
This enables the home agent to continue to intercept the packets
addressed to the mobile node's HoA. The advantage is that the MIPv6-
only mobile node can perform the returning home procedure normally
whenever it connects to home link. The detection of the home link is
achieved by checking the prefix included in Router Advertisement sent
by home agent. On the other hand, the MCoA-capable mobile node can
choose between using the HomeCoA and performing the returning home
procedure for the home attached interface.
Figure 3 shows the network configuration on normal Mobile IPv6 home
Link. The Home Agent advertises the home prefix and hence this
network is considered as the home link by the connecting mobile node.
The MIPv6-only mobile node can use its own HoA(pH.HoAm) directly
without interception by the home agent. On the other hand, the MCoA-
capable mobile node can create a CoA(pH.CoAc) from the home prefix
and register it with the home agent after noticing that it is
attached to the home link. This method allows IF2's binding cache to
be kept simultaneously with IF1. Of course, if the MCoA-capable
mobile node does not use IF2, it can choose to use its own
HoA(pH.HoAc) directly without interception by the home agent.
Internet Internet
| |
+----------+ +--------------+
|Home Agent| |Default Router|
+----------+ +--------------+
|pH(advertising) |pB(advertising)
------------------------ ----------------
| | |
+--+ +---+ +---+
pH.HoAm|IF| pH.CoAc|IF1| |IF2|pB.CoAc
+--------+ +----------+
|MIPv6-MN| | MCoA-MN |
+--------+ +----------+
pH.HoAc
[Binding Cache of Home Agent]
o pH.HoAc - pH.CoAc, BID1
pH.HoAc - pB.CoAc, BID2
home prefix : pH
prefix B : pB
Figure 3: Normal Mobile IPv6 Home Link
Aso & Koh Expires December 28, 2006 [Page 10]
Internet-Draft Multiple Forwarding Destinations June 2006
7.3. Modified Binding Unique Identifier sub-option
In the case that the mobile node creates a CoA in the home link
regardless of whether it is using the Home Prefix or Other Prefix, it
must set the H flag in the Binding Unique Identifier option in order
to notify the home agent that the address included in the option is a
HomeCoA. A new flag (H) is included in the Binding Unique Identifier
sub-option to allow the home agent to differentiate between the CoA
in the home link from the CoA in a foreign link. This
differentiation is useful for the home agent when considering the
shortest path to the mobile node. This is similar to the situation
between the correspondent node and the mobile node because the
correspondent node can learn of the existence of paths and the path's
characteristics through the route optimization mechanism.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) | Priority |B|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
CoA Registration in home link (H) flag
The CoA Registration in home link (H) flag is set by the
sending mobile node to indicate to the home agent that the
Care-of Address identified by this BID is a CoA in the home
link. If the flag is set, the home agent assumes that the CoA
contained in the Binding Update is a CoA in the home link. The
CoA can be included in the Source Address Field or the
Alternate CoA option.
This modified Binding Unique Identifier sub-option is based on
MCoA[2]. If MCoA[2] is updated, this flag could be easily applied to
the updated Binding Unique Identifier sub-option.
The binding cache of the home agent is as follows when the H flag is
set in case of Figure 3. This difference between a CoA in the home
link and a CoA in the foreign link is a Mobile IPv6 specific feature
hence this is notified using normal CoA registration.
[Binding Cache of Home Agent]
o pH.HoAc - pH.CoAc, BID1, H-flag
pH.HoAc - pB.CoAc, BID2
Aso & Koh Expires December 28, 2006 [Page 11]
Internet-Draft Multiple Forwarding Destinations June 2006
8. Backward Compatibility
It is important for MCoA to keep backward compatibility with Mobile
IPv6 to achieve coexistence between the mobile node using Mobile IPv6
and the mobile node using MCoA. Also the mobile node using Mobile
IPv6 should be able to utilize the advantage defined in RFC3775 which
was designed for use with a single interfaced mobile node. Also, the
extension for Mobile IPv6 should not disrupt the operation of Mobile
IPv6.
Specifically, the operation on returning home in Mobile IPv6 is
useful for the mobile node which wants to use own HoA directly
without interception by the home agent. However, if some other
prefix is advertised in the home link, the mobile node may not be
aware that it is attached to the home link. The result is that it
can not perform returning home procedure. This may be good for the
mobile node that is using multiple interfaces at all times but not
for the mobile node that is using only one interface at a time (even
if the mobile node has multiple interfaces). As such, the method to
allow the MCoA-capable mobile node to create a CoA in the home link
by advertising a prefix other than home prefix is disadvantageous and
redundant for both the MIPv6-only mobile node and MCoA-capable mobile
node. The method based on the normal Mobile IPv6 home link is simple
and can keep backward compatibility with Mobile IPv6. For the mobile
node with a single interface, the returning home procedure should be
used. For the mobile node with multiple interfaces, it should be
able to choose to register a CoA or perform the returning home
procedure.
9. Conclusion
In order to allow the home agent to initiate a change of forwarding
destination in the described scenario, the use of CoA in the home
network enables flow control based on policies set by the mobile node
even when it is attached to the home and foreign networks
simultaneously. Moreover, it is obvious that using the home prefix
rather than some other prefix to form the CoA is desirable because it
can maintain backward compatibility with Mobile IPv6. For
representing the explicit difference in home and foreign paths
between the home agent and mobile node, this document introduces the
Modified Binding Unique Identifier sub-option.
This work explains the mobile node and the home agent operation which
can be applied to the situation where the mobile node is connected to
both home network and foreign networks.
Aso & Koh Expires December 28, 2006 [Page 12]
Internet-Draft Multiple Forwarding Destinations June 2006
10. Security Considerations
As this operation follows Mobile IPv6 operations, no additional
security issues have been identified.
Please refer to the Mobile IPv6 specification [1] for security
considerations.
11. References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of
Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-05.txt (work in progress),
February 2006.
Aso & Koh Expires December 28, 2006 [Page 13]
Internet-Draft Multiple Forwarding Destinations June 2006
Authors' Addresses
Keigo Aso
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3 Hikarino-oka
Yokosuka, Kanagawa 239-0847
JP
Phone: +81 46 840 5123
Email: asou.keigo@jp.panasonic.com
Benjamin Koh
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Email: benjamin.kohtm@sg.panasonic.com
Aso & Koh Expires December 28, 2006 [Page 14]
Internet-Draft Multiple Forwarding Destinations June 2006
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 (2006). 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.
Aso & Koh Expires December 28, 2006 [Page 15]
