摘要

  • RFC 3077 保留卫星馈送的单向物理特性，再通过节点双向接口间的 IP 隧道，模拟接收端原本无法经广播介质发出的链路层通信。
  • 单向传输的 DTCP 公告帮助接收端发现馈送并清除过期端点；它既不认证馈送，也不替所有接收端选出唯一最佳路径，更不能证明数据抵达应用。

RFC 3077 于 2001 年 3 月发布。它讨论的问题看似简单：共享广播链路上的两个节点，无法通过这段链路完成双向对话。馈送端可以沿单向链路发送，接收端只能收听；若馈送接口是只发送型，它从该接口也听不到任何内容。与此同时，互联网协议通常把链路视为可双向传送报文的媒介。路由器把报文发给下一跳后，往往还要等候回应或路由更新。

RFC 3077 没有给卫星接收器加装发射能力。接收端和馈送端都还需要一个接入 IP 网络的常规双向接口。接收端要把链路层帧发往馈送端时，会先封装该帧，再经隧道送至馈送端面向互联网的接口。馈送端解除封装，再把帧交给连接单向链路的链路层。卫星广播仍负责下行传送；节点之间的隧道才提供回程。

为什么不只在网络层另建一个 IP 网络？因为链路层模拟可以让既有网络层协议在不理解卫星物理限制的情况下继续运行，尤其是 ARP。RFC 3077 列出双向广播网络原本能够支持的六种通信情境。馈送到接收端的第六种情境，单向广播本来就能完成；隧道要补上的，是其余五种，包括接收端到馈送端、接收端之间以及广播和组播通信。这样的抽象把接口留在协议栈熟悉的位置，但不代表物理链路因此获得了反向发射能力。

文档建议使用通用路由封装（GRE）承载不同类型的内层报文。RFC 3077 描述的格式是：外层 IP 报文发往馈送端的双向接口地址；GRE 头标明单向链路所用的 MAC 协议类型；负载则是原始 MAC 帧。也可以选择其他隧道类型，但双方必须先约定其含义。RFC 3077 定义的是围绕隧道的适配机制，并没有把 GRE 变成授权或安全协议。

更容易被忽略的是，接收端如何知道该把隧道发往哪里。动态隧道配置协议（DTCP）并不通过互联网回程做发现。它的 HELLO 消息仍由馈送端经单向链路发给接收端。JOIN 表示馈送端正在工作；LEAVE 可以通知接收端它即将停止。HELLO 还带有发送间隔、序列值、隧道类型以及一个或多个馈送双向 IP 地址（FBIP）。接收端监听 DTCP 公告组播，并维护带端点信息与计时器的活动馈送列表。

收到 LEAVE 时，接收端可以尽快移除对应馈送。若 HELLO 消息停止，条目最终会超时。这只是一个范围有限的信号：馈送端可能故障，单向链路也可能中断。无论是哪一种，接收端都不能再假定该馈送仍能提供双向连通性。计时器决定接收端该停止尝试什么，却不能判断哪一个组件失效，更不能证明某个应用报文已经送达。

馈送选择权在本地。每个接收端各自选择默认馈送；RFC 3077 只把较低往返时延列为一种示例，并未规定全网统一算法。管理员也可以在公告列表中选择另一个更易连接的隧道端点。即使馈送端在单向介质上的 MAC 地址（FUMAC）是运行所需信息，RFC 也没有规定统一的发现方式。消息格式有助于交换信息，哪条路径实际可用仍取决于本地配置与判断。

“双向”一词会遮住另一项成本：两条路径并不同步。RFC 3077 以对地静止轨道卫星约 250 毫秒的单程时延为例，并提醒互联网回程自身也有变化。依赖即时响应的 ARP 地址解析可能因此让馈送端等待，等待期间报文不断堆积，最后耗尽缓冲区并被丢弃。这是规范提出的工程风险，不是某个具名服务的实测结果。两个方向被组合在一起，却仍由不同网络承载，时延、容量和控制权也各不相同。

因此，当单向链路中断时，RFC 要求接收端禁用相应隧道。否则路由器可能通过隧道仍收到报文，便误以为底层链路运作正常；某些路由协议会根据收到的流量判断邻居状态。馈送端失效时，也应停止无意义的隧道报文。一个帧完成解封装，只是链路中的一个事件，不等于路由稳定或服务成功。

信任是另一层问题。RFC 3077 警告，ARP 或 IP 欺骗可能让未经授权的节点进入服务。规范表示可以认证隧道，却没有规定认证机制。运行在模拟链路之上的路由协议，则应在可行时使用自身的认证机制，以阻止未经授权的接收端注入错误路由。DTCP 中的 JOIN 和端点字段是公告，不是凭证。

该规范也没有承诺设备插上就能互通。部署配置仍需写明所用 MAC 格式和隧道类型；如果不采用 GRE，双方还得明确约定隧道类型的解释。可扩展性及组播路由配置则留在规范范围之外。RFC 3077 通过拼接一条单向介质与一条回程网络，使前者能够被使用；它没有把两种路径变成默认统一、默认可信或自动易懂的系统。

主要来源