ZeroConfNetworking

Differences between revisions 4 and 6 (spanning 2 versions)
Revision 4 as of 2006-11-08 22:48:36
Size: 3690
Editor: 207
Comment: fleshed out summary, rationale, and use cases
Revision 6 as of 2006-11-08 23:36:05
Size: 4619
Editor: 207
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * '''Packages affected''': `avahi-autoipd`, `libnss-mdns`  * '''Packages affected''': `basefiles`, `dhclient`, `zeroconf`, `libnss-mdns`, `network-manager`, `avahi-autoipd`, `avahi-daemon`, `ifupdown`, `gnome-system-tools`
Line 10: Line 10:
When a dynamic network configuration is desired and a local DHCP server is not available for a network, Ubuntu needs to correctly assign itself a link-local address. This is implemented by `avahi-autoipd`, but requires some additional configuration and packaging corrections to have the expected proper behavior. When a dynamic network configuration is desired and a local DHCP server is not available for a network, Ubuntu needs to correctly assign itself a link-local address. This is implemented by `avahi-autoipd`, but requires some additional configuration and packaging corrections to have the system behave in a fully correct way.
Line 13: Line 13:
Using link-local addresses for communicating on adhoc networks or local LANs without a DHCP server works for other operating systems. Having Ubuntu work correctly in these situations makes users more productive because they will be able to communicate with other link-local devices without having to do anything special. Other operating system correctly use link-local addresses for communicating on adhoc networks or local LANs without a DHCP server. Ubuntu users will be much happier and more productive when they are effortlessly able to communicate with other device with link-local addresses.
Line 17: Line 17:
 1. Claudia's home network does not have a DHCP server, and does not want to have to define a static IP address for her laptop. She still be able to communicate with other devices on the network.
 2. John's desktop computer was booted and it got a link-local address. Then he adds a DHCP server
to his network, and boots a second computer that gets a regular DHCP-assigned address. He wants these two devices to communicate with eachother.
 3. Mary uses a name server that makes a `.local` top-level-domain available, and she upgrades her computer from Edgy to Feisty, where link-local addresses are assigned. She needs notification that the unicast `.local` TLD and the link-local `.local` domain conflict with eachother, offering a hint on how to disable link-local assignments.
 1. Claudia and Mary set up an adhoc wireless network between between their laptops. They want to be able to communicate without needing to do anything special with interface address assignments.
 2. John
's home server was booted and it got a link-local address. He adds a DHCP server to his network, and boots his laptop, which receives a regular DHCP-assigned address. He wants his server and laptop to be able to communicate without fiddling with their interfaces.
 3. Ellen uses a name server that makes a `.local` top-level-domain available. She upgrades her computer from Edgy to Feisty, where link-local addresses are assigned by default. She needs notification that the unicast `.local` TLD and the link-local `.local` domain conflict with each other, and offer her instructions on how to disable link-local assignments.
Line 23: Line 23:
Line 25: Line 26:
 * After coming up, interfaces must be able to correctly route traffic to the local network for the link-local IANA network (169.254.0.0/16).
 * Dynamic interfaces that do not get a DHCP address must assign themselves a link-local address.
 * The `.local` TLD must be resolvable via the link-local mDNS.
 * Users new to link-locale addressing need to be educated about the changes.
Line 28: Line 33:
 * basefiles(?) update to include description of link-local network  * `basefiles`(?) -- for educational purposes, update to include description of link-local network
Line 30: Line 35:
 * dhclient hook for DNS changes to check for unicast "local" TLD
  * `if ! host -t soa local. >/dev/null 2>&1; then dbus-msg OMGPONIES; fi`
 * zeroconf
 * `dhclient` -- add hook for DNS changes to check for unicast "local" TLD
  * When a unicast `local` TLD is available, notify the user about the problem, and offer to fix it
   {{
if ! host -t soa local. >/dev/null 2>&1; then NOTIFY; fi
}}
 * `zeroconf` -- inco
mpatible with avahi
Line 34: Line 41:
 * libnss-mdns  * `libnss-mdns` -- to resolve link-local `local` TLD
Line 38: Line 45:
   * audit for error conditions around nsswitch.conf updating sanity    * audit for error conditions around automatic update of the `nsswitch.conf` 'hosts' line
