При получении запроса или отклика ARP все реализации должны понимать кадры без поля RIF (локальное кольцо) и с пустым полем RIF (также из локального кольца). Если реализация поддерживает source routing для множества колец, непустые RIF сохраняются для будущих передач хостам, отправившим исходный запрос или отклик ARP. Если source routing не поддерживается, все пакеты с непустым полем RIF должны игнорироваться. Это правило будет обеспечивать интероперабельность для всех реализаций в одном кольце независимо от поддержки расширения для множества колец.
При передаче запроса ARP с помощью широковещательного пакета all-routes возможно получение множества копий в результате пересылки запроса через несколько мостов. Однако, такие копии придут по разным маршрутам и будут различаться полями RIF. Реализация ARP в таком контексте должна выбрать одну из копий для использования, игнорируя прочие.
Существует три варианта стратегии для таких случаев:
взять первый пакет, игнорируя остальные (т. е. при наличии записи в кэше ARP она не будет изменяться),
взять последний запрос (т. е. всегда обновлять кэш ARP по последнему сообщению ARP) или
взять пакет, доставленный кратчайшим путем (т. е. обновить запись в кэше ARP, если новое сообщение доставлено по более короткому маршруту).
Поскольку выбор стратегии не влияет на интероперабельность, окончательное решение остается за разработчиками. Получатель запроса ARP должен передать отклик ARP как сообщение точка-точка, используя RIF.
Информация RIF должна сохраняться отдельно от таблицы ARP. Т. е., в принципе существует таблица ARP для отображения адресов IP в 48-битовые адреса 802 и таблица RIF для отображения этих адресов в маршруты 802.5 source routes (при необходимости). Для практической реализации может оказаться более удобным совместное хранение информации ARP и RIF. Совместное хранение информации может ускорить доступ при ее использовании. С другой стороны, при реализации для всех типов сетей 802 может расходоваться значительное количество памяти для кэша ARP при резервировании в каждой записи этого кэша места для информации RIF.
Широковещательные дейтаграммы IP должны передаваться с использованием широковещательных кадров 802.5 single-route. В отличие от ARP, широковещательные кадры all-routes являются нежелательными для IP. Получение множества копий широковещательных пакетов IP будет приводить к нежелательным эффектам для многих протоколов, использующих IP. Как и для случая ARP при получении пакета IP все реализации должны понимать кадры без RIF и с пустым полем RIF.
Поскольку современный аппаратный интерфейс допускает только один групповой адрес, а функциональные адреса не являются уникальными в глобальном масштабе, IP и ARP не используют эти возможности. Более того, сети стиля IBM 802.5 поддерживают для пользовательского определения лишь 31 функциональный адрес.
Предпочтения IP должны отображаться в приоритеты 802.5. Все пакеты IP и ARP должны передаваться с принятым по умолчанию уровнем приоритета 802.5 (это значение равно 3).