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]