One of the chief goals of standards bodies is to achieve interoperability through the clear and precise specification of interfaces and protocols. Interoperability means that hardware and software from diverse vendors can all work together in the same network. No one vendor has to supply every conceivable device and feature. No enterprise is constrained to commit to a single vendor.
The Internet Engineering Task Force (IETF) publishes its specifications as Requests for Comments (RFCs). The key words and phrases used to precisely define requirements in IETF specifications are defined in RFC 2119.
MUST, REQUIRED, and SHALL indicate absolute requirements of a specification.
MUST NOT and SHALL NOT indicate absolute prohibitions of a specification.
SHOULD and RECOMMENDED indicate items which can be omitted given valid reasons.
SHOULD NOT and NOT RECOMMENDED indicate items which can be accepted given valid reasons.
An implementation which satisfies all MUST, MUST NOT, SHOULD and SHOULD NOT requirements is said to be unconditionally compliant.
An implementation which satisfies all MUST and MUST NOT requirements but not all SHOULD and SHOULD NOT requirements is said to be conditionally compliant.
An implementation which fails to satisfy one or more MUST or MUST NOT requirements is not compliant and is occasionally referred to as non-RFC compliant.
Interlink Networks and Interoperability
Interlink Networks’ philosophy for attaining the highest levels of interoperability is to deliver products which are:
- Unconditionally compliant
All packets and attributes generated and transmitted by the software are unconditionally compliant with the applicable RFC standards.
- Forgiving of other non-RFC compliant implementations
To the extent that it does not impact the integrity of an application received packets which are non-RFC compliant packets can be processed.
An example is the requirement in RADIUS RFC 2865 that an Access-Request MUST contain one or more of the NAS-IP-Address, NAS-Identifier or NAS-IPv6-Address attributes. Many early RADIUS clients and some more recent lite RADIUS clients fail to do this and are technically non-RFC compliant. However, since these attributes are not used in some applications the Interlink Networks RAD-Series RADIUS Server can accept and process these requests.
- Configurable to enforce or ignore a client device’s RFC compliance
The RAD-Series RADIUS Server administrator can configure whether or not to strictly enforce many RFC compliance requirements for received packets on a client by client basis and others on a global basis.
Using the Advanced Policy Engine feature standard in all RAD-Series RADIUS Servers, attributes can be filtered, added, and modified in order to adapt to non-RFC compliant RADIUS clients. The standard Finite State Machine (FSM) table has hooks for filtering inbound and outbound packets on interfaces to both RADIUS clients and remote RADIUS servers.
Interoperability is very important to us at Interlink Networks. If you think some aspect of our software is failing to be unconditionally compliant please contact technical support to give us the details. If you have a vendor device which needs a new dictionary or other vendor specific support please request this as a new feature.
Comments are closed.