INTERNET DRAFT Mukesh Bhatla 8 November 2002 Motorola Inc. DNS RR type for Multiple Unicast draft-bhatla-dnsext-murr-00.txt Status of This Memo Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract To date, the scenario of multiple IP addresses for same domain name arises for the case where either we have multihomed IP hosts or we have multiple servers having the same domain name and application on the client needs to approach only one of those IP hosts. However, the penetration of mobile hosts and personal devices identified, on the internet, by the user's Network Access Identifier (NAI) may create a scenario where multiple devices may have same domain name but different IP addresses and all of those devices may need to get the service or data from the application which only identifies them by their host name. This document proposes to add a new Resource Record called the Multiple Unicast Resource Record (MURR) to the DNS system. This resource record is added for a domain name where the applications retrieving the IP address for the domain name have to provide the service (like PUSH data) to all the IP addresses retrieved in the multiple MURRs for the domain name. Bhatla Expires April 2003 [Page 1] Internet Draft November 2002 1. Introduction The use of mobile Internet is projected to increase manifolds, each Individual is foreseen to use multiple mobile devices. Each of these devices may be identified by the Network Access Identifier (NAI-RFC2486)[3]. This will create the scenario where multiple devices have the same domain name but different IP addresses. The DNS which maps the domain name to IP address may have multiple Resource records for each domain name. Each of these RRs will map the domain name to an IP address. This document proposes to add a new Resource Record called the Multiple Unicast Resource Record (MURR) to the DNS system. This resource record is added for a domain name where the applications retrieving the IP address for the domain name have to provide the service (like PUSH data) to all the IP addresses retrieved in the multiple MURRs for the domain name. 2. Applicability Statement Currently DNS stores the Resource records corresponding to each domain name. These Resource Records include the A and AAAA resource records, which map a host name to an IPv4 and IPv6 address respectively. A domain name may have multiple IP addresses corresponding to it, each of this IP address is represented by an A record. Applications query the DNS server for these resource records to map the domain name to the IP address. These A records are retrieved by the client application through the Resolver, which resides on client itself. Its not well defined whether the resolver will convey the multiple IP addresses retrieved for a domain name or will convey only one of them to the application. Application normally communicates with only one of the IP address, which is retrieved by the application by the domain name query. The scenario where all the hosts, who have the same domain name, and have to be sent the same data is a possibility. (It is possible in the case where same NAI is used on various mobile hosts and the domain name of these mobile hosts is derived from the NAI,and all these mobile hosts have to be sent PUSH DATA). Multiple Unicast resource record is added for a domain name where the application retrieving the IP address for the domain name has to provide the service (e.g. PUSH data) to all the IP addresses retrieved in the multiple MURRs for the domain name. A domain name can have multiple MURRs, if multiple hosts having different IP addresses but the same domain name are present. The application can either do a MURR DNS query or all the MURR records could be sent as a part of the additional part of the DNS A resource record query. Bhatla Expires April 2003 [Page 2] Internet Draft November 2002 The main goal of MURR is to convey to the application that all the hosts having the same domain name desire Multiple Unicast. The application can easily distinguish between the need for Multiple unicast to all the IP addresses provided by MURR or to provide/get the service to/from a single host in the case IP addresses are provided by the A records. This enables host whose domain name is being resolved to have control over how it wants to get/provide a service. Resolver MUST forward all the RRs of the type MURR to the application. MURR is especially useful for the IP Reachability service for the wireless mobile stations. For the IP Reachability service the host name of the mobile station is derived from the NAI (user@domain) of the user on the mobile. The NAI is converted from user@domain to user.domain to derive the domain name for the mobile. This derived domain is updated along with the IP address of the domain name (A resource records) to the DNS server by the home AAA or the Home Agent (HA) for the mobile station. An application on the network can resolve this domain name to the IP address to provide a service (like PUSH data) to the subscriber. It's a possibility that same NAI could be used on multiple mobiles; this will create a scenario where same domain name will be mapped to multiple IP addresses. This will result in multiple A resource records being returned to the resolver on the client where application is resolving the domain name to the IP address. Most of the current applications/resolver will pick up one of the IP addresses and unicast the data to it. If MURR is used instead of the A Resource Record to map the domain name to the IP address. The application will have to unicast the data to all the hosts having the same domain name but different IP addresses as specified in the MURRs for that domain name. MURR's use is not limited to the wireless scenario; it could be used in any access method. A domain name can have multiple MURRs in master file of DNS server. The dynamic DNS server update procedures are as specified in the RFC 2136. Bhatla Expires April 2003 [Page 3] Internet Draft 4 January 2002 3. NAI RR Type The MURR record has the DNS RR type of "?", hence has the same QTYPE number of "?". Note: MURR RR requires IANA number assignment. The class of MURR RR is defined in the IN class only. 4. MURR RDATA format The RDATA of MURR is same as A RDATA format, 32 bit Internet Address. 4. Examples An example MURR can be: Mbhatla1.Motorola.com 10000 IN MURR 165.213.221.4 Mbhatla1.Motorola.com 10000 IN MURR 165.213.179.2 5. Security Considerations Any information obtained from the DNS should be regarded as unsafe unless techniques specified in [RFC2535] or [RFC2845] were used. The definition of a new RR type does not introduce security problems into the DNS. 6. IANA Considerations It requires new RR type number from IANA. Bhatla Expires April 2003 [Page 4] Internet Draft November 2002 References [1] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 1034, Nov 1987. [2] Mockapetris, P., "Domain names - Implementation and Specification", RFC 1035, Nov 1987. [3] Bernard Aboba and Mark A. Beadles "The Network Access Identifier". RFC 2486. January 1999. [4] 3GPP2 P.S0001-B work in progress. Addresses Questions about this memo can be directed to the authors: Mukesh Bhatla Motorola Inc. 1501 West Shure Drive, Arlington Heights, IL 60074 Mbhatla1@email.mot.com (847)435-0732 Bhatla Expires April 2003 [Page 5] Internet Draft November 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Bhatla Expires April 2003 [Page 6]