Subject: zeroconf issues

From: [email-masked]
Date: Tue, 24 Jul 2001 08:29:06 +0200

Dear all,

Attached you will find an internet draft that serves as input for a discussion
on the ZeroConf charter to be held during the IETF meeting in August.
Unfortunately, I was too late for posting it as a draft because of forced holidays
and removal from one buidling to another.

Peter

(See attached file: issues.txt)

Peter van der Stok                Philips Research Laboratories Eindhoven
Bldg: WL P 311                      Prof. Holstlaan 4
Phone: +31 40 2742649       5656 AA Eindhoven
Fax:       +31 40 274                The Netherlands
Mailto: Peter.van.der.Stok@ philips.com

Internet Egineering Task force                        Peter van der Stok
INTERNET DRAFT                                          Philips Research
6 July 2001
Expires in 6 months

                   Issues for ZeroConf Working group
                draft-vanderstok-zeroconf-issues-00.txt

Status of This Memo

   This document is an individual contribution to the Internet
   Engineering Task Force (IETF).  Comments should be submitted to the
   [email-masked] mailing list.

   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.

   Table of Contents

   1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3. Wireless networks . . . . . . . . . . . . . . . . . . . . . . . 3
   4. Security considerations . . . . . . . . . . . . . . . . . . . . 4
   5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   6. Author's address. . . . . . . . . . . . . . . . . . . . . . . . 4
   7. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 5

Abstract This note considers some issues forthcoming from in-home
   networks that use the ZeroConfiguration protocols as network layer.

van der Stok, Peter     Expires: 23 January 2002                [Page 1]

Internet Draft              ZeroConf issues                   July 2001

1. Introduction

   The Zeroconf requirements [IDZR] and the link-local protocol [IDLL]
   are a good basis for the allocation of network addresses to the hosts
   in a home network.  Both documents consider networks where no
   management by the user is needed. The network can range from an ad-
   hoc network of two hosts to a larger stand-alone network comprising
   several bridged networks without DHCP server [RFC2131] to a network
   connected to the internet with administration by a DHCP server. The
   DHCP server is possibly configured by the internet services provider
   without intervention by the owner or user of the home network.

   This note considers a zero configuration network for the home. A
   number of consumer electronic appliances are interconnected, possibly
   also connected to one or more general purpose computers. Two specific
   aspects of these networks have consequences for the ZeroConf working
   group: (1) naming of appliances and (2) roaming of appliances in
   wireless networks.

2. Naming

   Users of the network will like to name their appliances (e.g. MyTV or
   tuner.in.the.bedroom) to address them by name for the execution of
   commands or the exchange of Audio/Video (A/V) streams. Traditionally,
   Domain Name System (DNS) [RFC 1034][RFC 1035] stores these names,
   associates a name with an IP address and returns an IP address for a
   given name. A multicast DNS [IDmDNS] is foreseen for small home
   networks to operate without a DNS server. In the DNS protocol it is
   foreseen that

   - domain names are provided, possibly structured and associated with a zone,
   - a specified server is authorative for a set of zones.

   The protocol foresees dynamic updates of the entries in the server by
   authorised sources [RFC 2136][RFC 3007]. This section considers the
   issues associated with the management of the name server(s).

   A home network can be in two possible states:
   (1) stand alone with no connection to internet
   (2) connected to the internet

   A connection to the internet can be provided through a residential
   gateway via a cable network or via the telephone connected to an
   Internet provider.  In the first case a DHCP server may be present
   and in the second case a DHCP server is present. A home network may
   pass from state 1 without DHCP server to state 2 with DHCP server
   because the user starts a connection with Internet from one of the
   connected appliances.

   There are a number of questions that need to be considered in the
   case of a stand alone home network without DHCP server. A boundary

van der Stok, Peter     Expires: 23 January 2002                [Page 2]

Internet Draft              ZeroConf issues                   July 2001

   condition is that users should not be bothered to specify a server or
   the server contents.

   a) what does the name space structure look like. Is there a fixed root name
      like .local.arpa?
   b) How many zones will there be and which host is the authoritative
      server for any zone.
   c) Do we need an authoritative server at all?
   d) When there are several candidate servers which one will be the
      authoritative one?
   e) What will happen if there are no candidate servers?
   f) Are multiple names possible for a single IP address?
   g) What to do in case of name clashes?

   When the network switches from stand-alone to connected a number of
   other questions need to be addressed. Within the context of the SIP
   protocol [RFC 2543] there have been efforts to setup an addressing
   scheme from the internet to the home network [IDSIP]. The following
   additional questions can be asked:

   h) Which of the named appliances are visible to the whole internet?
   i) Do the names of the DNS server mentioned in the DHCP server replace
      the existing ones?
   j) Do multiple names exist and what is their visibility?
   k) What happens if there are clashes between external names and local names?
   l) What is the relation of the local domain name structure, local domain
      name and local zone to the ones of the external server.

