Internet DRAFT - draft-schaller-dnsop-lnp
draft-schaller-dnsop-lnp
lnp C. Schaller
Internet-Draft Schallsoft
Intended-Status: Elective February 11, 2019
Local Naming Protocol -- LNP (v.1.0)
draft-schaller-dnsop-lnp-00
Abstract
The Local (or Lightweight) Naming Protocol (LNP) is an application-
level protocol for local area networks. It is a distributed,
stateless protocol which intents in resolving hostnames to ip
addresses without the need of any Domain Name Server. In private
local area networks, ip addressses are often dynamically allocated
through DHCP. The LNP can be seen as a DNS extension, which uses
broadcast udp messages (similar to ARP on IP-MAC-level) to request
ip addresses for hosts with a given host- or domain-name. Thus it
will be possible in dynamic local area networks to access ip-based
services on hosts by their hostnames, without further management.
Comments are solicited and should be addressed to the working
group's mailing list at dnsop@ietf.org and/or the author(s).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Schaller Expires August 11, 2019 [Page 1]
Internet-Draft LNP (v.1.0) February 2019
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Standalone LNP . . . . . . . . . . . . . . . . . . . . . 3
1.2. DNS extended LNP . . . . . . . . . . . . . . . . . . . . 3
2. Protocol version 1.0 . . . . . . . . . . . . . . . . . . . . 3
2.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Concurrent replies . . . . . . . . . . . . . . . . . . . 4
2.3. No host responding . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
In private local area networks or wireless LANs, today mainly DHCP
[RFC2131] managed ip address allocation is used. Since the equip-
ment on the market does not ship with integrated DNS servers, which
update their records when hosts attach to or detach from the net-
work, there is less help for private users or user applications
trying to access devices services over ip addresses. Actually no
service is out of the box available for all operating systems.
Microsoft Windows ships with NetBios [RFC 1002], which allows name
based access, however first after activation of file-sharing.
Apples MacOS is delivered with bonjour [RFC 6763], which runs out
of the box. Linux and Unix systems can do both, however after
explicit installation setup. All those systems are able to use DNS
[RFC 1035] when connected to ip networks. So why not extend the
functionality of the distributed Domain Name System, which already
has the task to resolv hostnames to ip addresses.
Schaller Expires August 11, 2019 [Page 2]
Internet-Draft LNP (v.1.0) February 2019
1.1. Standalone LNP
The standalone implementation of LNP uses a UDP broadcast message to
query the ip address of a host. Therefore the message contains the
full qualified name of a host connected to the local network. All
receivers check if the requested hostname equals their own. Every
matching host then replies. In version 1.0 a replying host shall
append the ip-address, bound to the interface receiving the message,
as message data. The sender now has resolved the ip-address of his
well known communication partner and can in turn open tcp-streams
and communicate directly.
1.2. DNS extended LNP
Every networking software using sockets, that relies on name reso-
lution to determine destinations ip-address will probably use a sys-
tem call e.g. getHostByName() or getAddrInfo() to retrieve the ip-
address. When every standard DNS client would be able to provide
and use LNP, i.e. in case of no matching DNS record or hosts-file
entry found, then no software product has to be rewritten or up-
dated to be able to resolv hostnames in a dynamically allocated
local domain as well.
2. Protocol version 1.0
The protocol relies on two types of messages, a request and a reply
-message. Both messages contain two lines of human readable
character-data, which end with a line-feed. The first line describes
the protocol version used, i.e. "LNP v.1.0" and the second line
describes the exchanged information. The request-data shall be
interpreted as qualified domain name and therefore be compared by
any receiver with its own hostname. Every host, that matches iden-
tically should then immediateliy reply with one line of human-
readable character-data containing the desired ip-address of the
interface where the request message was received on. The version of
the ip-address used can be determined on either dotted-decimal-
notation (IPv4) or colon-separated-hex-values (IPv6) [draft-main-
ipaddr-text-rep-02]. The appended reply-data is just useful for user
interaction, i.e. using the protocol on a command line interface,
since the receiver of the reply gets the address information about
the replyer from ip-header in binary format as well.
Schaller Expires August 11, 2019 [Page 3]
Internet-Draft LNP (v.1.0) February 2019
2.1. Wildcards
Due to security reasons, in protocol version 1.0 no wildcards are
defined or accepted.
2.2. Concurrent replies
Is more than one host at a time using the same hostname in exactly
the same local network, there will be multiple replies when asking
for this hostname. Since it is not unique, this case must be re-
ported, either directly to the user or at least into systems log-
file. The protocol implementation 1.0 defines the following method.
The ip of the first reply will be returned with error code set to
NOT_UNIQUE. Further messages shall be discarded, i.e. the socket
is closed.
2.3. No host responding
A timeout shall be set in case of no reply. In this case no ip-
address can be returned and no statement can be made, except that
the target host is not existent or not responding. The timeout can
be chosen very short, since the broadcast domain is limited to the
local network.
3. IANA Considerations
There has to be a well known Port number for LNP. An assignment
request shall be made when this document gets accepted.
4. Security Considerations
Since there are no wildcards defined in protocol version 1.0, it is
not possible to query all hosts ip-addresses at once. Furthermore
the design of the protocol respects privacy, so that the name of the
desired host has to be known before a valid query result can be
achieved.
Schaller Expires August 11, 2019 [Page 4]
Internet-Draft LNP (v.1.0) February 2019
5. References
[RFC 1002] NetBIOS Working Group in the Defense Advanced
Research Projects Agency, Internet Activities Board,
End-to-End Services Task Force,"Protocol standard for a
NetBIOS service on a TCP/UDP transport: Detailed
specifications",DOI: 10.17487/RFC1002, March 1987,
<https://www.rfc-editor.org/rfc/rfc1002.txt>.
[RFC 1035] P.V. Mockapetris, "Domain names - implementation and
specification", DOI: 10.17487/RFC1035, November 1987,
<https://www.rfc-editor.org/rfc/rfc1035.txt>.
[RFC 2131] R. Droms, "Dynamic Host Configuration Protocol",
RFC 2131, DOI: 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/rfc/rfc2131.txt>.
[RFC 6763] S. Cheshire, M. Krochmal, "DNS-Based Service Discovery",
DOI: 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763.txt>.
Author's Address
Christian Schaller
Schallsoft
Herderstrasse 13, 08525 Plauen
Germany
Phone: +49 3741 - 554 744
Email: christian.schaller@sprintmail.de
URI: http://www.schallsoft.de
Schaller Expires August 11, 2019 [Page 5]
