idnits 2.17.1 draft-schaller-dnsop-lnp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2019) is 1895 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2131' is mentioned on line 72, but not defined == Unused Reference: 'RFC 2131' is defined on line 179, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lnp C. Schaller 3 Internet-Draft Schallsoft 4 Intended-Status: Elective February 11, 2019 6 Local Naming Protocol -- LNP (v.1.0) 7 draft-schaller-dnsop-lnp-00 9 Abstract 11 The Local (or Lightweight) Naming Protocol (LNP) is an application- 12 level protocol for local area networks. It is a distributed, 13 stateless protocol which intents in resolving hostnames to ip 14 addresses without the need of any Domain Name Server. In private 15 local area networks, ip addressses are often dynamically allocated 16 through DHCP. The LNP can be seen as a DNS extension, which uses 17 broadcast udp messages (similar to ARP on IP-MAC-level) to request 18 ip addresses for hosts with a given host- or domain-name. Thus it 19 will be possible in dynamic local area networks to access ip-based 20 services on hosts by their hostnames, without further management. 22 Comments are solicited and should be addressed to the working 23 group's mailing list at dnsop@ietf.org and/or the author(s). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Standalone LNP . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. DNS extended LNP . . . . . . . . . . . . . . . . . . . . 3 60 2. Protocol version 1.0 . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Concurrent replies . . . . . . . . . . . . . . . . . . . 4 63 2.3. No host responding . . . . . . . . . . . . . . . . . . . 4 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 In private local area networks or wireless LANs, today mainly DHCP 72 [RFC2131] managed ip address allocation is used. Since the equip- 73 ment on the market does not ship with integrated DNS servers, which 74 update their records when hosts attach to or detach from the net- 75 work, there is less help for private users or user applications 76 trying to access devices services over ip addresses. Actually no 77 service is out of the box available for all operating systems. 78 Microsoft Windows ships with NetBios [RFC 1002], which allows name 79 based access, however first after activation of file-sharing. 80 Apples MacOS is delivered with bonjour [RFC 6763], which runs out 81 of the box. Linux and Unix systems can do both, however after 82 explicit installation setup. All those systems are able to use DNS 83 [RFC 1035] when connected to ip networks. So why not extend the 84 functionality of the distributed Domain Name System, which already 85 has the task to resolv hostnames to ip addresses. 87 1.1. Standalone LNP 89 The standalone implementation of LNP uses a UDP broadcast message to 90 query the ip address of a host. Therefore the message contains the 91 full qualified name of a host connected to the local network. All 92 receivers check if the requested hostname equals their own. Every 93 matching host then replies. In version 1.0 a replying host shall 94 append the ip-address, bound to the interface receiving the message, 95 as message data. The sender now has resolved the ip-address of his 96 well known communication partner and can in turn open tcp-streams 97 and communicate directly. 99 1.2. DNS extended LNP 101 Every networking software using sockets, that relies on name reso- 102 lution to determine destinations ip-address will probably use a sys- 103 tem call e.g. getHostByName() or getAddrInfo() to retrieve the ip- 104 address. When every standard DNS client would be able to provide 105 and use LNP, i.e. in case of no matching DNS record or hosts-file 106 entry found, then no software product has to be rewritten or up- 107 dated to be able to resolv hostnames in a dynamically allocated 108 local domain as well. 110 2. Protocol version 1.0 112 The protocol relies on two types of messages, a request and a reply 113 -message. Both messages contain two lines of human readable 114 character-data, which end with a line-feed. The first line describes 115 the protocol version used, i.e. "LNP v.1.0" and the second line 116 describes the exchanged information. The request-data shall be 117 interpreted as qualified domain name and therefore be compared by 118 any receiver with its own hostname. Every host, that matches iden- 119 tically should then immediateliy reply with one line of human- 120 readable character-data containing the desired ip-address of the 121 interface where the request message was received on. The version of 122 the ip-address used can be determined on either dotted-decimal- 123 notation (IPv4) or colon-separated-hex-values (IPv6) [draft-main- 124 ipaddr-text-rep-02]. The appended reply-data is just useful for user 125 interaction, i.e. using the protocol on a command line interface, 126 since the receiver of the reply gets the address information about 127 the replyer from ip-header in binary format as well. 129 2.1. Wildcards 131 Due to security reasons, in protocol version 1.0 no wildcards are 132 defined or accepted. 134 2.2. Concurrent replies 136 Is more than one host at a time using the same hostname in exactly 137 the same local network, there will be multiple replies when asking 138 for this hostname. Since it is not unique, this case must be re- 139 ported, either directly to the user or at least into systems log- 140 file. The protocol implementation 1.0 defines the following method. 141 The ip of the first reply will be returned with error code set to 142 NOT_UNIQUE. Further messages shall be discarded, i.e. the socket 143 is closed. 145 2.3. No host responding 147 A timeout shall be set in case of no reply. In this case no ip- 148 address can be returned and no statement can be made, except that 149 the target host is not existent or not responding. The timeout can 150 be chosen very short, since the broadcast domain is limited to the 151 local network. 153 3. IANA Considerations 155 There has to be a well known Port number for LNP. An assignment 156 request shall be made when this document gets accepted. 158 4. Security Considerations 160 Since there are no wildcards defined in protocol version 1.0, it is 161 not possible to query all hosts ip-addresses at once. Furthermore 162 the design of the protocol respects privacy, so that the name of the 163 desired host has to be known before a valid query result can be 164 achieved. 166 5. References 168 [RFC 1002] NetBIOS Working Group in the Defense Advanced 169 Research Projects Agency, Internet Activities Board, 170 End-to-End Services Task Force,"Protocol standard for a 171 NetBIOS service on a TCP/UDP transport: Detailed 172 specifications",DOI: 10.17487/RFC1002, March 1987, 173 . 175 [RFC 1035] P.V. Mockapetris, "Domain names - implementation and 176 specification", DOI: 10.17487/RFC1035, November 1987, 177 . 179 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", 180 RFC 2131, DOI: 10.17487/RFC2131, March 1997, 181 . 183 [RFC 6763] S. Cheshire, M. Krochmal, "DNS-Based Service Discovery", 184 DOI: 10.17487/RFC6763, February 2013, 185 . 187 Author's Address 189 Christian Schaller 190 Schallsoft 191 Herderstrasse 13, 08525 Plauen 192 Germany 194 Phone: +49 3741 - 554 744 195 Email: christian.schaller@sprintmail.de 196 URI: http://www.schallsoft.de