[Select]

Networking
Index

 

ZeroConf

Introduction

The ZeroConf module deals with Link-Local zero-configuration network address assignment. This module has been present since Select 3. The implementation follows that of RFC3927. The module can only handle a single interface. It will be automatically configured by the InetConfigure module when 'Dynamic' network addressing is configured.

The ZeroConf module will always configure alias 9 of an interface, for example 'eh0:9'.

Programmers Interface

SWI ZeroConf_Control (&56A00)
On entry
   R0 = control type:
         0 = add interface
         1 = remove interface
         Others reserved
   Other registers dependent on reason code
On exit
   Dependent on reason code

This SWI is used to control the operation of the ZeroConf module.

SWI ZeroConf_Control 0 (Add interface)
On entry
   R0 = 0
   R1 = pointer to interface name
On exit
   All registers preserved

This SWI is used to add an interface to those that the ZeroConf module controls. Only a single interface can be controlled by the ZeroConf module. An error will be returned if the interface cannot be added.

SWI ZeroConf_Control 1 (Remove interface)
On entry
   R0 = 1
   R1 = pointer to interface name
On exit
   All registers preserved

This SWI is used to remove an interface from those that the ZeroConf module controls. If the interface named is not controlled by ZeroConf an error is returned.

SWI ZeroConf_Status (&56A01)
On entry
   R0 = status type:
         0 = read configuration state
         Others reserved
On exit
   R0 = state of ZeroConf module:
         0 = idle
         1 = probing for address
         2 = announcing address assignment
         3 = configured
         4 = configured, defending against address collision
   R1 = pointer to interface name

This SWI is used to read the state of the operation of the ZeroConf module.

Service calls

Service_InternetStatus &20 (Service Call &B0)
On entry
   R0 = &20 (subreason code)
   R1 = &B0 (reason code)
   R2 = pointer to aliased interface name (eg "ea0:9")
   R3 = IP address assigned to interface
On exit
   R0-R3 preserved.

This service call is issued by the ZeroConf module when it has successfully configured an interface with a link-local address. This address may be used just like any other address. This address may be changed (and the appropriate services issued) if collisions occur or if manually modified.

This service should never be claimed.

Service_InternetStatus &21 (Service Call &B0)
On entry
   R0 = &21 (subreason code)
   R1 = &B0 (reason code)
   R2 = pointer to aliased interface name (eg "ea0:9")
   R3 = IP address that was assigned to aliased interface
On exit
   R0-R3 preserved

This service call is issued by the ZeroConf module when it has lost the link-local address allocated to an interface. A new address may be reestablished by the ZeroConf module if the reason for the address loss was due to a collision.

This service should never be claimed.

Conformance

The ZeroConf module and other components of the stack follow the protocol laid down by this RFC with certain caveats :

  • Link-local addresses assigned to interfaces with routable addresses will continue to be advertised by the Internet stack through the SIOCGIFCONF interface. (1.9 rule 2)
  • No operational changes have been made to prevent the issuing of link-local packets to a router, or forwarding by a router if so configured. (2.6.2, 2.7, 7)
  • The use of subnetting is not prevented. (2.8)
  • DNS addresses supplied by external sources may be cached for link-local addresses. (2.9)
  • DNS server may provide locally known link-local addresses. (2.9)
  • Operation where multiple interfaces use link-local addresses is not supported by the ZeroConf module and, where manual configuration occurs is not expected to route correctly. (3)

Select 3 ZeroConf implementation follows draft 7 of the link-local standard and had the following differences from the released RFC :

  • 4 probes will be sent initially (RFC now states 3).
  • The maximum number of conflicts before rate limiting was 60, RFC now states 10

This documentation is copyright 3QD Developments Ltd 2013 and may not be reproduced or published in any form without the copyright holders permission. RISC OS is subject to continuous development and improvement as such all information is reproduced by 3QD Developments Ltd in good faith and is believed to be correct at the time of publication E&OE. 3QD Developments Ltd cannot accept any liability for any loss or damage arising from the use of any information provided as part of the RISC OS Documentation.

HTML document version 1.03 3rd November 2015