Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization
Extracted elements (27)
For SEND requests when the target's location is known, only actions a.2 (unicast to target's RBridge) or a.5 (flood) are valid because cryptography prevents the ingress RBridge from constructing a locally generated SEND reply—the RBridge cannot sign the response with the target's private key.
IP address resolution creates significant flooding issues in data centers. Proxy ARP/ND on edge RBridges avoids this flooding. When all IP/MAC mappings are known via management, control plane, or data-plane snooping, flooding of ARP/ND can be completely suppressed.
When complete directory information is available, data-plane learning of end-station MAC addresses is not only unnecessary but could be harmful if frames with forged source addresses are learned. TRILL already provides an option to disable data-plane learning from source MAC of end-station frames.
SEND (Secure Neighbor Discovery, RFC 3971) messages cannot be optimized by this mechanism because RBridges do not have cryptographic keys needed to construct SEND messages. RBridges only construct ARP, RARP, or insecure ND messages; they are transparent to SEND messages in terms of response generation.
A dynamic proxy ARP/ND entry (learned from data-plane observation) MUST be removed from the cache table if the link over which it was learned fails.
A dynamic proxy ARP/ND entry SHOULD be flushed if the IP/MAC address mapping has not been refreshed within the age-time. The Ageing Timer is configurable per RBridge and defaults to 3/4 of the MAC address learning Ageing Timer defined in RFC 6325.
An Address Probe ARP query (sender's protocol address is zero, per RFC 5227) or a Neighbor Solicitation for DAD with an unspecified source address (RFC 4862) SHOULD be handled the same as a generic ARP/ND request.
If the ingress RBridge receives a generic ARP/ND/SEND request and does not know the target's IP address, it MUST take one of: (b.1) flood per RFC 6325, (b.2) pull from a directory server and reply, or (b.3) drop the message if the directory authoritatively indicates the address is nonexistent.
If the sender's IP has been seen before but with a different MAC address or a different ingress nickname, the RBridge SHOULD verify whether a duplicate IP address is in use or the end station has moved. The RBridge SHOULD update the saved {IP, MAC, ingress nickname} triplet based on verification results.
RARP (Ethertype 0x8035) SHOULD be handled by doing a local cache or directory server lookup on the target hardware (MAC) address to find a mapping to the desired protocol (IP) address, analogously to generic ARP request/response handling.
RBridges implementing ARP/ND optimization SHOULD snoop on SEND messages to extract the addressing information that would be present if the SEND had been sent as an insecure ND message.
RBridges MAY implement an 'optimized ARP/ND response' when the target's location is known by the ingress RBridge or can be obtained from a directory, avoiding ARP/ND query and answer flooding.
The ingress RBridge MAY use the IA APPsub-TLV with the Local flag set in ESADI to distribute any new or updated {IP address, MAC address, ingress nickname} triplet obtained from snooping ARP/ND messages.
When a duplicate IP address is confirmed (the former owner replies to a DAD-query), the querying RBridge SHOULD log the duplicate so the network administrator can take appropriate action.
When an end station moves to a new edge RBridge (MAC/VM mobility), the old ARP/ND cache entry on the previous RBridge SHOULD be replaced, and all other edge RBridges with end-station service enabled for that Data Label should update the entry to show reachability from the new RBridge.
When complete Push Directory information is used by all RBridges in a Data Label, a gratuitous ARP or unsolicited Neighbor Advertisement SHOULD be discarded rather than ingressed and flooded, to prevent forged announcements from corrupting the directory-based view.
When egress RBridge R2 receives a forwarded ARP/ND query and the target responds, R2 SHOULD initiate a link state update via IA APPsub-TLV in ESADI (or per RFC 8171 if using Push Directory) to inform all other RBridges of the target's location, Layer 3 address, and Layer 2 address.
When sending an ND response on behalf of a target, the source IP address for the ND response MUST be that of the target end station, because the edge RBridge might not have an IPv6 address.
A Duplicate Address Detection query (DAD-query) is a unicast ARP/ND message sent by an RBridge to the former owner of an IP address when a mapping conflict is detected. For ARP, the sender IP is 0.0.0.0 (or a configurable DAD-Query source IP); for ND, the source is an IPv6 Link Local Address. The source MAC is the querying RBridge's MAC.
ARP native frames are detected by Ethertype 0x0806; ND frames are detected as one of five specific ICMPv6 packet types. ARP/ND is used to query MAC addresses, detect duplicate IP addresses, and announce new or updated IP/MAC/attachment-point information.
Edge RBridges should snoop DHCP messages (primarily DHCPAck) exchanged by newly connected end stations, store the resulting IP/MAC address mapping in the ARP/ND cache, and distribute it via ESADI.
RBridges maintain a triplet of {IP address, MAC address, ingress nickname} per Data Label (VLAN or FGL) for each known end station. This triplet is the core data structure for ARP/ND optimization and can be locally learned or received via ESADI or directory.
The IA APPsub-TLV (RFC 7961) distributed via ESADI (RFC 7357) is the control-plane mechanism for distributing IP/MAC address mappings between RBridges. It includes a Flags field to identify whether the source is a directory server or local observation, plus a confidence level.
In data-plane mode, ARP and ND messages can be easily forged without SEND, making IP/MAC learning from ARP/ND hackable. Link-layer security (IEEE 802.1AE) between end stations and edge RBridges could improve security but imposes requirements on end stations that conflict with TRILL's goal of operating with unmodified end stations.
RBridges should rate limit ARP/ND queries injected into the TRILL campus to limit potential denial-of-service attacks where an attacker generates excessive ARP/ND traffic.
The confidence level in IA APPsub-TLV information received via ESADI or Pull Directory allows an RBridge to arbitrate between conflicting IP/MAC address mapping information from different sources (directory vs. locally learned), enabling the implementer to weight more reliable sources over less reliable ones.
When directory information (RFC 8171) is trustworthy and complete, ARP/ND responses can be entirely directory-based, bounding the damage that forged ARP/ND messages can do. Incomplete or unreliable directory data can be combined with data-plane-learned data arbitrated by the confidence level in the IA APPsub-TLV.