MONAMI6 R. Jaksa Internet-Draft C. Williams Expires: December 20, 2006 B. Sarikaya Huawei USA A. Huang C. Wan Huawei Technologies June 18, 2006 Destination Address Selection Analysis for a MONAMI6 MN draft-jaksa-monami6addr-select-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 December 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract When a correspondent node (CN) initiates a session with a multi-homed Mobile Node (MN), it should choose the "best" destination address based on the available information about the MN. Presently there is no mechanism allowing the MN to indicate on which interface (i.e., Jaksa, et al. Expires December 20, 2006 [Page 1] Internet-Draft Destination address selection June 2006 address) a CN may reach it. This draft documents a method whereby the MN may communicate to the CN address selection preferences so that the CN may initiate a session to the desired address (interface) for of the MN. The method is based on the notion of storing address selection preference information for the MN in the DNS. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Destination Address Selection for a Multi-homed MN . . . . . . 3 3.1. Analysis of DNS with MONAMI6 destination address selection . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. WKS Resource Record . . . . . . . . . . . . . . . . . 4 3.1.2. SRV Resource Record . . . . . . . . . . . . . . . . . 5 3.1.3. Summary of DNS usage . . . . . . . . . . . . . . . . . 5 4. Destination Address Selection Requirements . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative references . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Jaksa, et al. Expires December 20, 2006 [Page 2] Internet-Draft Destination address selection June 2006 1. Introduction A mobile node will have in the future multiple network interfaces, and the best decision to select an interface and an access network from other possible combinations has to be taken. This decision will depend on several things such as: user preferences, requirements from applications, device capabilities, available network interface cards and their performances, available access networks and their capabilities, etc. [6] Using MONAMI6 [5] technologies a multi-homed Mobile IPv6 Node [1] is able to use multiple interfaces at the same time, according to some preference settings. This will allow the MN to achieve load sharing, load balancing and aggregated bandwidth when sessions are initiated by the MN. When a correspondent node (CN) initiates a session with the MN, it should choose the destination address depending on the available information about the MN. Presently there is no mechanism allowing the multi-homed MN to indicate on which address (or interface) a CN may reach it. If only the MN addresses are known by the distant node (CN), the CN is unable to choose the "best" destination address of the multi-homed MN. It is on the MN that the profile management database resides and there is a strong requirement for the MN to communicate interface selection preferences about itself to the to the CN. This write-up reviews over the Destination Address Selection when initiating a connection with a Multi-homed MN. The document also examines possible ways that the DNS may aid this process. 2. Terminology See [2] for mobility terminology used in this document. 3. Destination Address Selection for a Multi-homed MN In general a host is able to gain knowledge about its local connections than about conditions at a remote location. For a multi- homed MN this would include such things as: user preferences, application QoS requirements, access network types for each interface, etc. On the destined CN, most commonly applications sequentially try destination addresses from the getaddrinfo API [4]. MONAMI6 mechanisms provide Mobile IPv6 support for mobile nodes with multiple addresses or multiple interfaces used simultaneously, i.e. Jaksa, et al. Expires December 20, 2006 [Page 3] Internet-Draft Destination address selection June 2006 multihomed mobile nodes. MONAMI6 extensions deployed on the MN means that MIPv6 will simultaneously work with all of its addresses or interfaces. This means that either a single Home Address (HoA) will be associated with a set of interfaces or a single interface is associated with one HoA or a single interface associated with multiple HoAs. 3.1. Analysis of DNS with MONAMI6 destination address selection Although the CoA may be a global IPv6 address, it is only the HoAs of the MONAMI6 MN that are stored in the DNS. Again, generally applications will sequentially try destination addresses received from the DNS resolver. If there are more than one HoA for the MONAMI6 MN, the default address selection is provided in [3]. Currently, this selection doesn't take into account the MONAMI6 MN connection profile which is managed locally. Another case is when there exists a single HoA associated with multiple interfaces. Here the application would be unaware of the fact that there are multiple interfaces as it would only receive a single HoA from the DNS. It has been stated in [5] and [4] that DNS may be used as an approach of helping the CN choose the most appropriate destination address. This would mean that the MN would need to be able to communicate to the CN through stored information in the DNS its preferences for connection. For the case whereby there is a single HoA for multiple interfaces, information received from the DNS would not help the application in its destination address selection. Here the CoA information would be required to distinguish which of the MNs interface to initiate a connection on. In the case whereby there are Multiple HoAs stored in the DNS as AAAA records, then it would be possible to store MN preference information along with the HoAs in the DNS. This may aid the application in selecting the "best" destination address. The next subsections will examine existing DNS resource records to see in what manner such preference information might be stored. 3.1.1. WKS Resource Record The WKS DNS resource record will provide to the CN applications information about which services are available at a host. Such information is coupled with the nodes IP address and can be associated with the MONAMI6 MNs HoAs. The record has the following format: ip-address protocol service. Here, ip-address is the IPv4 address of the server, protocol is a protocol such as tcp or udp, and service is a list of services, such as http or ftp, and port numbers. Here specific services could initiate connections to the on one HoA for the MN and others services initiate connections to the MN on Jaksa, et al. Expires December 20, 2006 [Page 4] Internet-Draft Destination address selection June 2006 other HoAs. This could be a way for at least providing MN preference information per HoA based on services and storing such information in the DNS. At the moment there is no IPv6 equivalent of WKS records. 3.1.2. SRV Resource Record SRV records provide a better way of dealing with services. However, such records are not intended to be per host. The SRV record instead offers a way to list services for a domain name. Through DNS configuration of the SRV record, a set of SRV records could apply to a host. In this way a service on the CN may use a the hostname (FQDN) and service name to query for the proper SRV records for the multi-homed MN. The service would receive the SRV record return by the DNS in order to choose the best HoA. The SRV has priority and weight values per HoA that represent the preference of the MN for which HoA that the service should select. The SRV records would need to be dynamically updated as the local conditions of the MN change. 3.1.3. Summary of DNS usage It is difficult to count on DNS for any reliable info concerning the reachability of a ever changing MONAMI6 Mobile Node. However, given some specific scenarios in which some service related preferences remain static and the access network types for the MN are more likely to always be available, then the DNS can provide some simple and powerful information to the application on the CN in determining the destination address selection of a multi-homed MN. We examined existing DNS resource records that may be applicable in aiding the destination address selection process when attempting to establish a connection to a multi-homed MN. People in DNS community also have strong opinions on who can register information in DNS so we choose not to invent new DNS resource records. However, a need may exist for a multi-homed host-centric DNS solution - one in which a Multi-homed Mobile Node may be able to state its preferences for which HoA that the application should select (in the event that MN has multiple HoAs). 4. Destination Address Selection Requirements As a side to the central focus of this draft we wish to provide some input into requirements for any solution (DNS or transport supported) that may be developed to aid in the CNs decision to choose the "best" MN address or interface in which to initiate a connection to. 1. The mechanism MUST periodically re-evaluate the mappings between flows and interfaces to take into account the quality changes on the different interfaces (or addresses). Jaksa, et al. Expires December 20, 2006 [Page 5] Internet-Draft Destination address selection June 2006 2. The mechanism MUST be Dynamic Adaptive in that after re- evaluation of the mappings and update is done so that flows are adjusted immediately or that new initiated connections reflect the current preference settings of the MONAMI6 MN. 3. The mechanisms SHOULD provide various granularity in its mappings. Such granularities examples include mappings of service to addresses (interfaces), mappings of source address to destination addresses (interfaces), and load balancing mappings from the context of the MN. 4. The mechanism MUST provide rapid reaction to topology changes. 5. The mechanisms MUST provide a secured way for the MN to update the mappings. 5. Security Considerations Dynamic DNS would be the method used for the MN to dynamic update the information stored for address selection preferences. This would be required to be secured when performing these updates. 6. Conclusion Destination address or interface selection by the CN when initiating a connection could be aiding by anyone of the various levels - IP level, MIPv6, Transport, or DNS (application). This document analyzed when it might be useful aid the selection via the DNS and possible deficiencies with current resource records. We also concluded with some requirements - a starting point - when developing these mechanisms (at any level). We hope that this write-up frets out some issues that have only preliminary been discussed in the MONAMI6 working group and that this information helps this debate. 7. References 7.1. Normative references [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [3] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484 Year 2003, February 2003. [4] Huitema, C. and R. Draves, "Host-Centric IPv6 Multihoming", Work Jaksa, et al. Expires December 20, 2006 [Page 6] Internet-Draft Destination address selection June 2006 In Progress draft-huitema-multi6-hosts-00.txt, July 2001. [5] Montavont, N., Wakikawa, R., and T. Ernst, "Analysis of Multihoming in Mobile IPv6", Work In Progress draft-ietf-monami6-mipv6-analysis-00.txt, February 2006. 7.2. Informative References [6] Andre, F. and J. Bonnin, "Optimized Support of Multiple Wireless Interfaces within an IPv6 End-Terminal", Smart Object Conference 2003, Proceedings of SOC, November 2003. Jaksa, et al. Expires December 20, 2006 [Page 7] Internet-Draft Destination address selection June 2006 Authors' Addresses Robert Jaksa Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: rjaksa@futurewei.com Carl Williams Huawei USA Consultant, Palo Alto, CA 94306 USA Phone: +1.650.279.5903 Email: carlw@mcsr-labs.org Bechet Sarikaya Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: bsarikaya@huawei.com Andy Huang Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, China 210001 China Phone: +86-25-84565415 Email: hpanda@huawei.com Jaksa, et al. Expires December 20, 2006 [Page 8] Internet-Draft Destination address selection June 2006 Changsheng Wan Huawei Technologies Site A,Floor 10,HuiHong Mansion,No.91 BaiXia Rd. Nanjing, China 210001 China Phone: +86-25-84565415 Email: wanchangsheng@huawei.com Jaksa, et al. Expires December 20, 2006 [Page 9] Internet-Draft Destination address selection 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. Jaksa, et al. Expires December 20, 2006 [Page 10]