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'.
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).
Service calls
| R0 | = | 32 (sub-reason code> |
| R1 | = | &B0 (reason code) |
| R2 | = | Pointer to zero-terminated aliased interface name |
| R3 | = | IP address assigned to the interface |
| R1 - 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.
| R0 | = | 33 (sub-reason code> |
| R1 | = | &B0 (reason code) |
| R2 | = | Pointer to zero-terminated aliased interface name |
| R3 | = | IP address that was assigned to the interface |
| R1 - 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.
SWI calls
| R0 | = | Reason code:
| ||||||
| R1 - R8 | = | Dependant on reason code |
| R0 - R8 | = | Dependant on reason code |
This SWI is used to control the operation of the ZeroConf module.
| R0 | = | 0 (reason code) |
| R1 | = | Pointer to zero-terminated interface name |
| R0 - R1 | 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.
| R0 | = | 0 (reason code) |
| R1 | = | Pointer to zero-terminated interface name |
| R0 - R1 | 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 will be returned.
| R1 | = | Status type:
| ||||
| R1 - R8 | = | Dependant on reason code |
| R0 - R8 | = | Dependant on reason code |
This SWI is used to read the status of the ZeroConf module.
| R1 | = | 0 (reason code) |
| R0 | = | State of the ZeroConf module
| ||||||||||||
| R1 | = | Pointer to zero-terminated interface name |
This SWI is used to read the state of the operation of the ZeroConf module.