Line 40: Line 47:
 * network manager
  * patch with proper avahi ll hooks, especially adhoc modes
 * avahi-autoipd
  * audit and promote to main (see http://avahi.org/wiki/SecurityConsiderations)
 * `network-manager`
  * patch with proper avahi link-local hooks, especially for adhoc modes
 * `avahi-autoipd` -- the actual core of ipv4ll assignment
  * audit and promote to main
Line 45: Line 52:
 * avahi-daemon  * `avahi-daemon`
Line 48: Line 55:
 * ifupdown, g-s-t
  * patch to include "ipv4ll" method for sane configuration in /etc/network/interfaces
 * `ifupdown`, `gnome-system-tools`
  * patch to include "ipv4ll" method (as opposed to "dhcp", "static", etc) for sane configuration in /etc/network/interfaces
Line 54: Line 61:

== Unresolved issues ==

== BoF agenda and discussion ==
Line 66: Line 69:
DNS-sd allows for service discovery using mDNS. DNS-sd allows for service discovery using mDNS (which is out of scope for this spec).

== Comments ==
 * To potentially assist in auditing, there are some items already available for review at http://avahi.org/wiki/SecurityConsiderations

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

When a dynamic network configuration is desired and a local DHCP server is not available for a network, Ubuntu needs to correctly assign itself a link-local address. This is implemented by avahi-autoipd, but requires some additional configuration and packaging corrections to have the system behave in a fully correct way.

Rationale

Other operating system correctly use link-local addresses for communicating on adhoc networks or local LANs without a DHCP server. Ubuntu users will be much happier and more productive when they are effortlessly able to communicate with other device with link-local addresses.

Use cases

  1. Claudia and Mary set up an adhoc wireless network between between their laptops. They want to be able to communicate without needing to do anything special with interface address assignments.
  2. John's home server was booted and it got a link-local address. He adds a DHCP server to his network, and boots his laptop, which receives a regular DHCP-assigned address. He wants his server and laptop to be able to communicate without fiddling with their interfaces.
  3. Ellen uses a name server that makes a .local top-level-domain available. She upgrades her computer from Edgy to Feisty, where link-local addresses are assigned by default. She needs notification that the unicast .local TLD and the link-local .local domain conflict with each other, and offer her instructions on how to disable link-local assignments.

Scope

Design

  • After coming up, interfaces must be able to correctly route traffic to the local network for the link-local IANA network (169.254.0.0/16).
  • Dynamic interfaces that do not get a DHCP address must assign themselves a link-local address.
  • The .local TLD must be resolvable via the link-local mDNS.

  • Users new to link-locale addressing need to be educated about the changes.

Implementation

  • basefiles(?) -- for educational purposes, update to include description of link-local network

    • add "link-local 169.254.0.0" to /etc/networks
  • dhclient -- add hook for DNS changes to check for unicast "local" TLD

    • When a unicast local TLD is available, notify the user about the problem, and offer to fix it

      • {{if ! host -t soa local. >/dev/null 2>&1; then NOTIFY; fi

}}

  • zeroconf -- incompatible with avahi

    • remove package from archive
  • libnss-mdns -- to resolve link-local local TLD

    • start with version 0.8-5
    • audit and promote to main
    • read debian #393711
      • audit for error conditions around automatic update of the nsswitch.conf 'hosts' line

    • build package with --disable-legacy (drops ministack)

  • network-manager

    • patch with proper avahi link-local hooks, especially for adhoc modes
  • avahi-autoipd -- the actual core of ipv4ll assignment

  • avahi-daemon

    • enable by default
  • in /etc/network/interfaces add some comments on how to set up manual ll addresses correctly.
  • ifupdown, gnome-system-tools

    • patch to include "ipv4ll" method (as opposed to "dhcp", "static", etc) for sane configuration in /etc/network/interfaces

Code

Data preservation and migration

Clarification of terminology

Zeroconf is a collection of protocols including ipv4 link local, mdns, and dns service-discovery. Apple's implementation of zeroconf was named "Rendezvous", and was later renamed to "Bonjour". Avahi is a free software implementation of zeroconf. See http://avahi.org/wiki/AboutAvahi.

IPv4 link-local addresses are in the 165.254.0.0/16 space.

mDNS is DNS over multicast on the local network.

DNS-sd allows for service discovery using mDNS (which is out of scope for this spec).

Comments


CategorySpec

ZeroConfNetworking (last edited 2008-08-06 17:00:50 by localhost)