MONAMI6 R. Jaksa Internet-Draft C. Williams Intended status: Informational B. Sarikaya Expires: April 26, 2007 Huawei USA A. Huang Huawei Technologies October 23, 2006 Destination Address Selection Analysis for a MONAMI6 MN draft-jaksa-monami6addr-select-01.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 April 26, 2007. 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., address) a CN may reach it. This draft documents a method whereby Jaksa, et al. Expires April 26, 2007 [Page 1] Internet-Draft Destination address selection October 2006 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 1.1. Current Standard for address selection . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Destination Address Selection for a Multi-homed MN . . . . . . 4 3.1. Analysis of DNS with MONAMI6 destination address selection . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. WKS Resource Record . . . . . . . . . . . . . . . . . . . 5 3.3. SRV Resource Record . . . . . . . . . . . . . . . . . . . 5 3.3.1. SRV and Best Destination Address selection . . . . . . 6 3.3.2. SRV specification for Mobile IPv6 multi-interface nodes . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.3. Summary of DNS usage . . . . . . . . . . . . . . . . . 7 4. Destination Address Selection Requirements . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative references . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Jaksa, et al. Expires April 26, 2007 [Page 2] Internet-Draft Destination address selection October 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. [8] Using MONAMI6 [7] 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. 1.1. Current Standard for address selection For a typical IPv6 host that has multiple IPv6 addresses assigned to multiple interfaces and multiple IPv6 addresses are returned in the DNS Name Query Response message, the choice of the source and destination IPv6 address is more complex. The source and destination IPv6 addresses should be matched in scope and purpose. For example, an IPv6 host should not choose a link-local source address when communicating with a global destination address. Additionally, the possible destination address should be sorted by preference. To provide a standardized method to choose source and destination IPv6 addresses with which to attempt connections, [3] defines the following required algorithms: (a) A source address selection algorithm to choose the best source address to use with a destination; (b) A destination address selection algorithm to sort the list of possible destination addresses in order of preference. Because RFC 3484 defines a standard method of determining source and Jaksa, et al. Expires April 26, 2007 [Page 3] Internet-Draft Destination address selection October 2006 destination addresses, applications do not need to include their own address selection algorithms, reducing the development burden on IPv6-capable applications. The purpose of the destination address selection algorithm is to sort the list of possible IPv4 and IPv6 destination addresses in order of highest to lowest preference. Here this draft describes the motivation for the use of a complimentary method for allowing a multi-homed node that is also mobile to be able to communicate its preference for which address that the corresponding node should use when initiating communications. Here the motivation may be that the multi-interface node may be paying different price to different service providers that the multi-interface mobile node may be simultaneously connected to. So the best choice may depend on specific destinations the corresponding node are sending to. It is highly desirable that a node would require that traffic is directed to a cheap link of a multi-interface node as long as it works. Also, the mobile node may want to utilize all links in certain proportion or based on services (as specified on their ports). 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 [6]. MONAMI6 mechanisms provide Mobile IPv6 support for mobile nodes with multiple addresses or multiple interfaces used simultaneously, i.e. 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 Jaksa, et al. Expires April 26, 2007 [Page 4] Internet-Draft Destination address selection October 2006 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 [5]. 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 [7] and [6] 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.2. 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 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.3. 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 Jaksa, et al. Expires April 26, 2007 [Page 5] Internet-Draft Destination address selection October 2006 (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.3.1. SRV and Best Destination Address selection The advertised address in the DNS should be that of the best interface on the host, in terms of network performance and reliability to the largest number of destinations. With Mobile IPv6 we have care-of addresses that temporary identify uniquely each interface. The destination address identifies the entity with which the correspondent host is communicating. If the correspondent host uses the mobile host's home IP address as the destination address, then the packets will be successfully deliverable regardless of where in the Internet the mobile host is connected, but they may not travel by the most efficient route. If the correspondent host instead uses the mobile host's current temporary care-of address, then the packets will be delivered efficiently, but transparent mobility is lost and TCP connections will be broken without warning when the mobile host moves. Both of these addressing techniques have situations where they are appropriate and situations where they are not. One technique is to have a Home Address for each interface and mobility service provided on each of these interfaces - serviced by a Home Agent. Each HoA will have associated CoA as the Mobile IPv6 node changes its point of attachment. The SRV record will contain a mapping of the service name and the appropriate HoA (or interface). The binding cache will allow route optimization via the mapping of the HoA of each interface with the respective CoA. In this solution there exist a balance between the mobility management and the DNS lookup in the selection of the best destination address. The advantage is that the DNS query is used to select and lookup the host today. By configuring the DNS host information with all of the IPv6 addresses of the multi-home mobile node, complex binding update structures and signaling may be avoided. This proposal only takes into consideration the selection of the destination address based on services but may be extended for other filters selection rules. 3.3.2. SRV specification for Mobile IPv6 multi-interface nodes An SRV record or Service record is a category of data in the Internet DNS specifying information on available services. It is defined in [4]. An SRV record holds the following information: Jaksa, et al. Expires April 26, 2007 [Page 6] Internet-Draft Destination address selection October 2006 1. Service: the symbolic name of the desired service. 2. Protocol: this is usually either TCP or UDP. 3. Domain name: the domain for which this record is valid. 4. TTL: standard DNS ttl field. 5. Class: standard DNS class field (this is always IN). 6. Priority: the priority of the target host. 7. Weight: A relative weight for records with the same priority. 8. Port: the TCP or UDP port on which the service is to be found. 9. Target: the hostname of the machine providing the service. In the following example, both the priority and weight fields are used to provide a combination of load balancing and backup service spanned over multi-interfaces of the Mobile IPv6 node. _sip._tcp.example.com. 86400 IN SRV 10 60 5060 interface1.example.com. _sip._tcp.example.com. 86400 IN SRV 10 20 5060 interface2.example.com. _sip._tcp.example.com. 86400 IN SRV 10 20 5060 interface3.example.com. _sip._tcp.example.com. 86400 IN SRV 20 0 5060 backinterface.example.com. Figure 1: Example of load balancing of Mobile IPv6 multi-interface Node using SRV records 3.3.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). Jaksa, et al. Expires April 26, 2007 [Page 7] Internet-Draft Destination address selection October 2006 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). 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 Jaksa, et al. Expires April 26, 2007 [Page 8] Internet-Draft Destination address selection October 2006 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, February 2003. [4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [5] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484 Year 2003, February 2003. [6] Huitema, C. and R. Draves, "Host-Centric IPv6 Multihoming", Work In Progress draft-huitema-multi6-hosts-00.txt, July 2001. [7] 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 [8] 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. Authors' Addresses Robert Jaksa Huawei USA 1700 Alma Dr., Suite 102 Plano, Tx 75075 USA Phone: 1 972 509 5599 Email: rjaksa@futurewei.com Jaksa, et al. Expires April 26, 2007 [Page 9] Internet-Draft Destination address selection October 2006 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 April 26, 2007 [Page 10] Internet-Draft Destination address selection October 2006 Full 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. 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. 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). Jaksa, et al. Expires April 26, 2007 [Page 11]