3. Wireless networks

   The most challenging part of wireless networks are the mobility of
   the hosts and the sensitivity of the network configuration to
   distance and barriers between individual hosts. This means that by
   moving a wireless device (e.g. PDA) around it may become visible to
   multiple home networks.  Such a device may be part of a home network
   A and by moving it to the neighbour remains part of home network A,
   becomes visible to home network B of the neighbour and can be
   declared a member of network B.

   From that moment on networks A and B become one network and provide
   unique link-local addresses over both networks. However, how will
   name spaces be organised? The above questions a-l have to be answered
   for this case as well.

   Wireless networks are more sensitive to disturbances. Consequently,
   hosts may become disconnected and reconnect to the network with a
   high frequency. These (dis)connections have an impact on the number
   of ARP messages that are sent. It may be worthwhile to publish
   recommendations in case of frequent (dis)connections to reduce the
   amount of network traffic and modifications to the contents of the
   server.

van der Stok, Peter     Expires: 23 January 2002                [Page 3]

Internet Draft              ZeroConf issues                   July 2001

4. Security considerations

   It is easy for any passing device to listen to a close wireless
   network unless special precautions are taken. It can be assumed that
   most MAC protocols for wireless connections address this subject. A
   recommendation that encryption must be provided by the wireless
   network is probably understood. Mechanisms for an adequate protection
   are assumed to be provided such that unknown persons cannot interpret
   the datastream or join the network. It is up to the user to exploit
   these mechanisms. This is similar to the security requirements
   provided for your wireless DECT network at home.

   However, there are a few security aspects that need further attention
   in the context of name servers. In [RFC 3007] already a few
   recommendations have been done. It is necessary to distinguish a
   stand alone network and a connected home network. In the stand-alone
   network, security is less an issue than in the case of a connected
   network (excepted the wireless case explained above). In both states
   of the network a few issues need to be addressed:

   m) Who has authority to allocate a name to an IP address?
   n) What is a trusted person or host?
   n) Can a trusted person always add/delete names to the name space?
   o) Who has authority to allocate a name to an IP address?
   p) When two networks join, are all names visible to both networks?
   q) Can a new named device that entered the network automatically be
      added to the name space with its IP address, provided there are no name
      clashes?

5 References

   [IDZR]     H. Hattig. "Zeroconf Requirements", Internet Draft, Work
              in progress, May 2001.

   [IDLL]     S. Cheshire and B. Aboba. "Dynamic Configuration of IPv4
              Link-Local Addresses", Internet Draft, Work in Progress,
              June 2001.

   [RFC 2131] R. Droms. "Dynamic Host Configuration Protocol", RFC 2131,
              March 1997.

   [RFC 1034] P. Mocapetris. "Domain names - Concepts and facilities",
              RFC 1034, November 1987.

   [RFC 1035] P. Mocapetris. "Domain names - Implementation and
              Specification", RFC 1035, November 1987.

   [IDmDNS]   L. Esibov et al. "Multicast DNS", Internet Draft, Work in
              Progress, July 2001.

van der Stok, Peter     Expires: 23 January 2002                [Page 4]

Internet Draft              ZeroConf issues                   July 2001

   [RFC 2136] P Vixie et al. "Dynamic Updates in the Domain Name Systems
              (DNS UPDATE)", RFC 2136, April 1997.

   [RFC 3007] B. Wellington. "Secure Domain name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC 2543] M. Handley and al. "SIP: Session Initiation protocol", RFC
              2543, March 1999.

   [IDSIP] S. Myer et al. "SIP for Bulbs", Internet Draft, Work in
              progress, August 2000.

6. Author's Contact Information

   Peter van der Stok
   Philips Research
   Prof. Holstlaan 4
   Bldg WL P 3.11
   5656 AA Eindhoven
   The Netherlands

   Phone:  +31 40 27.42649

   Email:  [email-masked]

7. Full Copyright Statement

Copyright (C) The Internet Society (1999).  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

van der Stok, Peter     Expires: 23 January 2002                [Page 5]

Internet Draft              ZeroConf issues                   July 2001

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."

van der Stok, Peter     Expires: 23 January 2002                [Page 6]