A Link-Layer Tunneling Mechanism for Unidirectional Links
Extracted elements (29)
Feed tunnel end-points are configured manually at feeds (not dynamically) because the number of feeds is expected to be small, making manual configuration feasible while avoiding the complexity of a dynamic discovery protocol between feeds.
GRE (RFC 2784) was chosen as the recommended tunneling mechanism because it provides a protocol for encapsulating arbitrary packets including IP and ARP datagrams and allows use of IP as the delivery protocol, satisfying the link-layer emulation requirement.
The mechanism emulates a broadcast bidirectional link-layer network rather than an NBMA or layer-3 network because a broadcast link-layer allows immediate use of any network layer protocol including ARP, without requiring changes to higher-level protocols.
Legacy receivers may listen on the old DTCP announcement address 224.0.1.124. Feeds SHOULD support dual announcement to both old and new addresses during transition. Old feeds MUST be updated to support the new announcement address.
To ensure interoperability, implementations must agree on a usage profile specifying the MAC format, tunneling mechanism (GRE recommended), and tunnel type indication if GRE is not used. Claiming conformance with the mechanism alone is insufficient.
A feed MUST be a router. It cannot be a simple host.
A feed MUST maintain a list of all other feed tunnel end-points, and this list MUST indicate which are send-only feed tunnel end-points.
As long as a feed is up and running, it MUST send HELLO packets containing a JOIN command every HELLO_INTERVAL (5 seconds) over the unidirectional link.
Due to existing deployments, a feed SHOULD also support the use of the old DTCP announcement address (224.0.1.124) in addition to the new address (224.0.0.36).
Feeds SHOULD be configurable to send announcements simultaneously to both the 'DTCP announcement' address and the 'old DTCP announcement' address to support legacy receivers.
If the HELLO_INTERVAL is increased, the feed MUST continue to send HELLO messages at the old rate for at least the old HELLO_LEAVE period.
Only support for the MAC addressing scheme of the unidirectional link MUST be implemented for GRE encapsulation on the receiver.
Receivers MUST use the tunnel encapsulation type indicated by the Tunnel Type field in the HELLO message when tunneling to a feed.
Routing protocols running on top of the link-layer tunneling mechanism MUST use authentication mechanisms when available, to prevent unauthorised receivers from providing fake routing information.
The DTCP Vers field MUST be set to DTCP_VERSION (1). The reserved fields (res and reserved) MUST be zero.
When a receiver is started, it MUST run a process which joins the 'DTCP announcement' multicast group and listens to incoming packets on the HELLO_PORT from the unidirectional link.
HELLO_LEAVE is defined as 3×Interval (15 seconds at the default 5-second interval). An active feed entry is removed from the receiver's list when its timer expires without a refreshing JOIN message.
The DTCP Com field supports two commands: JOIN (value 1) announces the feed is up and running, and LEAVE (value 2) announces the feed is shutting down. These drive the receiver's active feed list management.
The Dynamic Tunnel Configuration Protocol (DTCP) is a unidirectional protocol where feeds periodically broadcast HELLO messages over the unidirectional link to announce their tunnel end-points. Receivers listen to these announcements to dynamically discover and maintain a list of operational feed tunnel end-points.
The F bit in the HELLO message indicates feed type: 0 = send-only feed, 1 = receive-capable feed. This allows receivers to distinguish between feed capabilities.
The Sequence field (16 bits) is initialized to a random value at boot time and incremented by 1 whenever any value in the HELLO message changes. Receivers use it to determine whether to update or just refresh the timer for an existing feed entry.
The Tunnel Type field (8 bits) in HELLO uses the IP protocol number from RFC 1700 to indicate the tunneling protocol. Value 47 (GRE) is recommended; other values permitting link-layer encapsulation are allowed.
IANA reserved multicast address 224.0.0.36 for the 'DTCP announcement' group used by DTCP HELLO messages sent over the unidirectional link.
IANA reserved UDP port 652 for HELLO_PORT, used by feeds to send DTCP HELLO packets. No other traffic is permitted on this port.
Feed tunnel end-point addresses sent in HELLO messages may be considered sensitive information on unidirectional links that are easy to intercept. Link-layer security mechanisms should be used when such information is sensitive.
The tunneling mechanism introduces risk of ARP and IP spoofing because nodes may not be authorized to tunnel packets. This should be countered by authenticating all tunnels, either via the delivery IP protocol (e.g., AH per RFC 2402) or an authentication protocol integrated with the tunneling mechanism.
A receiver maintains an active feeds list. State transitions: EMPTY → ACTIVE (upon JOIN from new FUIP); ACTIVE → ACTIVE (timer reset on duplicate JOIN sequence); ACTIVE → UPDATED (new sequence number in JOIN); ACTIVE → REMOVED (LEAVE received or HELLO_LEAVE timer expires).
The DTCP HELLO message is a fixed-structure UDP datagram containing: Vers (4 bits), Com (4 bits), Interval (8 bits), Sequence (16 bits), res (3 bits), F (1 bit), IP Vers (4 bits), Tunnel Type (8 bits), Nb of FBIP (8 bits), reserved (8 bits), followed by n Feed Bidirectional IP addresses of 32 or 128 bits each.
The GRE encapsulated packet format consists of: an IP delivery header with destination = FBIP and IP proto = GRE (47), followed by a GRE header with type = MAC type of the UDL, followed by the payload MAC packet.